ADR-022: CI/CD and deployment strategy¶
| Status | Accepted |
| Date | 2026-04-10 |
| Deciders | CTO, Head of Platform Engineering |
| Affects repos | bank-core, bank-kyc, bank-aml, bank-payments, bank-credit, bank-risk-platform, bank-platform, bank-app |
Context¶
All eight system domain repositories need consistent CI/CD pipelines and environment management before any system can be built and deployed. Without a shared strategy, repos diverge — increasing operational overhead, creating inconsistent test coverage, and producing deployment paths that cannot be audited.
The bank is a regulated entity. Every production change must have a traceable audit trail, documented test evidence, and a controlled promotion path. APRA CPS 230 and RBNZ BS11 both require demonstrable change controls and operational risk management. Manual deployments are incompatible with AP-003 (compliance by design) and AP-004 (security by design).
The execution model is serverless. Pipeline and infrastructure decisions must reflect that: no cluster management, no container orchestration layer, artefacts are function packages not images.
Decision¶
Trunk-based development with immutable artefact promotion across four environments: local → dev → UAT → prod.
| Concern | Decision |
|---|---|
| CI/CD platform | GitHub Actions — already in use for wiki deployment; consistent with repo hosting |
| Execution model | Serverless functions — cloud provider not yet finalised (governed by SG-006 cloud-native, multi-region requirement) |
| IaC tooling | Not yet decided — a separate ADR will select the tool. Candidates: Terraform, Pulumi, AWS CDK, SST, and cloud-native tooling. Selection criteria: serverless-native support, state management approach, team familiarity, and provider lock-in risk |
| Artefact registry | Cloud-native function artefact store (provider-specific, finalised with cloud provider selection) |
| Secrets management | Cloud-native secrets manager or HashiCorp Vault; short-lived OIDC for pipeline-to-cloud auth |
| Branch strategy | Trunk-based; feature flags for partial work; no long-lived feature branches |
| Artefact promotion | Same function artefact (content-hash-tagged) promoted from dev → UAT → prod; no rebuilds |
The full pipeline design, testing gates, and infrastructure standards are documented in: - Environments and deployment framework - DT-010: Environments & deployment standards
Consequences¶
Positive: - Every production deployment is traceable from code commit through pipeline run to live service - The artefact deployed to prod is identical to what passed UAT — no environment-specific build differences - Compliance evidence is the pipeline log and IaC configuration history — not a manual attestation - Rollback is a pipeline trigger redeploying the previous artefact — not an emergency requiring production access - Serverless eliminates cluster and container orchestration management, consistent with AP-001 (KISS) - Shared pipeline structure reduces cognitive overhead across eight repos
Negative: - Each repository needs pipeline scaffolding before its first deployment — upfront cost before feature work begins - Trunk-based development requires discipline and feature flags for incremental work; teams unfamiliar with the pattern need onboarding - Cold-start latency must be measured against NFR thresholds for latency-sensitive paths (payments, KYC checks) - IaC tool selection is deferred — teams cannot finalise local environment setup until that ADR is resolved
Alternatives considered¶
GitFlow / long-lived environment branches: Rejected. Long-lived branches create merge debt, obscure what is actually deployed where, and make it harder to reason about pipeline state. Trunk-based is better suited to a small team moving quickly.
Container-based deployment (Kubernetes): Rejected. Serverless is the execution model. Containers would add cluster provisioning, orchestration, and operational overhead that conflicts with AP-001 (KISS) and increases the time to first deployment. Container CVE scanning and image registry management are also unnecessary concerns for a serverless platform.
PaaS (Heroku, Render, Railway): Rejected. Insufficient control for regulated financial services. Cannot satisfy NZ/AU data residency requirements, network isolation, or the audit-trail requirements of CPS 230 and BS11.
Manual deployments with runbooks: Rejected outright. Incompatible with DT-007 (change & release) and the bank's compliance-by-design principle. Creates an unauditable change path and is not scalable as the engineering team grows.
Per-environment IaC codebases: Rejected. Creates drift risk and maintenance overhead regardless of tooling choice. A shared IaC definition with per-environment variable overrides is simpler and keeps parity enforceable.
Signoff record¶
| Date | Name | Role | Status |
|---|---|---|---|
| 2026-04-10 | Ross Millen | CTO | Approved |
| 2026-04-10 | Ross Millen | Head of Architecture | Approved |
| 2026-04-10 | Ross Millen | Head of Data | Approved |
Capabilities¶
| Capability | Description | Relationship |
|---|---|---|
| CAP-028 | Policy-as-code satisfaction framework | governed — pipeline policy gates enforce policy compliance on every commit |
| CAP-029 | Immutable audit log | governed — every production change has a traceable pipeline audit trail |
| CAP-111 | Feature flag & remote config | governed — feature flags mandated for trunk-based development |
Related decisions¶
| ADR | Title | Relationship |
|---|---|---|
| ADR-025 | API layer — HTTP API Gateway and SST | resolves the deferred IaC tooling decision from this ADR |
| ADR-033 | Feature flag management — AWS AppConfig | resolves the deferred feature flag tool decision from this ADR |
All ADRs
Compiled 2026-05-22 from source/entities/adrs/ADR-022.yaml