Pipelines stocking stuffers: test reporting, Docker run and large builds

By on December 20, 2017

We’ve recently added a few tasty new features to Bitbucket Pipelines that we wanted to share with you before the holiday break. Here’s what Bitbucket Santa has put under the tree for our good Pipelines customers this December. (Naughty customers should close their browser window now!)

Test reporting with zero configuration

We’ve added test reporting to Bitbucket Pipelines, a highly requested feature from our customers. If you’re already generating test reports as part of their build process, you should already be seeing them picked up by Pipelines. They’ll appear in your build results and soon in notifications too.

Zero-config test reporting in Bitbucket Pipelines

As well as making your builds blazingly fast, our goal with Pipelines is to take the pain out of configuring CI/CD builds. To that end, we are always looking for ways to reduce configuration options that bloat and complicate things.

All the other build tools we’ve seen require you to configure exactly where you build stores test reports. Whenever you add a new module to your project, you might need to go back and update this configuration, or remember to set it when you configure a new project.

Unlike these other tools, test reporting in Pipelines requires zero configuration. We automatically scan your build directory up to 3 levels deep for directories matching “test-reports”, “test-results” or similar, then parse the JUnit-style XML files we find there.

This common format is supported and automatically generated by many tools (we’ve seen almost 10% of Pipelines builds pick up test reports automatically), and for tools that don’t automatically generate reports, we have instructions in our documentation.

A few improvements to test reporting are still in progress, like showing steps with successful tests, but we’re happy to make our first iteration available to you now.

Run Docker containers and docker-compose files

We’re also excited to announce that Pipelines now offers complete hosted Docker support, allowing you to build, run and test your Docker-based services in any configuration that doesn’t require privileged mode on the host. This includes using docker-compose to start a set of microservices up for testing on Pipelines.

Back in April 2017, we introduced the ability to build, tag and push Docker images from Pipelines up to your preferred registry. However, due to the security model of the Docker daemons in our shared infrastructure, we couldn’t offer the ability to run Docker containers and related tasks.

Thanks to some innovative work by our engineering team, we’ve extended our Docker authentication plugin to support all Docker commands and still prevent privileged commands being run.

Because we now allow starting arbitrary containers via docker run, we also now enforce a 1GB memory limit on Docker usage on Pipelines that was previously unlimited. You can read more about this change and how it might affect you in our infrastructure changes documentation.

Large builds: double resources for double cost

Ever since we launched Pipelines, we’ve had demand to support ever larger builds. We started offering 2GB of memory by default, and increased that to 4GB shortly after launch. Allowing builds with even more memory is a common request.

But one does not simply increase the resources allocated to customers on a hosted build service. Our default allocation factors in our hosting costs, typical customer needs, and maintaining a competitive price. To offer configuration options for larger builds, our scheduling and auto-scaling systems have to handle builds of varying sizes while continuing to keep queue times to an absolute minimum. Fortunately, the latter is what we’ve been able to achieve.

I’m pleased to announce that Pipelines now offers 8GB of memory, and similarly doubled resources (CPU, network, etc), as a new option for customers. Simply configure size: 2x in your Pipelines YAML file, either globally or on a specific step, to take advantage of this.

Steps that use double resources will consume twice the number of build minutes from your monthly allocation, effectively costing you twice as much. So we recommend configuring large builds only where you need additional memory or speed.

  size: 2x  # all steps in this repo get 8GB memory
    - step:
        size: 2x  # or configure at step level
          - ...

Our early stats show that large builds have decreased the average build time for customers that use them, due to decreased CPU contention on our hosts, but your results will depend on the specific tasks your build performs.

We’re sure the optional extra memory and CPU allocation will prove extremely useful to the growing number of professional teams that are relying on Bitbucket Pipelines for all their CI/CD needs.

Happy holidays!

We hope you enjoy these great new additions to Bitbucket, and thanks to the thousands of new customers that joined us this year.
Please let us know how Bitbucket and/or Pipelines is helping you and your team to build great software. We’re always excited to hear your stories.

Bitbucket Deployments: flexibility meets CD best practices

By on December 13, 2017

