What’s new in Bitbucket Pipelines

This blog is part of 12 days of CI/CD, a celebration of all things CI/CD. Click here for more content and stay up to date by following us on Twitter!

We added a number of improvements to Bitbucket Pipelines in 2019, making it a simpler, more powerful cloud native CI/CD tool for all your building, testing, and deployment needs. In the last few months in particular we've worked on simplifying typical workflows and use cases, as well as providing better support for more sophisticated workflows. Here's what's new:

Pull request list in deployment dialog

Code review is a vital part of any development workflow. In both the deployment summary and deployment preview screen you can now see pull requests that were merged, offering better visibility into changes being made and greater confidence into your deployments.

Run pipeline button

You can now run pipelines from the Pipelines list view, making it easier to trigger custom pipelines and automate more actions in your workflow.

Step limit increase

Steps make up the basic structure of your CI/CD pipeline and allow you to build a workflow to build, test, and deploy your code. Previously Bitbucket Pipelines let you configure 10 steps per pipeline, but we removed this limit, giving teams more flexibility to structure pipelines into more logical steps, test against more application versions, parallelize your tests, and more.

Support for 10 deployment environments

When we launched Bitbucket Deployments there were three deployment environments available for use – test, staging, and production. Teams often have CI/CD workflows that utilize environments for all kinds of use cases though, and three weren't enough. To that end you can now set up and configure ten deployment environments to deploy your code, application, or artifacts, and see the status of each.

This upgrade used in conjunction with deployment permissions gives teams both the flexibility to set up a CI/CD workflow to meet their specific needs, as well as granular permissions so that only certain users have the ability to deploy to a given deployment environment.