terraform planfor Terraform) with the source code of a short-lived feature branch with the state and config of the stack that's pointing to another, long-lived branch. Here's what such a notification looks like:
masterbranch in the repository called...
infra. Let's say you want to introduce some changes - define an S3 bucket, for example. What we suggest is opening a short-lived feature branch, making your change there, and opening a Pull Request from that branch to
terraform planwith the new code but existing state and config is reported to the Pull Request. First, we should ensure that the Pull Request does not get merged to master without a successful run, so we'd protect the branch by requiring a successful status check from your stack.
project_rootruntime configuration accordingly. This approach means changing the staging directory a lot and using as much or as little duplication as necessary to keep things moving, and a lot of commits will necessarily be no-ops for the production stack. This is a very flexible approach, and we generally like it, but it leaves Git history pretty messy and some people really don't like that.
stagingbranch linked to the staging stack, and a
productionbranch linked to the production stack. Most development thus occurs on the staging branch and once the code is perfected there over a few iterations, a Pull Request can be opened from the
productionbranch, incorporating all the changes. That's essentially how we've seen most teams implement GitFlow. This approach keeps the history of the
productionbranch clear and allows plenty of experimentation in the
productionbranches in GitHub. To maximize flexibility,
stagingbranch may require a green commit status from its associated stack but not necessarily a manual review. In the meantime,
productionbranch should probably require both a manual approval and a green commit status from its associated stack.
https://api.github.comas the API Host URL.