We believe development tools are more powerful when they provide flexibility but also steer teams towards the practices that help them succeed. In the design of Bitbucket Deployments in Bitbucket Cloud, we’re using our experience working with thousands of customers to recommend and reinforce the practices we see working for teams in the trenches.

Designed to fit your workflow

Our first goal was to support a wide variety of different deployment workflows, and provide visibility and confidence across all of them:

Regardless of how your team does deployments, we’ve designed Bitbucket Deployments to support your tracking model.

Multi-cloud support: AWS, GCP, Azure, and more

Support for multiple cloud vendors is also part of the Bitbucket ethos, and that includes multi-cloud support with our deployments features.

Bitbucket has deployment integrations with all the major cloud hosting platforms, whether that’s Amazon AWSMicrosoft AzureGoogle Cloud Platform or a Kubernetes cluster. By following these easy guides, you can start deploying today with Bitbucket Pipelines and tracking it through Deployments.

Built-in best practices for CD teams

While we provide a lot of flexibility for teams using Bitbucket Deployments, we also want to have some guardrails that guide teams towards best practices in continuous delivery.

First, we’ve found the “deployment pipeline” approach of deploying the same code (and ideally same build artifacts) to each environment in order dramatically improves the speed and confidence of teams in their release process. Bitbucket Deployments is designed around this idea of helping you progress quickly through each step in your defined release process, rather than jumping around haphazardly.

Second, the use of a “staging” environment is a key part of how many of the best teams work. It is used to validate once-off release changes like database schema changes or data migrations against replicated production data, or as a checkpoint for verification of single service changes in a multi-service environment. We want to encourage teams using push-button deployments to adopt a process that includes a staging environment.

Lastly, we’ve pre-configured the environment names in a way that we believe works for the vast majority of teams, who have test (or UAT/QA), staging (or pre-prod) and production (or live) environments. We want to encourage teams to use one, two or three environments in this pattern. Running different code in more than three shared environments tends be an anti-pattern, leading to developer confusion and an unclear release pipeline from code to production.

You can read more about our approach and best practice recommendations to deployments in our Bitbucket Deployments Recommendations.

Up next in the deployments journey…

If you’ve been following along with the blogs or on Twitter, you’d know that we’ve introduced the new Bitbucket Deployments, dug into some of the features, and now explained how we combine flexibility and best practices.

Next time we’ll look at some of the customers who have adopted Bitbucket Deployments and see what benefits they’re getting from the features already. Follow us on Twitter to be notified when the next post is out.

Confidence to release early and often: Introducing Bitbucket Deployments

By on December 5, 2017

Teams are deploying code faster than ever, thanks to continuous delivery practices and tools like Bitbucket Pipelines. But this has caused a huge problem: it’s hard keeping up with all the deployments and knowing where things are at.

In teams adopting continuous delivery, you hear questions like:

To help you answer these questions and more, we’re excited to announce Bitbucket Deployments in Bitbucket Cloud. Bitbucket Deployments is the first deployment solution that sits next to your source code and can be configured with a single line of code.

Now there’s no need to set up and maintain a separate deployment tool, or scroll through unrelated builds in your CI service to analyze deployments. Bitbucket can manage and track your code from development through code review, build, test, and deployment – all the way to production. (In the future, we’ll be adding integrations with Jira to keep your boards and issues in sync with deployments as well!)

Let’s jump into the specific features to show you how tracking deployments with Bitbucket can help your team move faster today.

Deployment visibility with the new dashboard

Our new Deployments dashboard gives you a single place to see which version of your software is running in each environment, and a complete history of earlier deployments.

Bitbucket Deployments dashboard

Environments in Bitbucket are configured out of the box as test, staging, and production, and your team can choose to use one or more of these environments as needed. The current status shown on the dashboard reflects the last deployment that was attempted to that environment, as configured via the Pipelines YAML file.

Also shown on the dashboard is a full deployment history with a list of every deployment to each environment. You can see which build went out, who deployed it, and when it was deployed. When diagnosing problems, the history list can be filtered to show all the deployments to one environment to trace back and find the offending change.

Tying code and deployments together in the deployment summary

Bitbucket Cloud is now one tool to manage your source code and your deployments, so it’s smarter than the average deployment tool. You don’t have to wonder which code changes went out in a deployment, Bitbucket can tell you!

