CI/CD release flow and feedback loops

Exam alignment: Domain 1.1: implement CI/CD pipelines. This includes choosing stages, actions, triggers, execution behavior, gates, and failure paths that satisfy the scenario.

Learning objective

Design a release flow that gives developers fast feedback, preserves one source revision and its artifacts, uses objective promotion criteria, and handles overlapping executions and failures deliberately.

Difficulty	Foundation
Study time	160 minutes
Prerequisites	Git, software testing basics, and the previous lesson

Professional scenario

A team runs a nightly build and a full test cycle every Friday. Integration defects are discovered several days after the responsible commit. Because the pipeline takes four hours, emergency fixes bypass it. Two releases can also enter the shared test environment at the same time and overwrite one another.

The problem is not simply that the pipeline is slow. Its feedback arrives too late, its environment has no concurrency policy, and the team has not distinguished cheap deterministic checks from expensive environment-dependent tests.

The CodePipeline mental model

An AWS CodePipeline design is easier to reason about when each term has one precise meaning.

Concept	Meaning	Design question
Source revision	The exact source state associated with an execution	Which commit, image, or object started this run?
Pipeline execution	One movement of a source revision through the workflow	Can it overlap or supersede another execution?
Stage	A logical release phase, often an environment boundary	What must be true before the revision leaves this phase?
Action	A unit of work inside a stage	What input does it consume and what output does it produce?
Artifact	Files passed between actions through the artifact store	Is this the same tested output that production receives?
Trigger	The event or manual request that starts an execution	Can duplicate or unintended triggers occur?
Condition or gate	Evidence evaluated before or after a stage transition	Is the decision objective and repeatable?

A stage is not just a visual group in the console. It can represent an environment or release boundary and influences how executions move through the pipeline. An action performs work such as sourcing code, building, testing, approving, or deploying.

Actions in the same stage can run in parallel when they have the same runOrder. A higher runOrder waits for all successful actions in lower orders. Parallelism is useful only when actions are independent. Two tests that modify the same database are not safely parallel merely because the pipeline supports it.

Artifacts and source identity

The source action establishes the revision for the execution. Build actions consume a source artifact and can emit a compiled application, container metadata, templates, test output, or another artifact.

CodePipeline transfers artifacts through its S3 artifact store. An action should declare only the input artifacts it requires and produce clearly named outputs. This makes the data flow visible and prevents later stages from silently rebuilding or fetching an untracked version.

Example artifact flow:

SourceOutput
    |
    v
CodeBuild -> ApplicationArtifact + TestReports + Manifest
                    |
                    v
             DeployToTest
                    |
                    v
             DeployToProduction

The test report is evidence about ApplicationArtifact; it is not a replacement for that artifact. The manifest connects both to the source revision and build execution.

Arrange checks for useful feedback

The fastest pipeline is not necessarily the best pipeline. The goal is to minimize the time until a useful, trustworthy result.

Check	Typical position	Reason
Formatting, lint, and policy validation	Earliest	Cheap and deterministic
Unit tests	Early	Fast isolation of code defects
Static security and dependency checks	Early or parallel with unit tests	Stops known policy violations before deployment
Build and packaging	Before environment tests	Produces the candidate artifact
Integration tests	After deployment to an isolated environment	Requires real service interactions
Acceptance and synthetic tests	Before production promotion	Validates user-visible behavior
Load or resilience tests	Dedicated stage or scheduled workflow	Expensive and may disturb shared environments
Runtime health validation	During and after deployment	Detects failures that pre-production tests missed

Parallel actions reduce elapsed time only if they do not compete for state or hide the first useful failure. A ten-minute unit test and ten-minute static scan can run in parallel. Two database migration tests using one schema need isolated databases or serial execution.

Objective gates versus human decisions

A gate is objective when another engineer can evaluate the same evidence and obtain the same result.

Examples of objective gates:

