Git Flow Model

Description:

I have come to a standard for setting up Github Repos following a git flow model which is an industry supported model as seen with Githubs Official Starter Workflow For Terraform. I will be going over Github Actions in a series of posts but this one will focus on the overall “Pull Request Model” that some people call it.

To Resolve:

1. Basically, the way it works is you have three main branches: feature, develop, and main.

2. In the feature branch, you make your changes to terraform code and push to that branch one, two, or twenty commits. Then, when you are ready to run a terraform plan, you simply trigger a Pull Request to the develop branch.

3. Once the Pull Request has been reviewed by looking at the Github Action’s output for Terraform plan, the approver will click Approve and this will trigger a terraform apply.

4. After the merge, you then repeat by merging develop to main where no Actions run except a check_branch script that we cover in a different post. Main is just a stable working copy of your terraform code.

5. That’s it! Some orgs set it up to where a merge to main will trigger pipelines or some variation of that, but the idea is still the same in most places - you do a PR to a branch which triggers terraform plan and then the acceptance triggers a terraform apply. Here is a visual of how it works:

   • 

6. Here’s the main section of the workflow that controls this:

   on:
   #workflow_dispatch:
   push:
      branches:
         - "develop"
   pull_request:
      types: [opened, edited, synchronize]
      branches:
         - "develop"
   

   • See that we trigger 2 times => One for any “push to develop” which is the same as a merged Pull Request. Next is during an initial Pull Request to develop (“opened” event) or any pushes to the feature branch while the Pull Request is open (“edited/synchronize” events) .

   • If you don’t want your terraform plan to keep triggering, you need to close your Pull Request and make all your changes, and then you can open another one once you are ready.

7. Note that I always leave workflow_dispatch: as an option because sometimes I need to turn off continuous integration to test some things and then turn it back off by commenting it out. You can read more about how I use workflow dispatch in this post.