Feature Branches

Feature Branches are one of Git's most powerful features, allowing developers to independently code new features without interfering with other development. Once the new feature's code is ready, it's reviewed and then merged into the main code using a "pull request".

Integrating feature branches into your CI/CD pipeline can be challenging, and in this article we'll discuss:

• Creating feature branches in Git that work best with automation
• Using feature branch pipelines in BuildMaster to accommodate these branches
• Monitoring existing and new feature branches to create builds
• Cleaning up old builds with retention policies

Using Feature Branches in Git

A "feature branch" is simply a branch that you want to use during the development of a new feature and merge with another branch when completed. For example, if you are creating a feature to allow SAML-based logins, you might do the following.

1. Create a new branch (feature/saml-user-login)
2. Write code and commit the changes to this branch
3. Push the branch to your Git server
4. Collaborate with other developers and testers to finalize the code
5. Create a "pull request" to merge the code in main
6. Review the code and merge the pull request together

For many teams, build automation (continuous integration) is an important part of step 4, and the feature is often tested with a build automatically created from the feature branch.

Using Feature Branches in a CI/CD Pipeline

To test the in-development feature, builds are often created from the feature branch as part of the continuous integration process. However, since feature branch builds should never be deployed to production, they're rarely integrated into a CI/CD pipeline.

With BuildMaster, you can safely automate building and deployment of feature branches without worrying about accidental deployment to production. You can even automatically create pull requests once a feature branch build has been properly tested.

Creating a Feature Branch Pipeline in BuildMaster

BuildMaster includes a Feature Branch Pipeline template that will help you get started. You can customize any aspect of the pipeline you need, or even create the same pipeline from scratch.

The Feature Branch Pipeline template includes three stages:

The first stage (Build) works like most build stages in other pipelines. When you create a new build, you select the feature branch you want, and the pipeline runs your build script.

The next stage (Integration) works a little differently: it will prompt the user to select a target server for deployment:

The final stage (Pull Request) will run a Create-Pull-Request script. If your application doesn't already have that script, the following default script will be created:

Git::Create-PullRequest
(
    Target: master,
    Source: $Branch,
    Title: $PullRequestTitle
);

The $Branch variable refers to the branch of the current build, and the user will be prompted for $PullRequestTitle:

After the build is deployed to the final stage, a pipeline event listener will sets the build status to Rejected, so that it's not accidentally deployed later.

Monitoring Git for New Feature Branches and Commits

You can configure a Git Repository Monitor to automatically create new builds when a new feature branch is created or a commit is detected on a feature branch.

To do this, navigate to Settings > Resource Monitors in your application, then click Add Monitor. After selecting Git Repository Monitor from the list, you can specify a branch filter that uses a wildcard expression such as feature/*:

The expression feature/* will create a build when a new branch that starts with feature/ is detected, or if there are any new commits to such a branch.

If you need to monitor multiple feature branch patterns, just create additional repository monitors.

Cleaning up Feature Branch Builds with Retention Rules

Builds created from feature branches can be purged shortly after they've been rejected.

You can automate purging these builds using a retention policy that's configured like this: