Standard for CI/CD

Metadata	Value
Source	Confluence - Standard for CI/CD
Status	Published (Closed)
Last Synced	2026-01-08
Space	Architecture (ARCH)

1. Executive Summary

This document introduces a common CI/CD (Continuous Integration and Continuous Delivery) standard to help teams across the organisation deliver software more efficiently, reliably, and securely. It establishes consistent practices and tooling while allowing flexibility to accommodate varying levels of team maturity and operational needs.

The standard acknowledges the value of existing gated release processes - such as Pre-CAB, CAB, and centralised deployment roles - while also offering a forward-looking approach that empowers teams to gradually adopt more automated, decentralised delivery models. The goal is to enable safe, auditable, and more frequent releases by embedding quality and control directly into the delivery pipeline.

2. Purpose

This standard provides a common foundation for evolving our CI/CD practices across the organisation. It is designed to:

Support faster, safer, and more consistent software delivery by encouraging automation where it adds the most value
Offer a scalable approach to CI/CD that works across both on-premise and cloud environments
Encourage a collaborative delivery model where development, testing, and operations work together throughout the lifecycle
Respect the diversity of team maturity levels and existing governance processes, while providing a clear path for gradual adoption

3. Scope

This standard applies to:

All teams building software that runs on either on-premise infrastructure or in the cloud
All GitHub-hosted source code repositories and associated delivery pipelines
CI/CD practices from code commit through production deployment

4. Deployment Pipelines

4.1. Common Technologies

Component	Technology
Source Code	GitHub
CI Pipeline	GitHub Actions
Security	SonarQube, Dependabot, GitHub Dependency Graph
Artefacts	GitHub Packages / GHCR.io (possibly replaced by Artifactory in the future)

4.2. Non-Kubernetes Deployments

Component	Technology
CD Tool	Ansible (transitioning to AWX)
Trigger	GitHub Actions → Ansible Playbooks
Future state	Self-service deployment via AWX UI with audit logs and role control

Note: AWX is still not available due to budget constraints. AWX adds visibility, self-service, and governance on top of raw Ansible.

4.3. Kubernetes Deployments

Component	Technology
CD Tool	ArgoCD
Trigger	GitHub Actions → GitOps repo update → ArgoCD watches and applies

Important: All production deployments must be executed exclusively through the governed CI/CD pipeline. Direct access or manual intervention in production environments is not permitted.

5. Flexible Approval Gates

To ensure safety and compliance without creating unnecessary delays, this standard allows for adaptable approval gates. Domains should tune gates based on application criticality and team maturity level.

5.1. Well-known Quality Gates

Stage	Gates
Pre-Merge	Code review, Automated unit tests, Automated Integration Tests, Static code analysis
Post-Merge / Pre-Deploy	QA sign-off (manual and/or automated), Scheduled Pre-CAB and CAB
Production or Production-like Deployment	Smoke Tests, Dynamic analysis (security), Release owner deploy, Time-window-based deployments

5.2. Risks of Traditional Gates

While traditional quality gates have historically provided control and oversight, they introduce certain risks:

Risk	Description
Delivery Delays	Scheduled approval meetings can introduce calendar-driven wait times
Bottlenecks and Queues	Centralised deployment responsibilities lead to delivery queues and limited scalability
Scaling Challenges	Manual controls do not scale effectively with increasing teams and services
Reduced Ownership	Handoff-based models may dilute responsibility
Risky release batching	Infrequent approvals lead to bundled changes, increasing complexity and risk

5.3. Evolving Gates Through Automation

As we modernise our delivery model, approval gates should evolve from people-dependent checkpoints to automated, auditable steps embedded in the CI/CD pipeline.

Options for Scalable Quality Gates

Practice	Reducing the need for	Description
Automate checks	Scheduled meetings	Replace scheduled approvals with automated gates that evaluate criteria like test coverage, security scans, and deployment readiness in real time
Role-based policies	Manual coordination	Gate behaviour governed by role-based rules enforced by the pipeline tool
Embedded audit trails	Centralised permissions	Every gate generates traceable logs - who approved what, when, and under what conditions
Dashboards and insights	Status meetings	Give managers visibility into deployment readiness through dashboards and real-time status
Tune gates per domain	All of the above	Gates should reflect the operational risk and maturity level of the team
Progressive deployment	All of the above	Rollout techniques that minimise blast radius: canary, blue/green, feature flags

