Our team shares a GitHub repository and follows a feature → dev → release → main workflow. Pull requests from feature branches currently trigger deployments to the shared AWS development account. This causes problems when one developer deploys first and another deploys afterward: the later Terraform run can apply an older desired state and overwrite changes that were already deployed, even when the developers edited different files. We also need a way to promote only validated changes to release without automatically including unfinished work that has already been merged into dev. Our CI/CD system uses GitHub Actions and Terraform. What workflow would prevent stale deployments and make release selection safer?
3 Answers
A shared development environment should have a single writer. Pull request workflows should run terraform plan and publish the result for review, but they should never run apply. Run terraform apply only after the pull request has been merged, using the current HEAD of the dev branch rather than the old feature-branch commit. Also require branches to be up to date before merging, and re-run the plan when necessary.
If a feature needs a real AWS environment before it is merged, give it an isolated ephemeral stack, account, or workspace with separate state and unique resource names. Destroy that environment when the work is finished. Do not let multiple feature branches apply against the same shared Terraform state.
For the release problem, treat deployment selection separately from the shared dev environment. Promote a known commit or build artifact, or use feature flags for merged work that is not ready to activate. Otherwise, merging unfinished work into dev naturally makes it part of the branch's combined state.
Add a GitHub Actions concurrency group for the development environment so applies are serialized instead of running at the same time. Configure queued jobs to wait rather than cancel an active apply, and have each job create a fresh plan when it starts. Terraform remote state locking is still important, but locking alone only prevents simultaneous writes; it does not stop a stale feature-branch plan from applying older desired state.
This also avoids people jumping ahead in the deployment order. The deployment workflow should be triggered by the merge or a push to dev, not by opening or updating the pull request.