CI/CD Pipelines

Two families of pipeline

• Production pipeline — deploys to stage, runs the gates, then promotes to production. Exactly one per program. Requires approval to reach production if configured.
• Non-production pipeline — either deploys to a development environment, or is a code-quality-only pipeline that builds and analyses without deploying anywhere. You can have several.

A code-quality-only pipeline on your main branch is one of the cheapest wins available: every merge gets analysed, so gate failures surface long before a release.

Triggers:

• Manual — someone presses Run.
• On Git changes — commits to the configured branch start the pipeline.
• Scheduled — for regular validation.

The stages of a production pipeline

1. Validation — checks the pipeline configuration and repository.
2. Build and unit testing — Maven build with your unit tests.
3. Code scanning — SonarQube analysis against Adobe's rule set.
4. Build images — package the deployable artefacts.
5. Deploy to stage.
6. Functional testing — product functional tests, your custom functional tests, and UI tests if configured.
7. Experience audit — Lighthouse-style performance, accessibility, SEO and best-practice checks on nominated pages.
8. Approval — if configured, a human gate.
9. Deploy to production, with a managed rollout.

The three-tier gate model

Every gate finding has a severity, and the model is the same across gates:

• Critical failure — the pipeline stops. No override.
• Important failure — the pipeline pauses and an authorised user (Business Owner or Deployment Manager) may override with a justification, which is recorded.
• Info — advisory, does not block.

The gates themselves:

• Code quality — Sonar findings plus test coverage against a threshold (commonly 50% line coverage).
• Security testing — configuration and code security checks.
• Performance testing — load testing against stage.
• Experience audit — page-level quality metrics.

Config pipelines

Some configuration is deployed separately from code, through a config pipeline targeting files under a top-level config folder:

• CDN traffic filter and WAF rules (cdn.yaml) — day 39.
• CDN redirects, purge configuration and request transformations.
• Log forwarding.

They are separate because they change independently of application code and must be deployable quickly — you do not want to run a full production pipeline to add a WAF rule during an incident.

Reading a failure

1. Which step failed? The pipeline UI names it, which narrows the cause immediately.
2. Build failure — download the build log. Usually a compile error, a failing test, or a dependency that resolves locally but not in the pipeline.
3. Code quality — open the detailed results to see whether it is coverage or specific findings.
4. Deployment failure — check package install errors, often a filter or repository structure problem.
5. Functional test failure — the test report identifies the case; reproduce it on stage.