Bitbucket Adds Pipelines

To keep up with competitors like GitLab, Bitbucket introduced Continuous Integration (CI) processing to their service offering and called it Bitbucket Pipelines. Since being introduced in May of 2016, the service is still free, with usage limits being imposed during the beta/trail period.

Since I spent some time working with GitLab and their pipeline processing for my Random Generator project, I thought I would dive into Bitbucket Pipelines to see if it possible for use with a Salesforce codebase that I want to automate.

What Does Bitbucket Pipelines Give Me?

Bitbucket Pipelines introduces Continuous Delivery (CD) seamlessly into Bitbucket cloud-based repositories. According to the lead Product Manager (for Bitbucket Pipelines):

"Pipelines exists within your repository and the configuration is part of the code. You do not need to configure agents or queues and, thanks to Docker, teams can manage themselves their dependencies without having to ask a Build Engineering team to add or configure AMIs for them."

The first step is to enable Bitbucket Pipelines from the Settings | Pipelines | Settings section within a cloud-based Bitbucket repository. Once enabled, there is a wizard that helps build a bitbucket-pipelines.yml (YAML) file into your repository. Experienced team members can simply configure the specified YAML file manually.

As a result, the build configuration becomes part of your repository. When they are executed, they run on an isolated Docker container that is managed by Atlassian. If integration is required as part of your pipeline process, Atlassian already includes an impressive list of tooling to assist. Some well-known products include:

• Amazon Web Services.

• bitHound.io.

• Google Cloud Platform.

• NPM.

• Sauce Labs.

• Sonatype.

This is only a partial list, with more tooling partners to come as the service evolves.

What Are the Limitations?

As a noted above, there are some monthly limits during the free stage of Bitbucket Pipelines:

• Build minutes: Limited to 500 minutes per team member/user (10 users x 500 = 5,000 build minutes).

• Build limits: Each build is limited to 4GB of RAM and 2 hours build execution time.

• Push limits: Pipelines with more than 5 references are not run, to product build minutes.

Additionally, the current functionality is either disabled or not available at this time:

• JIRA integration.

• HipChat notifications.

• Build artifacts stored by Bitbucket (3rd party artifacts repositories will work).

• Building Windows applications.

• Running/building Docker images from user scripts.

• Accessing items from behind a firewall.

These limitations have been put into place to make the still-free service maintainable. In time, I fully expect all the missing features to be included in the Pipeline product.

What About Atlassian Bamboo?

If your development suite includes Atlassian Bamboo, you are likely already benefitting from JIRA integration, HipChat notifications, storage of artifacts, script-based Docker building/running and access to elements behind a firewall. However, the Bamboo process still lives outside the Bitbucket/Stash/git repository and likely involves some level of duplication across projects, tasks or stages.

For those who want to stay on Bamboo, the cloud-based solution is being sunsetted. However, the on-premises product will remain an option - although it might be an interesting configuration if the remainder of the Atlassian suite is in the cloud.

Next Step: My Use Case

I have been working with an implementation of Salesforce which currently utilizes manually updates via the proprietary Change Set process. In the next couple of weeks, I am planning to prototype Bitbucket Pipelines with this Salesforce org and the Force Migration Tool to perform Continuous Delivery in an automated process.

Stay tuned for the next segment in this series.

Have a really great day!