Skip to content

DevOps / GitOps — workflows

Target

This page describes intended behaviour or structure. No implementation is claimed unless a section is explicitly marked Current implementation or Evidence.

W1 — A change set becomes a pull request

sequenceDiagram
    participant A as Agent attempt
    participant AS as ArtifactService (validators)
    participant T as ToolAdapterService
    participant SOR as Azure DevOps / GitHub (connector)
    participant P as PipelineExecutionService
    participant RC as RunControlService
    A->>AS: change-set artifact, local validators (compile, tests) → ArtifactValidated
    A->>T: propose-change-set (shared-write)
    T->>SOR: push branch with commit trailers, open pull request
    T->>P: RecordProposal (receipt)
    P-)RC: ChangeProposalOpened (run waits for review in the system of record)
    SOR-)P: webhook deliveries: review, new commits, merge
    P-)RC: ChangeProposalStateChanged … ChangeProposalMerged
Hold "Alt" / "Option" to enable pan & zoom

W2 — A pipeline run is mirrored

Deliveries for run started, stage completed and run completed arrive through the webhook gateway (GW-06) and the connector registry as DeliveryReceived; DeliveryApplier maps them to the run and attaches typed results (build, tests, coverage, static analysis, security scan, SBOM, packages, images, attestations) with artifact references. A run still Running after the threshold is polled by RunReconciler; nothing is assumed.

W3 — A release is assembled and verified as published

flowchart LR
    PR[PipelineRunCompleted · Succeeded on release branch] --> AS[Assemble: version, commit, components with digests, SBOM, attestations, merged proposals, generating assets]
    AS --> CAND[Candidate]
    CAND --> PV[PublicationVerifier: digest present in registry or feed per component]
    PV -- all present --> REL[Released → ReleaseReady]
    PV -- missing after retries --> STAY[stays Candidate · component named · Operator re-runs CI publication]
    REL --> NOTES[release notes drafted as an artifact · never auto-published]
Hold "Alt" / "Option" to enable pan & zoom

W4 — A release is promoted to production

sequenceDiagram
    participant O as Operator / deploy-environment tool
    participant E as EnvironmentPromotionService
    participant PE as PolicyEngineService
    participant RC as RunControlService
    participant PR as IaCProvisioningService (BC-25)
    participant ENV as EnvironmentService
    O->>E: RequestPromotion (release, production)
    E->>E: gates: PipelineResults ✓, PriorEnvironment (staging Completed) ✓, EnvironmentReady ✓, EvaluationEvidence ✓
    E->>PE: Decide (Deployment, production) → RequireApproval
    E->>RC: approval of class production bound to release + environment
    RC-)E: ApprovalDecided (Approved, decider ≠ requester)
    E-)PR: PromotionApproved (desired state, strategy)
    PR-)E: ProvisioningApplied
    E->>E: verify: health, smoke, SLO window
    E-)ENV: PromotionCompleted (current release updated)
Hold "Alt" / "Option" to enable pan & zoom

W5 — Verification fails and the environment rolls back

If health, the smoke suite or the SLO window fails within the verification window and AutoRollbackOnVerificationFailure is on, the service hands the previous release's desired state back to provisioning, waits for ProvisioningApplied, records RollbackCompleted with the evidence of what failed, raises an alert, and leaves the failed promotion as RolledBack for the Operator. A manual rollback from the Studio follows the same path with the Operator's role as the approval.

W6 — Recovery after a lost delivery store

Proposals and runs are re-pulled from the system of record through connectors; releases are rebuilt from pipeline results and registry reads; promotions are recovered from the run journal (approvals) and provisioning's receipts. Nothing in this store is the only copy of anything except the gate evidence per promotion, which is also in audit.