Build trust in your deployment workflow with deployment permissions

Deploying to a production environment always comes with risk. Nobody wants to break their customers’ trust by accidentally deploying the wrong code, especially in critical systems.

Bitbucket Cloud allows you to configure deployment permissions so that only certain branches or people can deploy to production, helping reduce this risk. In this blog we’ll work step-by-step through setting up deployment permissions for a feature branch workflow with Git, however this example can also be applied to other workflows. We’ll also look at how the Bitbucket Pipelines team’s deployment workflows ensure that our code meets necessary standards, without slowing us down with unnecessary overhead.

Feature branch workflows

With a feature branch workflow developers start a feature by creating a branch from the master branch. Once their work is ready they can merge their code back to master, usually via a pull request. Master can then be deployed to a staging and production environment using Bitbucket Pipelines.

An example bitbucket-pipelines.yml that matches this workflow is:

pipelines:
  branches:
# This pipeline runs when a new commit is pushed or merged to the master branch.
    master:
      - step:
          name: Build and Test
          script:
            - ./build-and-test
      - step:
          name: Deploy to Staging
          deployment: staging
          script:
            - ./deploy-to-staging
      - step:
          name: Deploy to Production
          deployment: production
          trigger: manual
          script:
            - ./deploy-to-production

# This pipeline runs for any branch that is prefixed with "feature/". 
# This is where developers do the actual work - e.g. feature/DEV-30
    feature/*:
      - step:
          name: Build and Test
          script:
            - ./build-and-test

Learn more about setting up Deployments with Bitbucket Pipelines.

Configuring deployment permissions

For this example we’ll set up permissions so that only repository administrators can deploy to production. This is useful if the person deploying needs to have a strong understanding of the deployment process, i.e. knowledge of follow up operations, handling data migrations, or rollback procedures.

Setting up admin restrictions is easy. Simply go to the Deployments section of the repository settings and select the environment you want to restrict deployment access to.

With this configuration now only those with the most knowledge of your process and dependencies can trigger a deployment to production.

Maturing your workflow

One of the key benefits of the feature branch workflow is ensuring your master branch meets quality requirements and is in a deployable state. Code review is a great way of ensuring this, as well as running CI builds on your feature branches. By requiring all deployments to run off master you know that newly deployed code has been verified for quality, reducing the amount of things that need to be checked before a deployment is started.

The first step for this is to ensure that deployments can only happen from the master branch. This can be done through the Deployments section of the repository settings.

Now that we can only deploy to production from master, we want to ensure the branch always has code that meets our quality requirements. To do this we can enforce rules that all code has been reviewed and has passed our CI tests. This can be set up with Branch Permissions in the repository settings.

We can create a new Branch Permission with the following options:

1. No user can write directly to the master branch. Master can only be written to via pull request.
2. Two merge checks:
   • A pull request must have at least one approval.
   • A pull request must have a successful build.
3. Merges are prevented until the merge checks have been met.
4. Approvals are reset whenever the source branch is modified.

Streamlining the dev cycle

Teams practicing Continuous Delivery know their master branch is always ready to be deployed. Automated deployments, reliable monitoring, and feature flags all provide confidence that a deployment will be successful. Having this additional trust removes the need to restrict who can deploy to certain developers, especially those that are also operating their own services. Greater trust in your process and your team allows you to deliver value to your users and respond to incidents faster.

Teams that have trust in their automation to provide deployment confidence can opt to remove the admin-only restriction for their production deployment. Instead they can rely on the master branch meeting code quality standards through the use of branch permissions and other automated quality checks as part of their deployment pipeline. This is how the Pipelines team’s release cycle works, enabling us to release multiple times a day with the confidence of deploying code that meets our strict quality and compliance requirements.

Getting started with deployment permissions

While this post has covered an example using feature branching, it’s easy to configure deployment permissions and merge checks to other development workflows. Deployment permissions are part of our Premium tier in Bitbucket Cloud, focused on features for teams that require extensive admin controls, security and auditing capabilities.

Not on the Premium plan? Find out more about the great features available and upgrade today!