Document changes with required issue keys in Bitbucket Cloud

By on May 16, 2017

“Why was this change made again?” Issue keys referenced in commit messages help answer this question by providing a link with more context around why a particular change was made. They’re useful for everyone from new team members getting their bearings with a repo, to quality engineers reviewing the latest release, or a budding startup getting back to their weekend project.

Issue key references are so important that some teams need every commit to include a reference. These teams rely on issue keys to maintain diligent documentation or to automatically generate release notes or changelogs to verify every change. Historically, they could do this with pre-commit Git hooks on each developer’s machine to validate messages, but this solution adds a layer of overhead that becomes difficult to manage. For these organizations, we’re introducing the ability to require issue keys for commits in Bitbucket Cloud.

Required issue keys in Bitbucket Cloud

Requiring issue keys ensures each change links to an issue in commit messages. Bitbucket automatically converts mentioned issue keys (e.g. ‘PROJ-1234’ or ‘#1234’) into links to your issue tracker so it’s easy to stay coordinated between a change and its backstory.

Issue keys aren’t just a reference. They can be used to automate workflow actions: you can add comments or transition an issue to a different state just by mentioning it, making it easier for your team to go back historically for validation of changes. If you combine this with the new JIRA issue details view, you can view and comment on JIRA issues without even leaving Bitbucket. As a result, including issue keys has become a best practice and requiring them in commit messages will make it easier to scale your workflow.

Get started with required issue keys

If you’re new to Bitbucket, sign up for a Bitbucket Cloud account. If you’re an existing Bitbucket user and are already using JIRA Software, make sure it’s connected to Bitbucket. This connection enables Bitbucket to automatically link to your JIRA Software issues. If you’re using the Bitbucket issue tracker, issues are already linked automatically.

Then, navigate to the “Links” section of your repository settings and enable “Require issue keys in commit messages.”

Once enabled, Bitbucket will only accept pushes to your repo if all pushed commit message contain issue keys.

Once all commit messages include keys (e.g. using interactive rebase to update the message), the push will succeed, and the issue keys are automatically linked across Bitbucket, like in this pull request.

Try Bitbucket, it’s free

Not using JIRA Software and Bitbucket together?

JIRA Software is the preferred issue tracker of over 350,000 Bitbucket teams. Teams who have JIRA Software and Bitbucket integrated release 14% more often and close 23% more issues (when compared to teams using just one of those products).
Learn more.

Have more specific questions about this post? Reach out to us on Twitter to get the information you need.

#Forthecode that does amazing things.

By on May 9, 2017

Bitbucket’s mission is to help teams solve real-world problems and accomplish their unique goals to change the world. Our customers select Bitbucket because it supports professional teams building things with a purpose. We get inspired hearing about all the ways our customers are using our products to move our world forward.

We want to share what you’re doing with the rest of the world. Join our #Forthecode program and share your company’s mission and all the hard work done to accomplish it.

#Forthecode contest

Share your company’s mission for a chance to be featured on our blog, our social media channels, and win some pretty cool swag! 

How to enter:

Click on the Tweet button below and tell us how you’re using @Bitbucket to accomplish your company’s mission with the hashtag #Forthecode.

For example, Atlassian’s mission is to unleash the potential in every team. We would tweet: “@Atlassian uses @Bitbucket #Forthecode that unleashes the potential in every team.”

To kick us off, check out some of the awesome ways our customers are using Bitbucket to accomplish their mission.

@Trulia uses @Bitbucket #Forthecode that finds your next home.

Bitbucket helps Trulia on large-scale agile development to provide home buyers and sellers essential information about the real estate market.

@Splunk uses @Bitbucket #Forthecode that makes big data, easy. 

Bitbucket helped Splunk transition to Git and develop software that makes big data scalable and usable.

@Orbitz uses @Bitbucket #Forthecode that takes you on your next vacation.

Bitbucket helped Orbitz migrate to Git to develop the world’s leading online travel site.

What will your code do?

Tell us how you’re using @Bitbucket to accomplish your mission using hashtag #Forthecode or give Bitbucket try today!

Try Bitbucket, it’s free

Introducing code aware search for Bitbucket Cloud

By on May 2, 2017

Code aware search

Save time combing through usage results with a semantic search that ranks definitions first over usages or variables names. Sign up for Bitbucket Cloud to take it for a spin.

Get started, it’s free

The search for code search is finally over: Bitbucket Cloud is launching code aware search, specifically built for teams who have many repos or large code bases.

What makes Bitbucket Cloud’s search “code aware”? Rather than simply indexing your code as text, we built a semantic search that has our systems do the grunt work for you. Bitbucket Cloud analyzes your code syntax, ensuring definitions matching your search term are prioritized over usages and variable names. Assuming your team is re-using code effectively, the ratio of usages to definitions will increase as your codebase grows, making this a big time saver on larger projects.

For example, if you search for “FastHashMap”, which document would you want to appear first?

public class FastHashMap {
   /* ... */


public class SomeOtherClass {
    public void doSomething() {
        FastHashMap fastHashMap = new FastHashMap();

You’d prefer the class definition, right? Let’s take a deeper look at how we built our code aware search to provide the most relevant search results at a fast pace.

How code search works in Bitbucket Cloud

Search indices built using traditional text indexers will usually return the usage result first because it contains a higher number of exact matches for your search term. In code bases where the same class or function is used many times, developers are often left trawling through page after page of usage results trying to hunt down the definition.

We took a different approach: by boosting the definitions matching your search term, the result you want is likely to rank much higher (usually #1) in the search results. Our algorithm boosts definitions for a wide range of type categories including classes, functions, enums, structs, and interfaces.  We prioritized building a code aware search scoped to team and user accounts over a global search functionality. This way, we hope to quickly give our users the relevant results they want instead of the hassle of checking out a repo locally and searching using an IDE.

To compare this live, you can search for the common class “QueryBuilders” on the Elasticsearch repo. In GitHub, it shows up as the 6th result on the 18th page (at time of writing). In Bitbucket Cloud, the class definition shows up as the first result.

Languages, filters, and operators

Code aware search outperforms traditional search approaches for statically typed languages like Java that tend to repeat type names when importing, declaring, and instantiating types. However Bitbucket Cloud’s code aware search is also highly effective for a range of other popular languages including JavaScript, Python, Ruby, and PHP, among others.

Since code aware search is built for source code, we also index  . and _ that are commonly used in identifiers. This means you can get more precise results for compound search terms such as class, function, and variable names like “foo_bar.baz”.

Additionally, we allow you to restrict search results by using modifiers and operators. You can use modifiers to filter by a particular language or file extension (like “ext:css” or “lang:ruby”) or limit search to specific repos (repo:elasticsearch). Projects can use operators (like AND, OR, and NOT) to narrow down or broaden results in case you get too many.

For a full list of the capabilities and search query considerations with code search in Bitbucket Cloud, check out our documentation.

Try Bitbucket Cloud’s Code Aware Search

If you’re ready to use a fast and relevant code search, sign up for a Bitbucket Cloud account, create a repository, and index your code. If you’re already a Bitbucket customer, you can find code search in your sidebar and further documentation on it here.

Get started, it’s free

Have more specific questions about this post? Reach out to us on Twitter to get the information you need.

Bitbucket Server 5.0 & Bamboo 6.0: Bringing DevOps to the Enterprise

By on

According to our recently released DevOps Maturity Report with xMatters, 43% of respondents in organizations of 1000 or more said they either didn’t know of or didn’t have a DevOps initiative in place. With proven benefits like faster time to market and better release quality, why aren’t more enterprises embracing DevOps?

The answer is simple: changing the way teams work isn’t easy. For teams of all sizes, the journey to DevOps can be fraught with roadblocks. For those in the enterprise, challenges like lack of visibility, deep-rooted cultural silos, disconnected tools, and complicated compliance requirements are magnified, making DevOps adoption nearly impossible.

For years, Bitbucket Server and Bamboo have been tackling these challenges, helping software teams build better software faster. Today we’re taking it up a notch with Bitbucket Server and Data Center 5.0 and Bamboo 6.0, giving development teams the freedom, speed, and automation they desire while meeting the demanding needs of their enterprise organization.

DevOps for the enterprise

Adopting DevOps in the enterprise is more than just better communication across operations and development, modern continuous integration practices, or the type of version control in place. Things like compliance and scale become just as important. Tooling must provide freedom and structure, scalability and performance – things that are not often found together.

Atlassian tools have the unique ability to make DevOps workflows a reality while ensuring traceability, availability, and security all remain intact. In Bitbucket Server and Data Center 5.0, and Bamboo 6.0 we’re upping the ante with a committer verification Git hook and updates to smart mirrors.

Committer verification

Git and distributed version control have many benefits out of the box, but controlling access and workflows isn’t one of them. For example, without a Git management tool, a developer can push commits that others have written to the central repository.

This creates problems for organizations with strict security and compliance requirements. Bitbucket lets you address this through permissions and workflow controls including Git hooks. In 5.0, we’ve added a new committer verification hook, which enforces that only the author of a commit can push those changes back to Bitbucket Server or Data Center. Now you can sleep easy knowing that only authorized code changes can make it to your repositories.


Smart mirroring gets smarter

Smart mirroring in Bitbucket Data Center is a hassle-free way of providing geographically dispersed teams a read-only copy of the repository. By pulling updates from a local mirror, teams can avoid the pain of high-latency and low-bandwidth clone operations. All authentication, permissions, and updates are controlled by the master data center instance keeping admin maintenance to a minimum.

In Bitbucket Data Center 5.0 we’re introducing authentication caching – a way for end users to maintain mirror access even in the event of short outages. Instead of communicating to the main server for every login event, credentials are now cached on the mirror for 5 minutes at a time. If network connection is patchy or the main server is offline, users can still fetch/clone using the cached credentials. You can rest easy knowing that Bitbucket Data Center’s active-active clustering, disaster recovery, and now authentication caching ensures your code will always be available.

Productivity at scale

With DevOps, development teams boost productivity through workflow automation, tighter communication across teams, and easier access to information (e.g. build and development status on JIRA issues and pull requests). Bitbucket Server & Data Center 5.0 and Bamboo 6.0 bring these key elements to the enterprise with more transparency and modernization of the release pipeline.

Bamboo Specs

First up, we’re modernizing the way builds are configured with Bamboo Specs, the ability to define Bamboo plan configurations as code. Changing build configurations no longer requires edits in the Bamboo user interface, instead configurations can be stored as code. Beyond simplifying application build, defining plan configurations as code provides benefits such as code reuse, proper code reviews, versioning, and so on. The best part? Bamboo Specs is native to Bamboo, no plugins or additional duct tape required.

Bamboo Specs

Did you know you can use our Bamboo Specs exporter feature to automatically create a Spec out of your existing plans? Learn more

Tighter integrations between Bitbucket Server and Bamboo

Next up we’re breaking through silos and introducing tighter integrations between Bitbucket Server, Bamboo, and JIRA Software Server. Development teams already benefit from tracking work items through JIRA Software to commits and pull requests in Bitbucket Server, and builds and deployments in Bamboo.

Traditionally, the link between JIRA Software and Bitbucket has been on the commit level (i.e. commit A pertains to JIRA issue ABC-123). In Bitbucket Server 5.0 we’re adding repository level shortcuts allowing teams to connect a repository to any related asset, like a JIRA project. Repository shortcuts make it easy for everyone on the team to find and jump to repository information. Simply link to your JIRA board, Confluence space, Bamboo plans, HipChat room, or whatever else that’s important to you.


Bamboo’s integration with Bitbucket Server is also getting an upgrade. Currently, we display build status (e.g. pass/fail) on related commits, branches, and pull requests in Bitbucket Server, but teams were unable to see Bamboo builds in-progress or trigger builds on pull request creation. With the addition of in-progress build status and pull request aware builds in Bamboo, developers gain more control over when their builds kick off and can monitor progress from inside Bitbucket. This frees up Bamboo build agent resources and cuts down on unnecessary build noise. Even better, if you’re not using plan branches already, now you can, and know that every pull request will get built. For more information on all of the Bitbucket Server and Bamboo integration enhancements, check out our integration guides.

PR aware builds

… there’s room for some fun too

Productivity at scale isn’t all integrations and workflow. In Bitbucket Server & Data Center 5.0, let your team know how you really feel with emoji and HipChat emoticon support for comments. To look for the perfect emoji type ” : ” which brings up the list of available options.

Making DevOps in the enterprise possible

Changing the way your teams work, adopting new tools, and learning new technologies is hard and doesn’t happen overnight. When you add disconnected tools, complicated compliance requirements, and scalability to the mix it makes “going DevOps” that much more difficult. No matter where you are in your DevOps journey, Atlassian provides the guidance and tools to help you succeed. If you’re ready to modernize your version control and continuous integration practices, give Bitbucket Server/Data Center and Bamboo a try.

Download Bamboo 6.0


Download Bitbucket Server 5.0

  For more information on other improvements and bug fixes in Bitbucket Server & Data Center 5.0  and Bamboo 6.0 check out our Bitbucket and Bamboo release notes.

Continuous deployment of a static website with Bitbucket Pipelines

By on April 24, 2017

Guest post

This guest post was written by David Von Lehman from Aerobatic, a simple yet powerful solution for static website publishing.

In this blog post we’ll look at how to use Bitbucket Pipelines to automatically build a website using a static site generator. This example will use Jekyll, but the same formula will work with any generator including Hugo, Middleman, Pelican, Gatsby, and many more. We’ll automatically deploy the built site to Aerobatic, a dedicated static website hosting platform. Finally we’ll explore how to combine the capabilities of Bitbucket, Pipelines, and Aerobatic to enable a production release workflow based on branches and pull requests that is optimized for teams.

Step 1 – Create new Jekyll site in Bitbucket

Create a new Jekyll site locally. We can do this by simply running the jekyll create command.

$ jekyll create
$ bundle install

To verify the site builds correctly locally, you can run jekyll serve and take a look at http://localhost:4000.

Now that we have a website, create a Bitbucket repo and push up the code. Our sample repo is named jekyll-pipelines. The full source code available at

$ git init
$ git remote add origin ssh://

Make sure the _site directory appears in the .gitignore file. Since Bitbucket Pipelines will be building the site from scratch, we don’t want the build output in source control.

Ok, now go ahead and push to your repo:

$ git push -u master

Step 2 – Setup Aerobatic

In this tutorial, we’ll be deploying our Jekyll site to Aerobatic, a specialized static website hosting service. It just takes a minute to get up and running:

Now we need to create an Aerobatic website for this repo. At the root of the project run the following command:

$ aero create --name jekyll-pipelines

To keep things consistent, I’m naming the website the same as the repo. This will create a file called aerobatic.yml that you’ll want to commit to Git.

Before running the pipeline, we need to set the AEROBATIC_API_KEY Pipelines environment variable. Environment variables can be set either at the repo level or the account level. We recommend setting it at the account level so you don’t have to repeat this step for future projects.

Retrieve your API key by running the following:

$ aero apikey

Paste it into the value box and click the Secured box.

Step 3 – Create bitbucket-pipelines.yml

Now we need to configure Bitbucket Pipelines to build our Jekyll site whenever a push is made. First make sure to enable Bitbucket Pipelines on your repo and create a new bitbucket-pipelines.yml file. Since Jekyll is Ruby based, we’ll want to specify a Docker image that has Ruby and Bundler already installed. Aerobatic has published an image to Dockerhub called aerobatic/jekyll that has Ruby already installed along with the necessary low-level libraries required to build most native gem extensions. You can checkout the Dockerfile at

Speaking of Docker, there are 3 Aerobatic images available on Dockerhub: aerobatic/jekyll, aerobatic/hugo, and aerobatic/node. Each is based off the ultra-small Alpine base image and has the aerobatic-cli pre-installed avoiding each Pipelines build from having to npm install it from scratch.

Here’s the entire bitbucket-pipelines.yml file:

image: aerobatic/jekyll
  depth: 1
     - step:
           - '[ -f Gemfile ] && bundle install'
           - 'echo "url: https://__baseurl__" >> _config.yml'
           - bundle exec jekyll build
           - aero deploy --directory _site

The script section is the actual set of commands that will be carried out inside the provisioned Docker container.

  1. The first line with run bundle install if a file named Gemfile exists (which in our case it will).
  2. The second line appends a value to the _config.yml overriding the url config setting. Even if the URL is defined earlier in the file, Jekyll will take the last value. The value “https://__baseurl__” is a special value that Aerobatic will replace at runtime with the appropriate site URL.
  3. Next run bundler to build the site
  4. Finally deploy to Aerobatic by running aero deploy. The –directory site option tells it that the files to deploy are located in the _site directory where Jekyll wrote the generated site to. Normally aero is installed by running npm install aerobatic-cli -g, but since we are using the aerobatic/jekyll image, it is already present.

Step 4 – Trigger a build

That’s it for setup, now let’s trigger a build. Commit the bitbucket-pipelines.yml to your repo and that should trigger your first build. If all goes according to plan the log output will look like this:

And just like that, you have a first class git push based deployment workflow for your website. With this setup it’s even possible to use the browser editor to make content updates or author simple blog posts without ever leaving Bitbucket.

Deploying with pull requests

The simple workflow above works great for a site where one or two people maintain the site. But what about a larger team with multiple developers, content contributors, and stakeholders? In agile software development projects, Git pull requests have emerged as the preferred workflow for promoting changes through a series of deploy stages culminating in production. With Bitbucket Pipelines and Aerobatic, this same workflow is easily achieved for static website deployments. Let’s assume the same repository structure suggested in the Bitbucket Pipelines guides:

master Your integration branch
staging Use this branch to trigger deployments to staging
production Use this branch to trigger deployments to production
features/xxx All feature branches


In addition to the production instance of the website, we also need a staging instance. Aerobatic provides a feature called deploy stages that makes this really easy – just pass a –stage option to the aero deploy command.

$ aero deploy --stage staging

This command above will deploy the build output to a URL https://jekyll-pipelines– In the bitbucket-pipelines.yml we use branch workflows to configure a different target stage for the production and staging branches:

image: aerobatic/jekyll
 depth: 1
   - step:
         - '[ -f Gemfile ] && bundle install'
         - 'echo "url: https://__baseurl__" >> _config.yml'
         - bundle exec jekyll build
     - step:
           - '[ -f Gemfile ] && bundle install'
           - 'echo "url: https://__baseurl__" >> _config.yml'
           - bundle exec jekyll build
           - aero deploy --directory _site
     - step:
           - '[ -f Gemfile ] && bundle install'
           - 'echo "url: https://__baseurl__" >> _config.yml'
           - bundle exec jekyll build
           - aero deploy --directory _site --stage staging

NOTE: The Aerobatic free plan is limited to shared * domains, but deploy stages also work with custom domains available on the Pro Plan.

Now the workflow becomes:

Using Bitbucket permissions you can lock down the workflow to whatever degree you like. For example, you can require that staging and master branches must be updated via pull requests, and specify which users have permissions to approve pull requests. A good rule of thumb is to allow everyone to merge to staging, but only senior personnel to update master (and by extension, deploy to production). The screenshot below shows this configuration:

See the Bitbucket Pipelines docs for more details on configuring branch permissions.

Protecting the staging URL

One lingering detail is preventing the general public from stumbling across the staging site URL. This can be addressed via the Aerobatic password-protect plugin that is declared in the aerobatic.yml file:

id: b74e6fb8-e747-4fb4-bd1b-1f92804ace5c
 ignore: []
 directory: .
 - name: password-protect
   stages: [staging]
     password: $PASSWORD
 - name: webpage

The stages property specifies that the password-protect plugin only applies for https://jekyll-pipelines– More details can be found at

Content as Code

Over the last several years there has been a trend within DevOps to manage as much of a software system, including the configuration settings and infrastructure definition, as plain text files committed to version control right alongside the rest of the source code. You may have heard the terms “Configuration as Code” or “Infrastructure as Code” that refer to this approach. Aerobatic encourages the practice via the aerobatic.yml file which defines metadata, deploy settings, and runtime behaviors (such as plugins) for the website.

There’s a strong argument to be made that this same practice should apply to website content including markdown files, images, etc. Rather than locking content up in a CMS database with its own proprietary mechanisms for backups, auditing, history, approvals, etc., just put it in Git or Mercurial and treat it like any other source asset. With the deployment workflow described above, you’ll then have a universal build pipeline regardless of whether the change was committed by a developer or a content contributor.

Now this does present a paradigm shift for content editors that are accustomed to a less techie CMS interface. Fortunately there are a new breed of CMS tools and services that bridge the gap – providing a friendly editing interface but using version control as the underlying data store.  Examples include CloudCannon,, DatoCMS, kirby, and other flat-file CMSes.

Doing More with Plugins

The password-protect plugin is just one of many plugins offered by Aerobatic that provide enhanced functionality beyond what is possible with vanilla static hosting. All plugins are configured in the aerobatic.yml file. Some other popular plugins include:


That’s it – we now have a first rate team based deployment workflow complete with private staging environment, streamlined approval workflow, and fully automated deployments – all with no infrastructure to maintain and no DevOps engineering. Everything is being treated “as code”, safely stashed away in Bitbucket where pull requests, branches, history tracking, and all the other benefits afforded by version control can be applied. This includes the site html, templates, css, JavaScript, configuration, and content.

This same setup works not only with static site generators like Jekyll or Hugo, but also sophisticated single page web applications such as React or Ember. You can learn more about continuous deployment of static sites with Aerobatic and Bitbucket over on the Aerobatic blog.

Happy coding (and deploying)!

Bitbucket Pipelines now supports building Docker images, and service containers for database testing

By on April 18, 2017

Bitbucket Pipelines gets advanced Docker support

We developed Pipelines to enable teams to test and deploy software faster, using Docker containers to manage their build environment. Now we’re adding advanced Docker support – building Docker images, and Service containers for database testing.

Try Bitbucket Pipelines

Companies love delivering their applications using Docker. According to Forrester, 30% of enterprise developers are actively exploring containers, and Docker is the dominant DevOps tool, with 35% of organizations adopting it, according to a recent RightScale survey. Docker provides a painless method of building and deploying applications as a set of independent microservices, which are scalable and resilient.

We developed Pipelines to allow all teams to test and deploy their software faster, using Docker containers to manage their build environment. Teams save countless hours and headaches by avoiding manual build server configuration, choosing instead from the enormous range of publicly available containers on Docker Hub, or bringing your own Docker image for a custom build environment.

“Software development teams need to move fast, which is why so many are turning to Docker. As companies embrace continuous delivery, testing becomes a crucial part of the development process, not an afterthought. By adding support for Docker in Bitbucket Pipelines, Atlassian is delivering modern software development tools and processes for continuous delivery. With Bitbucket Pipelines, there’s no need to switch to another application to use Docker containers for testing software, and no need to juggle permissions and access, or set up build servers.”
Nick Stinemates, VP of business development and technical alliances, Docker

We’re thrilled to announce support for building Docker images and Service containers in Bitbucket Pipelines. 

Use Bitbucket Pipelines to build, tag and push Docker images

Starting today, you can build your application as Docker containers, benefiting from the portability and minimal overhead of containerization. No need to install an additional plugin or run your own Docker service like in Jenkins or other legacy CI systems – just enable with 2-lines in your bitbucket-pipelines.yml and it just works.

This seamless Docker integration facilitates a whole new set of workflows for Bitbucket teams, including:

Bitbucket is now the only tool your team needs to code, build, test and deploy your applications in the cloud, covering the full lifecycle for teams building with microservices.

“With the ability to build Docker images, we’re able to build and deploy to AWS ECS all from within Bitbucket Pipelines. We were able to accomplish the same workflow that took us 50 hours of Jenkins configuration in only 5 minutes and 15 lines in Bitbucket Pipelines.”
Bernie Lees, CEO at DCBL

Service containers in Bitbucket Pipelines enable flexible container-based testing

Setting up integration testing with a database or other dependency on your build server is usually a mess of configuration files. You might even need to configure additional agents or build Amazon AMI images to get the dependencies up and running for your build. Docker has the potential to make that so much easier, with thousands of pre-built images for commonly used software like MySQL and Redis, and standardized configuration through environment variables.

Today we’re excited to announce service containers for Bitbucket Pipelines, bringing the power of Docker to your test environment configuration. You can now run up to three background services in your pipeline, in addition to your build container, using your own Docker images or any of those available on Docker Hub. This makes it a breeze to set up integration testing with databases like MySQL or PostgreSQL or run other common services like ElasticSearch or memcached.

There are several benefits to how service containers work in Pipelines:

“With Docker and service containers, we now rely on Bitbucket Pipelines for our entire continuous deployment strategy. We can go from a developer pushing to Bitbucket, code tested in Pipelines, deployed to AWS, and live on staging within 5 minutes for the API and less than a minute for web apps and support systems.”

– Chris Knight, CTO at Hevnly, a U.K.-based iOS app that helps individual discover and buy lifestyle products.

Bitbucket Pipelines service containers


Why switch to Bitbucket Pipelines from your legacy build server?

We talk with many companies who are still using legacy build servers like Jenkins and struggling with three big challenges:

  1. Teams spend a lot of time on manual build configuration and managing build agents. This maintenance can be a huge cost to the teams, often including several full time build engineers for larger dev teams.
  2. Using a separate build server presents a big speed bump for developers who need to switch contexts frequently between code and build during their day-to-day work.
  3. The team doesn’t have full control over deploying their releases, leading to manual release steps that are error-prone, encourage riskier less-frequent releases, and slow down the feedback loop between the team and their users.

With integrated Pipelines for continuous integration and delivery (CI/CD), Bitbucket solves these problems and helps your team move faster. Pipelines sits within your codebase and removes the barrier between the team, the code, and the configuration. The configuration is simple and lives in your code, versioned and managed alongside your application.

Bitbucket Pipelines vs Jenkins

With Bitbucket Pipelines, there’s no need to switch to another application, no need to juggle permissions and access, or set up build servers – and thanks to our cloud infrastructure you get unlimited concurrent builds.

Haven’t tried Bitbucket Pipelines?

If you haven’t given Bitbucket Pipelines a try, we’ve extended free build minutes for Pipelines so you can try for free. As always, please tell us what you think of this feature by tweeting @Bitbucket Pipelines.

Try Bitbucket Pipelines

Have more specific questions about this post? Reach out to us on Twitter to get the information you need. 

New integration: Bitbucket Cloud Power-Up for Trello

By on April 13, 2017

New integration with Bitbucket Cloud and Trello has arrived

Attach branches, commits and pull requests to Trello cards, create new branches from cards, and view pull request and build statuses on cards with the new integration. To keep the whole team informed at a glance, start by signing up for Bitbucket, and add the Power-up in Trello.

Get started, it’s free

In case you haven’t heard, Bitbucket has a new family member: Trello. Software teams use Trello to plan and track work via boards, lists, and cards in a flexible way. We have many teams on Bitbucket Cloud who use Trello because it is super fast and easy to get started, great for ad hoc work, and perfect for Kanban, but one thing was missing for these teams: the ability for the whole team to see development status updates in Trello boards and quickly bounce between Trello and Bitbucket.

In order to maximize productivity for these teams who want to see their work at a glance, we launched a Bitbucket Cloud Power-Up for Trello. Let’s take a deep dive in to how to get the most out of the new Trello integration.

Bitbucket Cloud Power-up for Trello

In Trello, Power-Ups give users the ability to make Trello boards functional and customizable. For a software team, Power-Ups move a project forward by keeping all team members in the know. With the new Bitbucket Popwer-Up, you can now alert fellow developers, product managers, designers, etc. on development progress with branches, pull requests, builds and commits on Trello cards. When it’s time to go from product planning to development, the Bitbucket Cloud Power-Up allows you to:

Connect Bitbucket and Trello

There is more on the way for a stronger Bitbucket and Trello integration, but this Power-up is a good start to cut out the back and forth and stay in sync on development progress.

If you’re already a Bitbucket and Trello user, head to your Trello board and add the Bitbucket Power-Up. If you’re new to Bitbucket and want to take this integration for a spin, get started here.

Get started, it’s free

Have more specific questions about this post? Reach out to us on Twitter to get the information you need.

Bitbucket Cloud gets a new navigation experience

By on April 11, 2017

A good user interface gets out of the way and makes it easy for teams to understand, focus on, and complete their work. We’ve been listening to our users on how to improve the navigation of Bitbucket Cloud’s UI and have been hard at work for over a year to address the feedback. Today we’re taking the first step in improving Bitbucket Cloud’s UI and launching a new navigation experience

As part of this new UI, we’ve streamlined navigation to create a more intuitive, warm, and inviting interface. Let’s take a deeper look at how we arrived at this new design, what it looks like and how you can enable it.

How did we land on this new design?

One of the best signals we have to understand our customers is NPS (Net Promoter Score) feedback. We pulled a research team together to sift through thousands of NPS responses to find common pain points and opportunities for improvement. One recurring theme we found was “complexity” – clearly a problem, but tough to address without breaking it down further. So, we conducted qualitative interviews and narrowed down areas of improvement to address perceived complexity:

  • Wayfinding and architecture – Historically Bitbucket has used many interaction patterns for navigation: top bar menu, search box, sidebar, omni-bar, and tabs (oh my!). That’s led to a frustrating user experience when finding features and getting around. To cut out the visual noise and distractions, we’ve combined global and repository-level navigation into the left sidebar. The dashboard and search menus let you quickly jump between all repos, pull requests, and issues you need to manage.



  • Look and feel – Users had feedback about Bitbucket’s fluid width, iconography, lack of color and whitespace. They expected an easy to use and cohesive experience that surfaced the right information at the right time. With the new nav, we removed clutter, use flashes of color and clear iconography to accentuate the important bits. These new interactions are more considerate, straightforward, and guide you to the next step. We’ve got more to do on this front to make the entire Bitbucket experience more consistent and simpler, but we’re excited about this start!



  • Repository navigation – This was unintuitive because icons were not easily understood. There were too many options and the mix of actions and navigation made it difficult to parse. As part of the UI cleanup, we wanted to remove as many of the hurdles between you and your work as possible. To simplify, we’ve grouped repo actions with other actions in the create (plus) menu and kept navigation simple.



How did we test the new UI?

We’ve been testing our design direction from the beginning with actual users to validate and stay on track. was hugely helpful for early signal testing and getting quick qualitative feedback from real users. Building on those positive results, we shipped an initial implementation in Bitbucket in October 2016 to our internal Bitbucket dev team.

Since then, we’ve expanded from just the Bitbucket dev team to hundreds of users, integration partners, and Atlassians and have received overwhelmingly positive feedback. Any UI change, especially one as large as adopting a new navigation paradigm, involves tough calls and tradeoffs. Based on our research and testing, we’re optimistic that people will intuitively understand the new layout and be even more productive with Bitbucket.

Most recent updates

Since we launched the new navigation experience back in April, we’ve been gathering a ton of feedback from our users—the good, the bad and ugly—and we’ve made some updates. So what did we change?

  • Blue color: the contrast of white text on the blue background of the global navigation was causing issues with readability so we altered the blue and lowered the contrast between the blue and white.  You can compare below (old left, new right)

  • Keyboard shortcuts: in the first iteration of our new design, keyboard shortcuts were temporarily removed, but not for long. You can access the guide for all the shortcuts by hitting `shift + ?`

bitbucket keyboard shortcuts

  • Badges for Pull Requests: We originally removed badges for pull requests from the new design because there was a performance hit every time the page loaded. We know this is an important count that many of you rely on, so we’ve placed it in the stats on the repository overview page as an interim step and are continuing to explore ways to surface that information.

  • Access to your teams: Teams are now accessible under your profile picture.


I have feedback on the new Bitbucket experience! How do I give it?

This initial roll out is just the beginning. We’ve started with navigation, updated, and changes are now starting to flow in to product.

Now after all this testing, it is time to get feedback on a larger scale. We’re going to be continuing to improve the UI, the navigation, and all the things. While we do that, we’d love to continue getting feedback. To give us feedback, click on your profile picture and navigate to the “Give feedback” link to give us your thoughts. We’re listening! If you’re not already a Bitbucket user, sign up for Bitbucket to give it a try. Give us feedback and we hope you love the new UI as much as we do.

Get started, it’s free

Have more specific questions about this post? Reach out to us on Twitter to get the information you need.

Bitbucket Cloud: free for student developers and teachers

By on April 3, 2017

Are you a student or teacher?

Store your classwork, distribute assignments, and collaborate on your code. Bitbucket Cloud offers free unlimited collaborators and free unlimited private repositories for all students and teachers.

Already a student using Bitbucket? Join our Student Ambassador Program here.

Get started, it’s free

There are many things a student developer needs to worry about during their college life, but knowing where to store their labs, projects and assignments shouldn’t be one of them. Bitbucket Cloud has offered free unlimited repositories and unlimited collaborators for some time, and now we’ve streamlined the process of getting an academic account. It’s easier than ever for both students and teachers to get started and store, collaborate on, and distribute their classwork using Bitbucket Cloud.

Get up and running with Git, all in the cloud

No more USB drives, emails, or FTP’ing to your college servers for your classwork. You can easily set up repositories for each of your labs or classes with Bitbucket. Better still, your code is hosted in the cloud so you can access your classwork on any machine, anywhere you are. Want to keep your work private, away from prying eyes? We’ve got you covered. With unlimited private repositories you can control who can view your work and only give access to those who need it.

And by using Git you’re getting a head start on your career by learning to use the industry standard for version control. What’s there not to like?

Sharing is caring

Perhaps you need to collaborate on a group project with your team, or give repository access to your professor or TA for grading? Academic accounts on Bitbucket include unlimited collaborators making it easy to do all that and more. Our aim is to make the process of working with your teachers and peers as easy as possible.

Free Academic accounts for all students and teachers

Best of all, Academic accounts on Bitbucket are free. That’s right, free as in beer… without the age requirement of course! To get free unlimited repositories and collaborators, all you need to do is sign up for a Bitbucket account with your academic email address (e.g. We’ve automated the process so when you sign up you’ll instantly be given an Academic account. And don’t worry if it’s not automatic – simply fill out this form and our team will get you up and running in no time. We’re always adding approved academic institutions to our list, so over time we hope to have this process automated for as many institutions as possible.

Share and win!

We’re excited to help student developers all over the world learn, collaborate and share their code with Bitbucket Cloud, and we want you to help spread the word. Share our student developer page with your friends on Twitter and Facebook and be in the running to win some sweet swag. Don’t forget to use the hashtag #bitbucketedu so we can keep track!

Join our ambassador program

As we expand our student initiatives we’re proud to announce our upcoming student ambassador program. If you’re interested in learning more about Git, love attending events, and exploring opportunities for your peers and universities, then we’d love to hear from you. Register your interest here and we’ll be in touch!

Get started today

Edit history with Mercurial Evolve (Beta) in Bitbucket Cloud

By on March 28, 2017

Mercurial patch queues (MQ), even though they are deprecated, have long been the only way to share your not-yet-ready-to-land commits via Bitbucket. Patch queues have a long history of being thorny to use because they were developed for version control techniques that have been out of date for quite some time. Rising from the ashes of Mercurial patch queues and forged from the painful experience of “git push -f”, we are launching evolve in hopes of providing a better experience for Mercurial users. 

What does this mean for you? You’ll be able to edit the history for a pull request before merging it. You can rebase, if that’s your fancy. Plus, this paves the road for us to enable new merge options, like our new squash merge in pull requests.

Where to get evolve

After calming down a bit, it’s important to note that evolve is still in Beta in both Mercurial and Bitbucket. To facilitate rolling out this Beta feature as we do our other features in Bitbucket, we decided to write an extension to make integrating Mercurial’s configuration with our per-user labs settings. I call this magic hgenvconfig – a very simple extension that even has tests! (For the technically curious: the way “hgenvconfig” works is by adding our per-user configuration to an environment variable. Our Mercurial extensions and hooks are then able to read from this variable by the fact that subprocesses inherit environment variables from the main thread.)

With this extension, we were able to add evolve to our lab settings so we can help get evolve hardened for all Mercurial users. Our hope is that as this gets more testing, evolve will move out of experimental status in Mercurial. We need your feedback on terminology, UX, and bugs (of course). To start using it, first install evolve by running “pip install hg-evolve” then head to your account settings, Bitbucket Labs, and enable Mercurial Evolution Support.

Getting the most out of evolve

How is evolve different from “git push -f”? For starters, “git push -f” behaves just like your favorite FTP server: last one to write wins. In contrast, Mercurial marks commits as “replaced” by using an append-only store. Let’s see how this works (without getting too technical here):

Figure 1: unsafe history modification with core Mercurial (not using evolve): the original revision 1 is destroyed, similar to git when the reflog is cleaned.

Figure 2: safe history modification using evolve: the original revision 1 is preserved as an obsolete changeset providing more history than git. (The “temporary amend commit”, marked with T, is an implementation detail stemming from limitations in Mercurial’s current merge machinery. Future versions of Mercurial will not create them.)

Similar to “git push -f”, evolve is an advanced feature and editing history is tricky. Evolve is built on the Mercurial concept of phases. In preparation for evolve a little while ago, I switched the default state of new Mercurial repositories to be non-publishing (e.g. draft commits by default).

To get the most out of evolve, make sure to read up on the evolve concept of unstable. Simply put, this is analogous to a “rebase” that is in-progress. It represents, as the name suggests, an unstable state of your repository and should be used carefully. If you stick to “rebase” and “histedit” commands, then it should be rare to end up in this state and be safe to use.

Evolution ain’t easy

In order to help make features like this accessible to the community in the future, including through further development of the Mercurial platform, Bitbucket has made a charitable donation to the Software Freedom Conservancy. We’re proud to support the Software Freedom Conservancy and promote the development of platforms like Mercurial, and encourage you to keep a look out for advancements to come.

If you are new to Bitbucket, sign up for Bitbucket here or if you are already a Bitbucket user, head to your account settings, Bitbucket Labs, and enable Mercurial Evolution Support. It’s time to evolve.

Get started, it’s free

Have more specific questions about this post? Reach out to us on Twitter to get the information you need