Internet Explorer is no longer supported. Many things will still work, but your experience will be degraded and some things won't function. Please use a modern browser such as Edge, Chrome, or Firefox.

Feature Branches

view on GitHub

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:

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:

buildmaster-git-featurebranch-pipeline

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.

buildmaster-git-featurebranch-build

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

buildmaster-git-featurebranch-deployint

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:

buildmaster-git-featurebranch-deployprod

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/*:

buildmaster-git-featurebranch-repomon

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:

Retention Policy Field Recommended Value
Purge item type: Build
Application: «your-application»
Pipeline: «feature-pipeline»
Purge options: [ ] Only purge builds in deployed releases
[X] Only purge rejected builds
Keep builds for: 14 Days
Retention options: [X] This retention policy is active