Cellane
commented
4 years ago I’d want to follow-up on the original idea with a similar issue, and I possible solution proposal (whose viability I didn’t have time to test 😭). I recently finished configuring CircleCI for a new project with a workflow that works something like this:
- when PR is opened against the
developbranch, runterraform fmt -check,terraform validateandtflint, and once all three succeed, calculate Terraform plan against the development environment (using Terraform workspace, and different-var-file), save the plan for future applying, and notify the changes by commenting on the PR, as well as sending a message on Slack; on merge, apply the changes to the development environment only; - similarly, when a PR is opened against the
stagingbranch, perform all actions against the staging environment;masterthen affects the production environment; up to this point, I think my setup is somewhat similar to what @hossein-rasi is describing; - the only difference, I suppose, is that each branch should really contain the same code, just in different versions at a time – as in, changes should “bubble” from
developthroughstagingtoproduction, and the only difference should be input variables and of course, state file.
After I spent two days fighting with CircleCI’s quirks, I never want to do that again 😅 (What kind of CI system allows you to set the project to only build on a commit which has a PR associated to it, but then doesn’t trigger a build once the PR is merged and closed? 🤯)
And that’s when I found Atlantis and realized that perhaps, I could’ve spent the past two days in a much better way. One thing that I’m not seeing in the documentation, however, is how I could achieve the “Git flow” setup that I described above… but what I see are a few pieces of the puzzle that when put together, they could perhaps help?
What I’m asking is… I’m sorry for the long introduction, but would the following setup have a chance to work for me or would I run into some other traps that it would be difficult to get out of?
- I don’t think Atlantis workflows can be triggered based on the base branch (or did I miss that?). That leaves me with a workaround of using computed environmental variables and custom commands, like so:
- In
atlantis.yaml, define a single workflow for all three branches/environments. -
The first step in the
planaction would look something like this:- env: name: CUSTOM_WORKSPACE command: | if [ "${BASE_BRANCH_NAME}" == "master" ]; then echo "production" elif [ "${BASE_BRANCH_NAME}" == "staging" ]; then echo "staging" elif [ "${BASE_BRANCH_NAME}" == "develop" ]; then echo "development else # echo "Where are you merging into?" exit 1 fi - The second step would then be
init, the third step would switch the workspace to the value generated in the first step, and all of this would be followed by a rather simple adjustment of the standardplanstep:- init - run: terraform workspace select $CUSTOM_WORKSPACE - plan: extra_args: ["-var-file", "${CUSTOM_WORKSPACE}.tfvars"] - Finally, similar adjustments would have to be done to the
applyphase.
I’m sorry for asking for a consultation like this, but I’d be incredibly grateful to hear opinions/improvements/traps, and especially any warnings if I am proposing something impossible (perhaps variable interpolation in extra_args is not possible?)
lkysow
hossein-rasi
dcatalano-figure
Matroxt
hasland
Does atlantis support GitHub multi-branching strategy? What we need is to use separated git branches which consists of different terraform configuration for different evironments (like dev,staging,production) and need to use atlantis to do terraform plan whenever a pull request opened to the specific branch. This means there is no common branch like master which carry all the configurations. I couldn't find any specific branching strategy for atlantis and would be great if you can let me know whether it is possible or not? Thanks!!