A pipeline that fits the project
Decide which parts of a reference Terraform pipeline to reuse, based on the new project's risks and scale.
The decision you will investigate
A fictional scenario: read the evidence and compare approaches. Each recommendation fits this case's constraints. Nothing runs against real systems. Progress resets when you leave or reload.
A fictional team needs a Terraform pipeline for a small internal service. A mature platform repository is offered as a reference. Your task is to choose an approach the team can operate.
Engineering judgment
Stage 1 / 4
Inspect the request
Available evidence
- Task
- Create CI/CD for Terraform. Use the platform repository as a reference.
- Project brief
- Two maintainers, one AWS account, one environment. Resources include a shared bucket with data that must survive deployments. Changes are currently applied locally.
Review the trade-off and try another approach
File length says little about state ownership, access, or destructive changes. Start with the operational constraints.
Supported by the evidence
These answers define the controls the pipeline needs, even with only one environment.
Review the trade-off and try another approach
The brief needs one environment. Adding more would import a requirement the project does not have.
Start with constraints
A small project can still carry significant risk. Scope and risk are separate inputs to the design.
Diagnose the reference
Available evidence
- Reference repository
- Eight accounts, regional matrices, remote state locking, federated CI identity, plan review, and a custom cross-team release coordinator.
- Maintainer response
- The new project needs serialized changes and a reviewed plan. There are no regional or cross-team releases.
Supported by the evidence
You preserve relevant safeguards while dropping machinery tied to a different operating model.
Review the trade-off and try another approach
Consistency helps when the underlying needs match. Here the matrix and coordinator add dependencies without solving a stated problem.
Review the trade-off and try another approach
The shared data still needs protection. Fewer resources do not make an unintended destroy acceptable.
Reuse decisions deliberately
Connect each reused control to a constraint. A reference is evidence about another system, not a specification for this one.
Choose the change
Available evidence
- Agreed approach
- The maintainers accept remote state with locking, a scoped CI role, serialized applies, and human review of the plan.
- Delivery constraint
- Only a reviewed plan from the approved revision may be applied. A newer commit makes the old approval invalid.
Review the trade-off and try another approach
The fresh plan may contain unreviewed changes. Approval must stay tied to the revision and plan being applied.
Review the trade-off and try another approach
The team already has a need for controlled, traceable changes. Account count is not the trigger.
Supported by the evidence
The implementation preserves the agreed review boundary without adding a release coordinator.
Make agreement executable
Controls are useful when their behavior matches what reviewers think they are approving.
Verify the outcome
Available evidence
- Trial run
- A harmless change succeeds in a disposable test fixture. The team has not yet exercised a competing run or a changed revision.
- Acceptance criteria
- Prevent overlapping applies, reject stale approvals, and document recovery ownership.
Review the trade-off and try another approach
The happy path does not exercise the controls that motivated this design.
Supported by the evidence
You verify the actual constraints and whether the team can operate the result.
Review the trade-off and try another approach
Matching job counts does not demonstrate safe changes or operational ownership.
Verify the reason for the design
Acceptance checks should demonstrate the required behavior, including the failure paths that matter.
The pipeline has a reason
You chose controls from the project's needs, aligned the approach, and defined evidence of safe operation.
Lesson
Reuse the reasoning behind a reference. Keep the controls your constraints require and leave unrelated complexity behind.
Review the reasoning
-
Inspect the request
Who may apply changes, how state is protected, and what must never be destroyed?
A small project can still carry significant risk. Scope and risk are separate inputs to the design.
-
Diagnose the reference
Keep state protection, scoped identity, and plan review; omit the regional matrix and coordinator.
Connect each reused control to a constraint. A reference is evidence about another system, not a specification for this one.
-
Choose the change
Apply the reviewed plan for the same revision; require a new plan and review if it changes.
Controls are useful when their behavior matches what reviewers think they are approving.
-
Verify the outcome
Exercise competing runs and changed revisions safely, then have a maintainer follow the recovery notes.
Acceptance checks should demonstrate the required behavior, including the failure paths that matter.
Read the accompanying field note
Before implementing, understand the problem
A solution can work and still solve the wrong problem. Notes on context, reference projects, and engineering judgment before implementation.
Related labs
Keep moving while the approach is reviewed
Decide what needs alignment, what you can investigate now, and when a small change can proceed through normal review.
Repair it, or retire it?
Investigate a failing synchronization process and decide whether it still serves a need before rebuilding it.
The ALB with healthy instances and no traffic
Diagnose an AWS Application Load Balancer whose target health check still uses a removed path.