• all required tests passed
• code coverage did not fall below the agreed threshold
• no vulnerability above the accepted severity is present
• the artifact is signed and its digest matches the manifest
• the deployment alarm remained healthy during the observation period

A manual approval is appropriate when judgment or accountability is genuinely required, for example a scheduled business release decision. It is weak when a person is asked to inspect deterministic data that the pipeline could evaluate automatically.

An approval also needs context: source revision, artifact version, changed components, test evidence, risk, rollback plan, and expiry. “Approve build 483?” is not enough information for a professional decision.

Execution modes and overlapping changes

CodePipeline supports different ways to handle multiple executions:

Mode	Behavior	Suitable when	Important trade-off
SUPERSEDED	A newer execution can overtake an older one	Only the newest revision should continue	Older work may not complete
QUEUED	Executions pass through one by one	A shared environment must process changes in order	Feedback can wait in a queue
PARALLEL	Executions run independently at the same time	Environments and state are isolated per execution	Stage rollback is not available in parallel mode

Do not confuse parallel pipeline executions with parallel actions inside one stage. They solve different problems. Execution mode controls overlapping revisions; runOrder controls action ordering for one revision.

Worked release flow

For a web service with development, test, and production accounts:

1. Source stage: A reviewed merge starts one execution and records the commit ID.
2. Validate stage: Lint, unit tests, template validation, and dependency scanning run in parallel where independent.
3. Build stage: CodeBuild creates one artifact, digest, software bill of materials where required, and test reports.
4. Test deployment stage: The artifact is deployed to an isolated test environment.
5. Acceptance stage: API, integration, and synthetic checks run against the deployed version.
6. Production decision: Objective evidence is evaluated; a recorded approval is added only if the business process requires judgment.
7. Production deployment: Traffic shifts progressively while alarms are observed.
8. Outcome: Healthy traffic completes promotion. An alarm stops the shift and starts the defined recovery action.

Every failure should notify an owner with the execution ID, source revision, failed action, first relevant error, and a link to the evidence. A notification that says only “pipeline failed” creates another investigation step.

Architecture flow

Source
  |
  v
Fast validation ----------------------+
  |                                   |
  +--> Unit tests                     |
  +--> Static and policy checks       | same revision
  +--> Template validation            |
  |                                   |
  v                                   |
Build immutable artifact <------------+
  |
  v
Deploy test -> integration checks -> promotion gate
                                         |
                                         v
                              progressive production release
                                  |                 |
                               healthy           alarm
                                  |                 |
                               complete      stop or rollback

Decision matrix

Requirement	Preferred direction	Reason
Fast developer feedback	Run cheap deterministic checks first	Failures return before expensive work
Independent checks	Same-stage parallel actions	Reduces elapsed time without changing evidence
Shared test environment	Queue or otherwise serialize deployments	Prevents state collisions
Per-change ephemeral environment	Parallel executions may fit	Each revision owns isolated state
High-risk production release	Progressive deployment with runtime alarms	Limits blast radius
Deterministic compliance rule	Automated gate	Repeatable and auditable
Business judgment required	Context-rich recorded approval	Preserves accountable decision-making

Failure modes and troubleshooting

Symptom	First question	Likely area
Pipeline did not start	Was the expected source event emitted and matched?	Trigger, connection, or EventBridge rule
Action cannot find input	Did the previous action declare the expected output name?	Artifact declaration
Test passes locally but fails in pipeline	Are runtime, dependencies, IAM, network, and environment variables identical?	Build environment or configuration
New execution overtakes old work	Which execution mode is configured?	Pipeline flow control
Approval waits forever	Was context delivered, and did the action expire?	Approval notification and ownership
Deployment succeeded but service is unhealthy	Which runtime or business health checks were evaluated?	Post-deployment validation
Retry fails or is unavailable	Was the execution superseded, or is rollback unsupported in this mode?	Execution state and mode

Troubleshoot from the first failed boundary rather than the final symptom. Follow the execution ID, source revision, input artifact, action role, service event, and output artifact in order.

