Gitflow-style Workflows With Destination Branches
Any workflow
A goal of Terrateam is to fit into your workflow, no matter what it is.
Terrateam's default configuration supports a feature-branch into main-branch style workflow well. But sometimes more complicated workflows are necessary. For example, Terraform code might live in the same repository as application code and need to follow the lifecycle of an application code change.
GitFlow
One common workflow for applications is GitFlow (opens in a new tab).
In short, GitFlow has developers branching their features off of develop
,
and merging them back into develop
. Then when they are ready to release,
they merge into a release/<version>
branch. The release branch can get
bugfixes before it is completed. Once done, the release branch is merged
into main
and develop
, and main
is tagged with <version>
.
Finally, in the situation where a hotfix needs to be made, a branch named
something like hotfix/<descritpion>
is merged directly into main
, which
is then merged back into develop
.
To put this another way, we need to support the following pull requests:
feature/*
intodevelop
develop
intorelease/*
release/*
intomain
hotfix/*
intomain
main
intodevelop
In this example, the pull requests we want Terraform to perform operations are pull requests (2) and (3).
To express this in the Terrateam repository configuration (.terrateam/config.yml):
destination_branches:
- branch: 'release/*'
- branch: 'main'
source_branches: ['hotfix/*']
This configuration specifies that Terrateam should operate on any pull request
that has a destination branch that matches release/*
and any pull request that
has a destination branch of main
and the source branch matches hotfix/*
.
See the documentation on destination branches for more information.