Here’s what you’ll see if you click on one of the deployments on the dashboard:

Bitbucket Deployments Summary

With this complete and detailed history of every deployment, investigating problems becomes much easier. Your team can quickly confirm the cause of a bug and roll forward with the fix.

Preview and promote deployments between environments

Preventing mistakes is a key part of every team’s deployment process. This is why so many teams still have manual checkpoints in an otherwise automated process. However, these manual checkpoints are more difficult than they need to be, with lead developers trawling through dozens of diffs and PRs to review a set of changes prior to pushing them live.

To help make this easier, Bitbucket Deployments will soon have a built-in promotion workflow, letting you take a verified build that is running in one environment and promote it to the next:

Bitbucket Deployment promotions

We’re also improving the chat notifications for Stride, HipChat, and Slack to keep your entire team in the loop about the releases once they go out. You’ll see Bitbucket Deployments round out with these improvements in the coming weeks.

Get started by enabling deployments in your build

The best bit? Once you’re signed up for Pipelines early access, it’s just a single line of code to enable deployment tracking in your Pipelines YAML configuration.

Check out the example below, where tracking is enabled for test, staging and production deployments:

Bitbucket Deployments YAML example

Please give it a try and let us know your thoughts.


Try Bitbucket Deployments


Stay tuned for more on deployments…

Today we started with a quick introduction to the new Bitbucket Deployments. In the coming weeks, we’ll have a bunch more to share, covering CD best practices and the future of Bitbucket Deployments. Stay tuned!

Excited about this news? Tell us why on Hacker News or Reddit


Bitbucket Pipelines Team

Better repository search and fork discovery come to Bitbucket Server 5.6

By on November 30, 2017

How long has your code base been around? Jira Software is our oldest project at Atlassian clocking in at 15 years old. That’s a lot of code, and more importantly a lot of repositories with the word “Jira” in the name! Our switch to Git, where it’s common to create more repositories with less contents in each, didn’t help the matter.

If you can relate to this phenomenon, then you can probably relate to the struggle of searching for a specific repository or fork in Bitbucket Server today. New in Bitbucket Server 5.6 we’re taking steps to make the data discovery process much easier through improved repository search and fork discovery.

Improved Repository Search

Depending on the number of repositories you have in Bitbucket, finding the specific one you need can be a bit tricky. If you’ve never visited that repo before, then searching for its name may only show a couple of possible results even if there’s hundreds of repos that match your criteria. Sifting through irrelevant lists isn’t exactly what you hoped to be doing with your day, which is why we’re introducing a better way to find repositories in Bitbucket Server 5.6.

Search results are now easier to navigate, revealing more matching repositories in the quick search (located in the header) as well as on the search results page. The ability to filter repositories has also been added to the repository list page.

Repository Search in Bitbucket Server 5.6

Repository Fork Discovery

If your team uses a fork based workflow, you may commonly ask the questions “What repository is this forked from?” or “What forks exist of this repository?”. Until today, it was possible to get an answer only to the first question, leaving you guessing as to how to answer the second.

In Bitbucket Server 5.6 we’re bringing that information to the forefront, by adding a new menu item for “Forks” for each repository. Viewing all the forks in a single place makes it much easier to grok who has been doing what and when.

Fork discovery in Bitbucket Server 5.6

Try Bitbucket Server 5.6

If you’re currently fielding lots of repositories or forks, then Bitbucket Server 5.6 can help. Give it a try today and see how easier data discovery can improve your 9-to-5.

Download Bitbucket Server 5.6

For a full list of updates to Bitbucket Server 5.6, check out our release notes.

New outbound IP addresses for webhooks

By on November 21, 2017

Bitbucket webhooks are used by teams every day to test, analyze, deploy, and distribute great software to millions of people.

In a few weeks, we will be making a change to our network configuration that results in these services routing through different IP addresses. We plan to make this change no earlier than Monday December 11th.

If you’re using webhooks and have firewall rules to allow Bitbucket to communicate with your servers, you’ll need to add the new IPs to your rules before Monday December 11th.

The current source IP address range is (the IP range that is changing has been bolded for emphasis):

The new source IP addresses will be:

As always, you can consult our documentation for the current list of supported IPs for webhooks.