6. Maturity Levels (Crawl/Walk/Run)

Category	🐢 Crawl	🚶 Walk	🏃 Run
🧪 Testing & Validation	Manual QA Sign-off for staging/pre-prod	Automated test suite with enforced coverage thresholds	Progressive rollout + automated rollback
🚀 Deployment Process	Manual deployment via script or CLI	Self-service deploy via Ansible/AWX	GitOps-based rollout with auto-promotion (ArgoCD)
🔒 Security & Quality	Static code analysis (Warnings only)	Dynamic analysis integrated as required gate in CI	Full security scan + license/compliance check
🧭 Governance	Manual approval in meetings (CAB), Time-window-based deployments	Role-based approval via pipeline (GitHub reviewers) and/or ChatOps	Conditional approvals based on service risk profile
📈 Observability	Informal smoke testing after deploy	Post-deployment automated smoke test	Live traffic validation and health-based gate
🧹 Code Quality	Code Review before merge	—	—
🛠️ Build & Test	CI Pipeline execution before merge	—	—
🧾 Traceability	Auditability of deployments	—	—

7. The Role of AI in Evolving Quality Gates

As we evolve our CI/CD model toward scalable and automated controls, AI offers a complementary way to improve speed, quality, and governance without increasing manual effort. The objective is to empower teams and leaders with intelligent insights.

Category	How AI Can Help
🧪 Testing & Validation	Generation of missing test cases
🚀 Deployment Process	Risk scoring for releases based on size, service criticality, test health, and config patterns; Smart suggestions for rollout strategy
🔒 Security & Quality	Continuous code scanning with AI-detected insecure patterns; Intelligent grouping of vulnerabilities by impact
🧭 Governance	Dynamic approval routing based on risk level; Pattern-based flagging of policy drift
📈 Observability	Anomaly detection post-deploy; Pre-production risk predictions based on telemetry trends
🧹 Code Quality	AI-assisted code review to catch patterns and suggest improvements
🛠️ Build & Test	Automated config linting based on learned patterns
🧾 Traceability	Smart generation of SBOM and changelogs for audit and compliance reviews

Note: This section does not mean these capabilities are available in the current Platform - the goal is to encourage both IDP and development teams to champion the mindset.

8. End Goal

The target state is a scalable and secure CI/CD ecosystem where:

Teams own their entire delivery pipeline, from code to production
Deployments are frequent, incremental, and low-risk
Quality gates are built into the pipeline and don't depend exclusively on external calendar-based checkpoints
Central teams (Architecture, DevOps, Security) enable, advise, and govern - but don't become bottlenecks

9. Frequently Asked Questions

Code	Question	Answer
OQ.1	Why not just stick with CAB and handovers?	While CABs and handovers have historically provided oversight, they can introduce delays and don't scale effectively. By automating checks within CI/CD pipelines, we retain control with greater speed, consistency, and traceability.
OQ.2	What if my team isn't ready for full autonomy?	The standard is intentionally flexible. Teams can start by automating selected steps while retaining manual gates where needed. The path to autonomy is gradual.
OQ.3	Why standardise across all environments?	A consistent approach reduces onboarding friction, troubleshooting effort, and deployment risks. It also simplifies support and enables better tooling.
OQ.4	Is this a mandate or a recommendation?	This standard provides a recommended baseline. Adoption is strongly encouraged but teams should be supported through the transition and allowed to adopt practices progressively.
OQ.5	What happens to DevOps or Release Engineers?	These roles remain essential. They increasingly focus on enablement - building shared tools, improving infrastructure, and coaching teams through modern delivery practices.
OQ.6	Will we lose control without CAB and manual approvals?	Not at all. Control is shifted - not removed - by embedding policy enforcement, traceability, and validation directly into pipelines.
OQ.7	How will risk be managed in automated deployments?	Automated gates include controls like mandatory test coverage, security scans, and progressive rollout strategies (canary, blue/green). These reduce risk while enabling faster feedback and recovery.