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.

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:

Running automated tests, then building your validated app as a Docker image and pushing it to a container registry

Building and pushing a Docker image to a registry, then manually triggering a pipeline to deploy it to ECS or Kubernetes

With service containers (described below), build, tag and push a Docker service in one pipeline, then pick it up as a dependency to test in another.

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

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 announceservice 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:

Service containers are started and stopped automatically alongside your pipeline, minimizing the necessary configuration of these services compared to other systems.

All containers share the same network interface, so there’s no need to map ports between your build and service containers like you might in other environments (e.g. those using docker-compose).

With Docker Hub hosting many versions of all the popular open source services, testing your software against different versions of dependencies is much easier in Pipelines than in any build system that requires you to provide your own images.

“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.”

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:

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.

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.

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.

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.

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.

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:

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.

Before

After

Look and feel – Users had feedback about Bitbucket’s fluid width, iconography, lack of color and whitespace. Theyexpected 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!

Before

After

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.

Before

After

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. Usertesting.com 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 + ?`

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 bitbucket.org, 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.

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. stanford.edu). 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!

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!

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.

Anywhere you can add issue key links, such as commit messages, comments, pull requests, and branches, you can now see JIRA issue details to stay coordinated between code and related JIRA issues. Sign up for Bitbucket and connect JIRA to take advantage of saving time on the back and forth.

When building software, you often find yourself navigating to different tools, littering your browser with tabs just to stay on top of the information you need. It happens so frequently that you’re likely not even aware of it. Over time, these unnecessary actions all start to add up, sapping your productivity and focus.

Wouldn’t it make more sense to bring the relevant information you need into context so that you don’t have to navigate away from your work? That’s why we’ve added JIRA issue details within Bitbucket Cloud, so you never need to navigate away from Bitbucket to get context on an issue.

Stay in context

Click on a JIRA issue key link from within Bitbucket and see the details of the issue.

This makes it easier for you and your team to stay coordinated between code and related JIRA issues. Anywhere you can add issue key links, such as commit messages, comments, pull requests, and branches, you can now see JIRA issue details, in context. Only Bitbucket allows you to have your JIRA information at your fingertips – no other code repository tool can provide this functionality.

If you need to make edits or view further information you can easily click on the View Issue in JIRA link at the bottom.

There’s more to come

Over the next several months, we’re adding more functionality so you never have to leave Bitbucket, further speeding your development cycle.

Look forward to:

Editing the available fields that are shown

Adding comments

Transitioning issues into a new status

Get started

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.

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).

Configuring SSH access to servers for your builds and deployments on Bitbucket Pipelines used to be a real pain. We had a manual process that involved generating keys locally, then base64 encoding them to pass through environment variables in your build. You also needed to add hosts to the SSH known_hosts file so various commands didn’t fail with cryptic error messages. We saw an opportunity to make this experience a whole heap better.

Improved SSH configuration for Pipelines

We’ve designed a new configuration screen for your Bitbucket repository that lets you generate and configure SSH keys for your pipelines with a single click. The private key will be encrypted, kept securely within Bitbucket, and automatically registered in your pipeline build container. You then simply copy/paste the public key on to your remote host to give your build access to it.

Adding your remote hosts to the known_hosts file in your build is just as easy. Type in the hostname and Bitbucket automatically pulls down the host’s public key, and lets you verify the fingerprint. If everything looks is okay, add your hosts to the configuration with a single click.

With these small improvements, configuring SSH access for Pipelines now takes just a few seconds instead of half an hour of error-prone tweaking.

Alpine is a very lightweight Linux distribution that weighs in at an insanely small 5 MB, so using it in your build can shave a significant amount off the download and startup time. However, Alpine was incompatible with Pipelines because we had a dependency on the bash shell.

Bitbucket Pipelines was originally designed to require bash, which isn’t included in Alpine. But with a few tweaks on our side, we now fall back to using /bin/sh when /bin/bash isn’t available. These changes allow customers to use any Alpine-based image for their build container in Pipelines.

Haven’t tried Bitbucket Pipelines?

Bitbucket Pipelines is a continuous delivery service built right within Bitbucket so you can code, test, and deploy from a single tool with a unified workflow. There’s no need to switch to another application, no need to juggle permissions and access, or setup servers – just use Bitbucket Pipelines and get unlimited concurrent builds.

Every time you trigger a build in Bitbucket Pipelines, whether by pushing commits or creating a pull request, you have to remain at your desk or constantly refresh your email to see if the build has passed. You don’t like wearing the cone of shame for a failed build and would like to get notified ASAP asynchronously.

Introducing HipChat notifications for Bitbucket Pipelines

Many software teams use HipChat to share ideas and stay connected regarding their team’s latest commits, pull requests, or the latest meme. If you are one of those teams, we’ve added a long-awaited HipChat integration with Bitbucket Pipelines. Now get feedback even faster with build status updates via HipChat.

Enable HipChat notifications for Pipelines

To enable HipChat notifications for Bitbucket Pipelines, follow these three simple steps:

Go to your Bitbucket team or repository settings page and click HipChat integration.

Under the section Notify the room with activity in these areas, select the boxes for Started, Successful, and/or Failed.

Voila! you are good to go…

Haven’t tried Bitbucket Pipelines?

Bitbucket Pipelines is a continuous delivery service built right within Bitbucket so you can code, test, and deploy from a single tool with a unified workflow. There’s no need to switch to another application, no need to juggle permissions and access, or setup servers – just use Bitbucket Pipelines and get unlimited concurrent builds.

The Bitbucket team are excited to announce a brand new integration with Unity Cloud Build, just in time for GDC 2017!

Traditionally, game builds are compiled, tested, and packaged by developers via their IDE or another tool provided by the game engine SDK. This is sub-optimal as it wastes developer time and resources, excludes non-technical contributors from building the game, and requires builds to be uploaded and hosted somewhere to share with other team members. The situation is even worse if you target multiple platforms with your game, as you’ll need to create separate builds for each platform.

Fortunately, Unity Cloud Build provides automated builds and continuous integration for your Unity projects hosted on Bitbucket. Bitbucket’s new Unity Cloud Build integration improves this experience by allowing you to jump quickly from your source code in Bitbucket to a built, playable version of your game or app.

Once the integration is enabled, Unity build logs and artifacts are posted to Bitbucket as build statuses, so you can jump from your source code in Bitbucket to a playable version of that same code with a single click. The integration automatically creates a sharable link for each game artifact, allowing any team member to access builds for the latest version or historical versions of their game – without having to wait for a developer to cut a build for them.

Your project, your platforms

Unity Cloud Build supports a range of target platforms including Android and iOS games and apps, desktop games for Windows, macOS, and Linux, and WebGL builds for the web! In fact, for WebGL builds, you can click straight from your code in Bitbucket to an interactive web player and play your game without having to download a build yourself.

Unity Cloud Build platforms, February 2017

Unity Cloud Build statuses will appear against their corresponding commits, branches, and pull requests in the Bitbucket UI. This makes it simple to:

get the very latest version of your project by clicking the build at the tip of your master branch;

play code changes while you review them, by clicking on the latest pull request build; or

check whether an earlier version of your game exhibits a particular bug, by clicking a build on a historical commit!

If a build happens to fail, no game artifacts are generated, but a handy link to the build logs will be displayed instead so you can quickly debug the failure and get your project building again. Speaking of failed builds, Unity Cloud Build statuses are fully integrated with Bitbucket’s merge checks which can be optionally enabled to prevent failing code from being merged into master, keeping your game buildable at all times.

We’re at GDC 2017!

The Bitbucket and SourceTree team will be representing at GDC in force! If you want to catch a demo of the Unity Cloud Build integration, score some Atlassian swag, or have any questions about our game development tools: come and find us at Booth #336, South Hall Zone 2.

I’ll also be giving a talk – Collaborating on Unity Projects with Git – at 4pm in Room 3014, West Hall. It’ll feature the new Unity Cloud Build integration, alongside some tips for versioning Unity projects in Git, handling large assets with Git LFS, and Git workflows for game dev teams. Looking forward to seeing you there!