Pipelines manual steps for confidence in your deployment pipeline

By on

Bitbucket Pipelines gives you the ability to build, test and deploy from directly within Bitbucket Cloud. Today, we’re excited to announce that you can now use manual steps in Bitbucket Pipelines. With manual steps, you can customize your CI/CD pipeline by configuring steps that will only be run when manually triggered by someone on your team.

This is a great addition for teams that require some manual process (e.g. manual testing) as a prerequisite to deploying their software. You can simply configure the deployment steps as manual steps, then trigger the deployment once the necessary testing or other activities have been done.

Manual steps can also be used as an optional final step for additional automated testing. In cases where certain types of automated tests are expensive or time-consuming to run, adding them as a final manual stage gives your team the discretion in when to run these tests.

To configure a step in your pipeline as manual, add trigger: manual to the step in your bitbucket-pipelines.yml file. The pipeline will pause when it reaches the step until it is manually triggered to run through the Pipelines web interface.

Below is an example bitbucket-pipelines.yml file which uses manual steps for the deployment steps.

image: python:3.6.3
    - step:
        name: Build and push to S3
          - apt-get update
          - apt-get install -y python-dev
          - curl -O https://bootstrap.pypa.io/get-pip.py
          - python get-pip.py
          - pip install awscli
          - aws deploy push --application-name $APPLICATION_NAME --s3-location s3://$S3_BUCKET/test_app_$BITBUCKET_BUILD_NUMBER --ignore-hidden-files
    - step:
        name: Deploy to test
          - python deploy_to_test.py
    - step:
        name: Deploy to staging
        trigger: manual
          - python deploy_to_staging.py
    - step:
        name: Deploy to production
        trigger: manual
          - python deploy_to_production.py

Manual steps are designed as a replacement for using custom pipelines to trigger deployments, and we’ll be adding future enhancements to support tracking these deployments in the coming months. Custom pipelines remain primarily as the method of configuring scheduled builds, and also for running builds for a specific commit via the Bitbucket API.

For more information on manual steps and how to configure them, check out our documentation. For help configuring Pipelines to perform deployments, check out our deployment guides for your preferred platform.

We hope you like this addition to Pipelines. Happy building!


Learn more about Pipelines


The Jira + Bitbucket integration just leveled up

By on October 17, 2017

Back in March 2017, you gained the ability to view your Jira issues from Bitbucket Cloud, making it much easier to stay in sync with your team without leaving Bitbucket. But this didn’t solve having to visit Jira if you wanted to make any updates to an issue. Developer time is money and we don’t want you to waste it by jumping between Bitbucket and Jira to update, comment, or transition issues. That’s why we’re excited to announce that we’ve brought Jira issue editing power to Bitbucket.

Next time you do a peer review on someone’s code in Bitbucket and you need context from Jira, open the issue right from Bitbucket and add comments, attachments, or even transition the issue to done.

So what’s new?

The latest improvements are all about giving you the ability to update Jira issue information from Bitbucket. Now you can…



What’s next

We will continue to invest in making Bitbucket and Jira easier to use together, further speeding your development cycle. Up next, we are focused on the following items.

How to get started

Ensure Bitbucket and Jira Software are connected. 

If you’re already using issue keys in your commit messages today, simply click on the links to enjoy visibility on Jira issues. If you’re not using issue keys in Bitbucket, try adding one to your next commit message. Type out an issue key that exists in one of your Jira projects, for example, “TEST-123” and voilà, you should now be able to click on the issue keys to view it’s details. Read more about using issue keys in Bitbucket here. 

Having trouble? You may need to reconnect your Jira and Bitbucket connection. Visit our troubleshooting page if you run into issues or contact support.

Not using Jira Software and Bitbucket together?

Jira Software is the preferred issue tracker of over 350,000 Bitbucket teams. We did an extensive study amongst our users and found 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


Add structure to your pipeline with multiple steps in Bitbucket Pipelines

By on October 3, 2017

Bitbucket Pipelines empowers modern teams to build, test and deploy their code directly within Bitbucket. Today, we’re excited to share a huge improvement to how Pipelines can be structured to suit your team’s workflow, with support for multiple steps – the highest voted feature request in Bitbucket Pipelines.

