Several months ago, we released Bitbucket Pipelines Beta to offer a unified and centralized software development workflow for teams looking for continuous delivery solutions within Bitbucket Cloud. Since launch, we’ve gotten a lot of great feedback, and many have benefited from moving faster without losing product quality. In this post, we’ll provide a deeper look at the technical details of Pipelines that makes it such a valuable tool for teams.
Read on to learn more about Pipelines and our latest feature addition, team variables.
Configuration as code for reproducible environments
Getting started with Bitbucket Pipelines is easy. You can enable it in one click and define the build commands your team wants to run in a bitbucket-pipelines.yml configuration file that’s placed at the root of your repository. Bitbucket Pipelines will then start building your commits automatically and publishing the results straight into Bitbucket on every push. Having your team’s pipeline configured as code living in the source code repository not only makes it easy to modify your pipeline but also ensures that the build configuration is aligned and evolves together with the code.
The configuration file will also enable your team to define different build configurations per branch. This way you can seamlessly integrate your build automation with the branching workflow your team is using. Run your unit tests on all of your feature branches and let Bitbucket Pipelines deploy your app when changes are pushed to your production branch.
pipelines:
branches:
master:
- step:
script:
- echo "This script runs only on commit to the master branch."
feature/*:
- step:
script:
- echo "This script runs only on commit to branches with names that match the feature/* pattern."
- npm install
- npm test
production:
- step:
script:
- echo "This script runs only on commit to the production branch."
- pip install awscli
- aws --region us-east-1 s3 sync site s3://my-bucket
Save time with fast development feedback
Fast development feedback plays an important role in continuous delivery. It helps by detecting test failures and deployment issues earlier in the process, which leads to shipping products faster. Since Bitbucket Pipelines is built within Bitbucket, it starts building your changes as soon as you’ve pushed them. While your build is being executed, you can track the progress with the logs streaming in real time. In case of a failure, logs will automatically expand the command that failed so you can quickly tell or make a strong guess about the root cause. The build status is also visible at all other places you care about: on commits, branches and pull requests.
When reviewing a pull request you can immediately see your build status in context and click through to find out more about the test failures – all without leaving Bitbucket.
Also, with the latest updates to the Bitbucket dashboard you can now easily filter out pull requests that have failing builds. This way you will avoid wasting time reviewing the code that broke tests. You can instead focus on reviewing the code that actually passed automated quality checks while the broken builds are being fixed.
Use Docker as a build environment
Bitbucket Pipelines uses Docker containers, which makes it possible to create flexible build environments. Docker uses versioned images to define these environments and you can specify the Docker image Bitbucket Pipelines should use when setting up your bitbucket-pipelines.yml file.
As an example, if you have a Node application, select the node:5.10 Docker image as the environment in which Bitbucket Pipelines builds should run:
pipelines:
default:
- step:
script:
- npm install
- npm test
You can also create your own Docker image for a fully customized build environment if none of the available Docker Hub images match your build requirements. Bitbucket Pipelines supports both public Docker repositories as well as privately hosted registries.
Apart from the flexibility benefit of running builds in Docker, it is also easy to spin up a Docker container locally. This will allow you to locally reproduce the exact build environment in which your Bitbucket Pipelines builds are executed. Such reproducible build environments can be a huge time saver when debugging failed builds. All you need to do is to spin up the Bitbucket Pipelines build container locally and study the result.
Newly added team variables to Bitbucket Pipelines
We’ve recently added team variables to Bitbucket Pipelines. Prior to adding this feature, if one had to block the access of a specific team or individual to a certain repository, they had to go with per repository access level variables which was repetitive and very time consuming, especially for bigger teams. If there were any changes (i.e. AWS keys), every single repository had to be updated one by one. Team variables make it possible to set up credentials once and for all. They make it possible to create environment variables at the team level and share or reference them in individual projects.
Above are only few of the many features of Bitbucket Pipelines (Beta). This is a big step forward towards the future of development tools in the cloud that are ready to use with a simple click and no infrastructure requirement. Sign up for early access to Beta!
