Skip to content

Workflows

This page describes how the DevOps / GitOps Platform turns validated artifacts into running systems — the core GitOps delivery flow — and the lifecycle of a release. It is the operational realization of the platform's promise: the bridge from validated artifacts to running systems.

Target Architecture — Final-State Design

The flow is fully agent-driven. The Agent Mesh DevOps & Release cluster issues commands; the platform's services and workers execute them and emit events that advance the workflow.

GitOps Delivery Flow

sequenceDiagram
    participant AM as Agent Mesh (DevOps cluster)
    participant CS as CommitService
    participant PR as PullRequestService
    participant PG as PipelineGeneratorService
    participant PE as PipelineExecutionService
    participant BR as BuildResultService
    participant RS as ReleaseService
    participant EP as EnvironmentPromotionService
    participant GS as GitOpsSyncService
    participant RT as Runtime and Cloud

    AM->>CS: CreateCommit (validated artifacts)
    CS-->>AM: CommitCreated
    AM->>PR: OpenPullRequest
    PR-->>AM: PullRequestOpened
    PR->>PR: Run checks and policy gate
    AM->>PR: MergePullRequest
    PR-->>PG: PullRequestMerged
    PG-->>PE: PipelineGenerated
    AM->>PE: RunPipeline
    PE-->>BR: PipelineRunStarted then build outputs
    BR-->>RS: BuildCompleted
    AM->>RS: PlanRelease
    RS-->>AM: ReleasePlanned
    AM->>RS: ApproveRelease (segregation of duties)
    RS-->>EP: ReleaseApproved
    EP->>EP: Render manifest, promote
    EP-->>GS: DeploymentPromoted
    GS->>RT: Reconcile desired state from Git
    GS-->>AM: GitOpsSynced
Hold "Alt" / "Option" to enable pan & zoom

Steps

  1. Commit — the Code Committer agent writes validated artifacts to a feature branch via CreateCommit; CommitCreated is emitted with lineage to the source artifactId.
  2. Pull request — the Pull Request Creator agent opens a PR; branch policy and build checks run; on success the PR is merged (PullRequestMerged).
  3. Pipeline generation — PipelineGeneratorService generates/refreshes the YAML pipeline (PipelineGenerated).
  4. Build — PipelineExecutionService runs the pipeline (PipelineRunStarted); on completion BuildResultService ingests results and emits BuildCompleted. Packages publish to Azure Artifacts and images to ACR in parallel.
  5. Release plan — the Release Manager agent plans a release (ReleasePlanned) for a target environment and strategy.
  6. Approval — ReleaseApproved is recorded after the Governance Platform policy gate passes and an approver distinct from the planner signs off.
  7. Promotion & manifest — DeploymentManifestService renders the manifest; EnvironmentPromotionService promotes through the environment path (DeploymentPromoted). Infrastructure is provisioned via Pulumi (InfrastructureProvisioned) when required.
  8. GitOps sync — desired state is committed to the GitOps repository; GitOpsSyncService reconciles it onto the Runtime & Cloud Platform and emits GitOpsSynced.

ReleasePlan State Machine

stateDiagram-v2
    [*] --> Planned
    Planned --> PendingApproval : submit for approval
    PendingApproval --> Approved : policy passed and approver signed
    PendingApproval --> Rejected : policy failed or rejected
    Approved --> Promoting : begin promotion
    Promoting --> Deployed : health gates passed
    Promoting --> Failed : deploy or health gate failed
    Failed --> Promoting : retry after fix
    Rejected --> Planned : revise and replan
    Deployed --> [*]
Hold "Alt" / "Option" to enable pan & zoom

Failure Handling

  • Build failure — BuildCompleted with status=Failed halts the flow; the Bug Investigator/Resolver agents may be engaged. No release is plannable from a failed build.
  • Policy rejection — a failed governance gate yields Rejected; the release returns to Planned for revision. The decision is audited.
  • Deploy/health-gate failure — promotion enters Failed; the strategy's rollback (e.g. blue/green swap back, canary abort) is executed, then a retry is attempted after remediation.
  • Drift — if GitOps detects drift between runtime and Git, it reconciles automatically; persistent drift raises a Degraded sync state and an alert.

Retry & Compensation

  • Workers retry transient failures with exponential backoff (see Workers); apply/promote operations re-preview before retrying to avoid partial mutations.
  • The release flow is a MassTransit saga keyed on releaseId, so it resumes correctly after restarts.
  • Compensating actions: failed promotions roll back to the last healthy deployment; failed infra applies are reconciled against Pulumi state and re-previewed.

Human Escalation

  • Approvals can require a human approver via the Factory Studio DevOps Center when policy mandates (e.g. production releases).
  • Exhausted retries and dead-lettered messages raise incidents in the Observability & Feedback Platform for human triage, with the full envelope preserved for replay.
  • Segregation of duties guarantees the approving identity differs from the planning identity, even when both are agents.

Pillar Alignment

  • Autonomy — the happy path runs without human intervention; humans are engaged only by policy or on failure.
  • Governance — approval and policy gates are mandatory and audited.
  • Traceability — a single traceId spans the entire sequence from commit to GitOps convergence.