Skip to content

Environments and deployment standards
Code DT-010
Domain Data & Technology
Owner Head of Platform Engineering
Status Draft
Applicability Platform
Jurisdiction NZ + AU
Business domain BD09
Review date 2027-03-27

Regulations: CPS 230 Operational Risk Management · CPS 234 Information Security · DTA Outsourcing Standard

Defines minimum technical requirements for environment configuration, CI/CD pipeline design, testing gates, infrastructure management, and secret handling across all system domains.

Scope

Applies to all eight code repositories and their cloud infrastructure: bank-core, bank-kyc, bank-aml, bank-payments, bank-credit, bank-risk-platform, bank-platform, bank-app.

Environment requirements

  1. All systems shall maintain four environments: local, dev, UAT, and prod.
  2. No environment shall be bypassed in the promotion path — dev must pass before UAT is triggered; UAT must pass before prod is triggered.
  3. Dev and UAT deployments shall be executed exclusively via CI/CD pipelines. Manual deployments are prohibited.
  4. Prod deployments shall require a named approval gate in addition to passing all pipeline stages.
  5. Dev, UAT, and prod shall run in logically isolated infrastructure (separate cloud accounts or equivalent hard-boundary isolation). No cross-environment network paths are permitted.
  6. Production data shall never be replicated to dev or UAT environments. Test data must be synthetic.

CI/CD pipeline requirements

  1. Every merge to main shall trigger an automated pipeline covering, at minimum: static analysis, unit tests, artefact build, integration tests, deployment to dev, and smoke tests.
  2. UAT deployments shall be triggered only by a release candidate tag on main. Branch pushes shall not deploy to UAT.
  3. The same deployable artefact (identified by an immutable content hash) that passes UAT shall be deployed to prod without rebuilding.
  4. Pipeline configuration shall be stored as code in the repository it serves. No pipeline configuration shall reside only in a CI/CD platform's UI.
  5. All pipeline execution logs shall be retained for a minimum of 90 days and shall be queryable for audit purposes.
  6. A failed pipeline gate shall block deployment. No bypass mechanism is permitted without a change request approved under DT-007.

Testing gate requirements

  1. Unit test line coverage shall be ≥ 80% before any dev deployment proceeds.
  2. Integration tests shall cover all module API contracts and key error paths before dev deployment.
  3. UAT/BDD tests shall cover all acceptance criteria documented in docs/systems/ for the module being deployed, and shall pass before UAT promotion.
  4. Security scans (SAST and dependency vulnerability scan) shall run on every build. Critical-severity findings shall block deployment.
  5. Performance tests shall run against UAT before any prod promotion for modules that have NFR thresholds defined in docs/goals/nfr-register.md.
  6. Smoke tests shall run after every deployment to dev, UAT, and prod. A failed smoke test in prod shall trigger automated rollback within five minutes.

Infrastructure as code requirements

  1. All cloud infrastructure, serverless function configuration, networking, DNS, and TLS configuration shall be defined in infrastructure as code (IaC). The specific IaC tooling is an architectural decision — see ADR-022.
  2. No resource shall be created or modified outside of IaC in dev, UAT, or prod environments. Exceptions require a change request under DT-007.
  3. IaC configuration and any associated state shall be stored remotely with access controls and an audit trail. Local-only IaC state is not permitted for shared environments.
  4. Environment-specific differences shall be expressed as variable overrides or stack parameters on a shared IaC definition. Separate IaC codebases per environment are not permitted.

Secret management requirements

  1. No secrets, credentials, API keys, or private keys shall appear in source code, build artefacts, IaC configuration, or pipeline logs.
  2. Pipeline-to-cloud authentication shall use short-lived credentials (OIDC or equivalent). Static long-lived credentials in pipelines are prohibited.
  3. All secrets shall be stored in an approved secrets manager and injected into workloads at runtime only.

Compliance basis

This policy supports APRA CPS 230 (operational risk management), APRA CPS 234 (information security), and RBNZ BS11 (cloud outsourcing). Compliance evidence is the CI/CD pipeline log and IaC configuration history — not a manual attestation.

Satisfying modules

Module Name Mode Description
MOD-156 CI/CD pipeline platform AUTO GitLab Environments, protected branch rules, and OIDC role bindings are automatically provisioned from source-controlled config — no manual environment configuration is permitted.

Part of Data & Technology · Governance overview Compiled 2026-05-22 from source/entities/policies/DT-010.yaml