Security and operations

• Give the pipeline service role only the orchestration permissions it needs.
• Use separate action or deployment roles when duties or accounts differ.
• Encrypt artifact stores and restrict read, write, and deletion permissions.
• Keep credentials out of action configuration; retrieve secrets at execution time through a supported secure mechanism.
• Protect test data with the same classification discipline used for production data.
• Retain action, approval, and deployment evidence according to audit requirements.
• Monitor pipeline inactivity as well as failure; a pipeline that never starts can be silently broken.

Hands-on lab: design a three-environment release flow

Goal: Produce a release-flow specification that another engineer could implement without guessing.

Tasks

1. Choose one source event and define the exact source revision identifier.
2. List every check, its duration, dependencies, output, and owner.
3. Order checks by feedback value, speed, and risk.
4. Mark actions that can safely share a runOrder and explain why.
5. Define artifact names and the producer and consumer of each artifact.
6. Choose an execution mode for the shared test environment and justify it.
7. Write entry and exit criteria for every stage.
8. Define the evidence included in a production approval, if one is required.
9. Define a runtime alarm and the exact stop or rollback behavior.
10. Create notifications for trigger failure, action failure, approval timeout, deployment alarm, and successful recovery.

Validation checklist

• Every stage has objective exit criteria.
• Every artifact has one clear producer and at least one intended consumer.
• The production artifact is not rebuilt.
• Parallel work has no shared mutable state, or the state is isolated.
• Overlapping executions have an explicit policy.
• A required failure blocks later stages.
• Notifications identify the revision, execution, failed boundary, and owner.

Cost control: The design version needs no cloud resources. Implement only the source and validation stages in a sandbox if you want a low-cost extension.

Cleanup

For the optional implementation, remove test pipelines, artifact buckets, roles, event rules, build projects, and logs after verifying that no shared resource depends on them.

Exam traps

• Assuming every pipeline must be strictly sequential.
• Confusing parallel actions with parallel pipeline executions.
• Selecting PARALLEL while requiring stage rollback.
• Using manual approval for a deterministic policy rule.
• Running expensive tests before cheap checks.
• Rebuilding the artifact after approval.
• Treating an approval without evidence as a strong control.

Key takeaways

• A pipeline moves one identified source revision and its artifacts through controlled boundaries.
• Put fast, deterministic feedback early and parallelize only independent work.
• Choose execution behavior from environment and state constraints.
• Gates need objective evidence; approvals need decision context.
• Model trigger, success, failure, timeout, and recovery paths.

Review questions

1. What distinguishes a stage from an action?
2. How does runOrder affect actions in one stage?
3. What is the difference between parallel actions and PARALLEL execution mode?
4. When is QUEUED preferable to SUPERSEDED?
5. Why should test reports identify the artifact they validate?
6. What makes a promotion gate objective?
7. Why is a deployment-success event insufficient for production promotion?
8. What information should a useful failure notification contain?

Model answers

1. A stage is a logical release or environment boundary. An action is one unit of work within a stage that consumes inputs and may produce outputs.
2. Actions with the same runOrder can run in parallel. A higher order waits until all required actions in lower orders succeed.
3. Parallel actions execute independent work for one pipeline revision. PARALLEL mode allows multiple pipeline revisions to execute independently at the same time.
4. Use QUEUED when revisions must enter a shared environment one at a time and in order. SUPERSEDED fits when only the newest revision should continue.
5. Without that connection, the evidence could describe a different build. Revision, digest, and build identity preserve provenance.
6. It uses measurable evidence and a repeatable rule that produces the same result for the same inputs.
7. It proves that the deployment provider completed its operation, not that dependencies, customer behavior, latency, or business transactions are healthy.
8. At least source revision, execution ID, failed stage and action, first relevant error, evidence link, environment, and responsible owner.

Further reading

• AWS CodePipeline concepts
• How CodePipeline executions work
• CodePipeline pipeline structure reference