With multiple steps in Pipelines, you can now:


multiple steps in bitbucket pipelines

You can add additional steps to your pipeline by modifying your bitbucket-pipelines.yml file to include another step keyword. Steps are executed in the order that they appear in the bitbucket-pipelines.yml file, and run in separate Docker containers. Each step can be configured to:

  • Use a different Docker image.
  • Use specific caches and services.
  • Produce artifacts that subsequent steps can consume.

Below is an example bitbucket-pipelines.yml file which uses multiple steps.

    - step:
        name: Build and test
        image: node:8.5.0
          - node
          - npm install
          - npm test
          - npm build
          - dist/**
    - step:
        name: Integration test
        image: node:8.5.0
          - node
          - postgres
          - npm run integration-test
    - step:
        name: Deploy to beanstalk
        image: python:3.5.1
          - python deploy-to-beanstalk.py
      image: postgres:9.6.4

For more information on how to set up multiple steps, check out our documentation.

Now that we’ve added support for multiple steps, you might be curious about whether we’ll support running steps in parallel or manually on-demand. Good news! This work is a stepping stone for us to add support for manual steps and parallel steps in the near future.

So stay tuned for more improvements to Bitbucket Pipelines to meet the needs of your team. If you haven’t tried Pipelines, get started today and improve the way your development team works.


Powering Enterprise DevOps with Bitbucket Server 5.4 & Bamboo 6.2

By on

Bitbucket Server and Bamboo

Implementing DevOps practices in large or highly regulated organizations is a balancing act. How do you make your development and operations teams as productive as possible, improve the flow of work moving throughout the system, and maintain the scale and security required? The answer is to choose tooling that can do it all.

Bitbucket Server 5.4 and Bamboo 6.2 bring powerful new features to support your DevOps workflows at scale. From improving your flowand developer productivity to providing the scale to run continuous integration across an entire organization, Bitbucket and Bamboo have you covered.

Read on to learn more about new features including Bamboo Specs for Bitbucket Server, project level permissions in Bamboo, and upcoming additions to Bamboo’s licensing model.

Improving your flow

One of the 3 underlying principles of DevOps is flow, a key ingredient to reducing development risk and shortening release times. Optimizing for flow means understanding and improving how changes move through your systems, how teams interact with that data, and how quickly the data can get from point A to point B.

Bamboo Specs for Bitbucket Server

Bamboo Specs (a.k.a configuration as code) speeds up your ability to make plan changes on the fly and in bulk. New in Bamboo 6.2, we’re introducing Bamboo Specs for Bitbucket Server: the ability to store your spec file in linked Bitbucket Server repositories. Changes made to spec files stored in Bitbucket are automatically propagated to your Bamboo builds, saving time by updating your development pipeline alongside your codebase. Plus, by storing your specs in Git & Bitbucket you get the added benefits of code reviews, version tracking, and the ability to rollback at any time. All of this means higher quality build plans and faster changes.

Bamboo Specs for Bitbucket Server

Bamboo smart mirror support

For distributed teams, smart mirrors have been a huge time saver. The ability to clone repositories that are located geographically closer to teams can cut down on hours of idle development time. Now this saved time can also be enjoyed in builds too. Simply choose a mirror when configuring an integrated Bitbucket repository in Bamboo and it will take care of the rest. Even with co-located infrastructure some customers see the use of smart mirrors as an appealing way to spread out the effect of spikes of activity from armies of build agents.

Smart Mirrors in Bamboo

Webhook support in Bitbucket Server

Flow isn’t limited to your build pipeline, it encompasses your entire development workflow. With new webhooks support in Bitbucket Server 5.4, it’s easier than ever to integrate with the 3rd party tools that make up your DevOps toolchain. Webhooks are configurable through the Bitbucket user interface at the repository level. If you’re using some custom tooling to track work, webhooks can be sent for specific events, such as when a commit is pushed, a pull request is created, merged or a comment is added.

Webhooks in Bitbucket Server

Contributing guidelines in Bitbucket Server

Developers often work on multiple projects and dependent libraries in their day-to-day lives, and sometimes it’s hard to know what the rules of engagement are for each. Any given repository might have a different standard for the definition of “done”, for branch naming conventions, for pushing commits, and for getting contributions reviewed and merged. Contributors might forget a requirement, have to interrupt a project owner for details, or have their carefully crafted change rejected for not complying. Work slows down when standards aren’t clearly defined and visible.

Bitbucket Server now supports contributing guidelines files in addition to the existing support for showing README files. Simply add a CONTRIBUTING markdown or text file to your repository that documents the guidelines for contributions. Your clone dialog, create a pull request screen, and view pull request screen will then automatically display a link to this file.

DevOps at scale

Translating DevOps techniques from concept to reality is hard enough. Throw in the additional challenge that enterprises experience doing this at scale, and you may have an actual mountain left to climb. When it comes to version control, Bitbucket Data Center does a great job supporting those needs, but what about continuous integration and delivery?

What do you do when your development teams are generating so many build artifacts your CI/CD server can’t keep up, or you’re running so many concurrent builds that you’ve hit your maximum build agent capacity? Or perhaps you have so many build plans it’s become quite troublesome just to configure permissions. Until today, the answer was “you can’t do much.” Now with Bamboo 6.2 new project level permissions, artifact handlers and dependency proxies, and new, larger agent tiers, these worries can become a thing of the past.

Bamboo project level permissions

With the addition of a brand new role, called Project admin, permissions in Bamboo can now be thoughtfully applied at the project level. This allows Bamboo administrators to delegate some of their responsbilities to those who are in charge of the projects themselves, or apply permissions more broadly across many build plans. Not only does this lighten the burden of managing a large amount of users, but it’s great for those organizations who have strict compliance or security requirements around access controls.

Project Permissions in Bamboo

Supporting massive scale

Bamboo 6.2 also introduces artifact handlers and agent bootstrapping proxies, both are ways to decrease the load on your Bamboo server while adding the ability to support greater scale. New options for storing your build artifacts include Amazon S3 and NFS effectively transferring the load of archived binary files from Bamboo to servers specifically built for storage. Similarly, agent proxies decrease the reliance on your Bamboo server by caching and loading agent dependencies from a proxy.

Artifact handlers in Bamboo

Both of these new features mean more builds, more concurrent processes, and more code releases are possible. Ensuring all organizations, regardless of how large, can implement modern CI practices is extremely important to us. The positive impacts that come from testing and automation cannot be ignored – things like faster release cycles, higher quality code, and empowered development teams. This is why we’ve placed an emphasis on scaling Bamboo, and will continue to do so. For those who are pushing the boundaries of what their CI/CD servers can handle, we’re extremely excited to give you a sneak peak into what’s to come: 500 and 1,000 agent tier updates to our Bamboo pricing. With 1,000 build agents at your disposal, build queuing is reduced and more concurrent processes can happen at once, which ultimately helps you release more code, more often. Availability of these new agent tiers is coming soon.

…One more addition, GVFS support in Bitbucket Server

Microsoft recently announced a new open source project that they’ve been using internally for improving developer productivity when it comes to very large monolithic codebases in Git. GVFS (Git Virtual File System) virtualizes the file system underlying Git repositories on developers’ machines (currently Windows only), making more efficient use of bandwidth, space and computation by only working with files that have been accessed. At Atlassian, we’ve been pondering and observing similar problems, and while it doesn’t affect a great many software teams, it’s a real thing for some. The announcement of GVFS piqued our interest, and we soon followed up with GVFS support in SourceTree, our free Git GUI, for those that use a supporting host like Visual Studio Team Services. Since then we’ve explored the possibilities for our Git hosting tools, and have now released an experimental add-on for Bitbucket Server and Data Center that provides the server side support needed for those wishing to use GVFS for their development.

Like GVFS itself, it’s early days for this add-on, but if you work on large repositories, we’d love for you to take it for a spin and send us your feedback.

Powering Enterprise DevOps

As DevOps practices become the new normal, the importance of well connected version control and continuous integration is clear – they’re vital to implementing modern development workflows. Bitbucket Server and Bamboo provide the flexibility, control, and scale needed to do just that. Give them a try today and see how they can transform the way your team works.

Download Bitbucket Server 5.4


Download Bamboo 6.2

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

Say Trello to boards in Bitbucket Cloud

By on September 13, 2017

Your team just came up with a great new idea for a feature, product, Airbnb for dogs, whatever it is….it’s amazing (naturally) and you’re ready to get started. But often building a product feels like chaos with so many spreadsheets, emails, chats, bugs, features, releases, and more. Keeping track of it all seems impossible. Wouldn’t it be nice if you had one place where your whole team could plan requirements, assign tasks, start coding, collaborate, and deploy to your customers? If you didn’t have to fumble around deciding where you’re going to document user stories and requirement details? And what if you could bring your designers and marketers into the conversation instead of having to collaborate with them through a separate medium?

Well, now you can! With Trello boards in Bitbucket Cloud, spin up a Trello board and get your entire team on the same page, instantly. 

If you haven’t heard of Trello, well, get ready to get work done, fast. Trello’s boards, lists, and cards let you organize and prioritize projects in a fast, flexible way. Trello is one of the worlds most popular project planning and collaboration tools, and it’s now a core part of Bitbucket’s experience. Already, 14% of Bitbucket customers use Trello for planning their software projects, and we’ve made it even easier for teams to plan and track in the tool they already know and love. Give your team a shared workspace that takes you from planning to deploying with hackathon speed – for free.

Why use Trello boards in Bitbucket?

Everything in one place

With boards in Bitbucket, you now have one place for planning, tracking, collaborating on code, testing and deploying. Developers save time by never bouncing between multiple applications and losing context to find their next piece of work. You don’t have to add and configure user permissions in a separate tool because access to Trello boards can be set based on Bitbucket’s repository permissions. Keep work moving fast by having everything and everyone organized in one tool.

Simplify your workflow – create branches directly from cards

Plan projects on a Trello board and get to coding quickly by creating a branch straight from a Trello card. Create a pull request in Bitbucket and attach it to a card to keep everyone in the loop on the status. Pick your next card from a prioritized backlog on the board and move cards through your workflow to ensure all work is complete.

Get project status at a glance

Quickly understand the status of the team’s work in a simple, digestible view without navigating around Bitbucket to find related work. Gain total traceability with branches, commits, and pull requests all associated with cards on the board. Even see build and pull request status from the front of the card with color-coded card badges that help you recognize if there are any issues. Daily stand-ups are a breeze with information like status updates, code reviewers, and more all within the details of the card.

Collaborate with your team – no coding skills necessary! 

PMs, engineers, designers, and marketers and many more contribute to the success of your product team. Extended teams now have a common language and workspace to collaborate on projects without needing to understand Bitbucket. Everyone can have one view of all their work without switching between multiple applications. Product teams can prioritize tasks and get perspective on the work getting done, and non-technical teams, like marketing, can see what’s shipping and share it with customers.

The Trello integration with Bitbucket makes it easy for our developers to collaborate with our marketing team who want a fast and simple tool. They have access to our development backlog and can quickly add things like bugs, feature requests, or changes to the website.” – Alex Brown, Sr. Web Developer from Lushusa.com

We launched Bitbucket’s Trello Power-Up back in March. If you haven’t already, make sure to install it to take advantage of the full integration.

Using Bitbucket? Here’s how to get started

Trello boards are now available on all repositories in Bitbucket. Just navigate to a repo, click on the board menu item in the sidebar, and get started. If you already have a Trello account, you can select an existing board from the drop down or create a new board. If you want to have more than one board, go to the repository settings and attach a second or third board.

Need some inspiration? Use a Trello board for agile development, bug tracking, a product roadmap, sprint retrospectives and more. Check out some of Trello’s engineering use cases.

Using GitHub? 

This is a great reason to try Bitbucket.

  1. We have Trello integrated – obviously! Marketers and Designers don’t want to learn how to use GitHub issues.
  2. Bitbucket has integrated CI/CD with Pipelines, so developers don’t spend time doing maintenance on Jenkins servers and GitHub integrations. With built-in Pipelines, see the status of your builds right in your repo. Take your code from testing to deploying in seconds.
  3. Bitbucket offers free unlimited private repositories. Nice!
  4. And, best of all, get all of this for around 25% of the cost of GitHub.
  5. Try it all for free (even premium features) for 30 days. No credit card required. Import your repo 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.