Gitflow-style Workflows With Destination Branches

Introduction

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.

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:

1. feature/* into develop
2. develop into release/*
3. release/* into main
4. hotfix/* into main
5. main into develop

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.