Notifications
Clear all
Topic starter
06/09/2026 9:34 am
TL;DR: Deploy 26.1 makes GitOps more governable by limiting bidirectional YAML exchange to Deploy Infrastructure and Environment configuration items, with explicit import and export control task execution, branch and path mappings, and excluded secret fields, according to Arxan Technologies. The practical shift is not full declarative control, but a tighter reviewable boundary for environment definitions and promotion discipline.
NHIMG editorial — based on content published by Arxan Technologies: How Digital.ai Deploy Makes GitOps A Reliable, Governed Model
Questions worth separating out
Q: What breaks when deployment configuration is managed outside Git?
A: Teams lose a clean version history for environment definitions, which makes it harder to tell what changed, who changed it, and whether the applied state still matches approved intent.
Q: Why does separating secrets from GitOps matter for governance?
A: Secrets need a different lifecycle from infrastructure and environment definitions because they are not just configuration text.
Q: How should security teams audit a GitOps-based deployment model?
A: They should audit who can change repository content, who can approve promotion, and who can execute control tasks that apply the change.
Practitioner guidance
- Define a GitOps scope boundary for deployment objects Limit Git-managed synchronization to infrastructure and environment configuration items, and document which fields stay outside the import and export loop because they require separate lifecycle handling.
- Map branch and path mappings to promotion stages Assign branch or directory mappings to specific lifecycle stages such as staging, production, or regional overlays so the repository layout reflects governance intent instead of convenience.
- Correlate control tasks to change records Capture import and export task executions alongside commit IDs, pull requests, and approval records so the system produces an auditable chain of custody for configuration changes.
What's in the full article
Arxan Technologies' full blog post covers the operational detail this post intentionally leaves for the source:
- The specific git.GitSource and git.GitDirectory object model used to wire repository mappings into Deploy
- The exact import and export control task flow for moving YAML between Git and Deploy
- The handling limits for excluded value types such as dictionaries, encrypted dictionaries, and secret or key fields
- The practical implications of branch and path mapping choices for staging, production, and regional overlays
👉 Read Arxan Technologies' analysis of governed GitOps for Deploy 26.1 →
GitOps for deployment configuration items: what changes for teams?
Explore further
06/09/2026 9:34 am
Governed GitOps works best when the boundary is narrow and explicit. The article is strongest when it defines exactly what is in scope and what is excluded, because governance fails most often when teams assume too much can be made declarative at once. Infrastructure and environment definitions can be controlled as YAML, but secrets, encrypted dictionaries, and key fields need a different lifecycle. The practitioner lesson is to design for controlled scope, not universal Git-ification.
A question worth separating out:
Q: How do teams know whether GitOps is improving control rather than adding noise?
A: Look for fewer ad hoc UI edits, clearer promotion paths, and a consistent match between declared YAML intent and the deployed environment. If the workflow still depends on manual reconstruction after changes, then Git is only storing files, not governing state. Effective GitOps reduces ambiguity, not just console activity.
👉 Read our full editorial: GitOps for deployment config: what governed YAML changes change
