Business Rules - DevOps & CI/CD

This document lists the fundamental business rules of the DevOps & CI/CD domain, each identified by a unique BR-NNN code. Every rule is technology-independent and describes an invariant constraint on the behavior of the integration and release pipeline.

---

BR-001 - Build once, deploy many

Code: BR-001 Name: An artifact is built once and promoted unchanged across environments Description: The same Artifact produced by the build stage must be promoted identically through staging and production. Rebuilding the artifact per environment is not allowed, as it would introduce untested differences. Rationale: Ensure what was tested is exactly what is released; traceability. Priority: HIGH Actors: CI Runner, Release Manager Violation: promotion is blocked if the production artifact does not match by digest the tested one. Traceability: 12factor.net; build-and-release.md; Artifact (glossary).

---

BR-002 - Immutable, versioned artifacts

Code: BR-002 Name: Every artifact has a unique immutable identifier (digest/version) Description: An Artifact published to the ArtifactRegistry cannot be overwritten. A new build produces a new identifier (version tag or content digest). Mutable tags (e.g. latest) are not the source of truth for promotion. Rationale: Release reproducibility and reliable rollback. Priority: HIGH Actors: CI Runner, Artifact Registry Traceability: OCI image digest; SemVer; BR-001.

---

BR-003 - Every change goes through the pipeline

Code: BR-003 Name: No change reaches production without passing the CI/CD pipeline Description: Every Commit destined for production must traverse the Pipeline (build, test, scan, gate) with a green result. Direct manual changes in environments are forbidden. Rationale: Quality, repeatability and auditability of every release. Priority: CRITICAL Actors: Developer, CI Runner Violation: immediate rollback and blocking of direct access to environments. Traceability: commit-to-deploy.md; GitOps (glossary).

---

BR-004 - Blocking quality gates

Code: BR-004 Name: A pipeline with failed tests, SAST or scans does not promote Description: If a test, static analysis (SAST) or security Job fails, the corresponding Stage fails and the Pipeline does not proceed to promotion. Gates cannot be bypassed without a tracked and approved exception. Rationale: Prevent defects or known vulnerabilities from reaching production (shift left). Priority: HIGH Actors: CI Runner, Security Engineer Traceability: Shift Left, DevSecOps (glossary); commit-to-deploy.md.

---

BR-005 - Secrets never reside in code or logs

Code: BR-005 Name: Credentials and tokens are injected from the Secrets Manager, never versioned Description: No secret may appear in the Git repository, history, pipeline files or Job logs. Secrets are retrieved at runtime from the audited secrets manager and masked in logs. Rationale: Prevent credential disclosure in the supply chain. Priority: CRITICAL Actors: Security Engineer, CI Runner Violation: the secret scan blocks the pipeline; immediate rotation. Traceability: Secrets Management, Supply Chain Security (glossary).

---

BR-006 - Zero-downtime deploy with fast rollback

Code: BR-006 Name: Every production release is progressive and quickly reversible Description: Releases use progressive strategies (blue-green or canary) with health checks; on degradation, Rollback returns to the previous version within minutes without rebuilding the artifact. Rationale: Reduce the risk and blast radius of a faulty release. Priority: HIGH Actors: Release Manager, Deployment Target Traceability: Blue-Green, Canary, Zero-Downtime Deployment (glossary); deploy-rollback.md.

---

BR-007 - The pipeline is defined as code in the repository

Code: BR-007 Name: The pipeline definition lives versioned next to the code Description: The build, test and deploy configuration (Pipeline, Stage, Job) is declared in versioned files in the repository, not configured manually in the CI system's UI. Changes go through code review. Rationale: Traceability, reproducibility and review of changes to the release process. Priority: HIGH Actors: Developer, Platform Engineer Traceability: Infrastructure as Code, GitOps (glossary).

---

BR-008 - Verifiable supply chain (SBOM and provenance)

Code: BR-008 Name: Every artifact has an SBOM and signed provenance Description: The pipeline generates an SBOM (Software Bill of Materials) for every Artifact and records its signed provenance. Dependencies are scanned for known vulnerabilities before promotion. Rationale: Track and secure the software supply chain. Priority: HIGH Actors: Security Engineer, CI Runner Traceability: SBOM, Supply Chain Security (glossary); BR-004.

---

BR-009 - DORA metrics drive improvement

Code: BR-009 Name: Lead time, deploy frequency, MTTR and change failure rate are measured Description: The domain measures the four DORA metrics for each service: lead time for changes, deployment frequency, mean time to recovery and change failure rate. Process improvement decisions are based on these indicators, not opinions. Rationale: Improve delivery speed and stability in a measurable way. Priority: MEDIUM Actors: Platform Engineer, Release Manager Traceability: DORA Metrics, Lead Time for Changes, MTTR, Change Failure Rate (glossary).