Continuous Delivery Shouldn't Be Guesswork

Thanks to Matt Ryall, Senior Product Manager with Bitbucket Cloud for taking me through their latest upgrade.

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 to keep up with all the deployments and knowing where things are at.

In teams adopting continuous delivery, you hear questions like:

• What changes were deployed to production yesterday?
• Can I try out this feature in the test environment?
• Who broke the staging environment?

To help you answer these questions and more, Bitbucket Deployments is now available 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!

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 will have a built-in promotion workflow, letting you take a verified build that is running in one environment and promote it to the next:

Clicking the promotion button on the dashboard launches a preview that gives you the information you need to make a decision on whether to promote the release. It shows the full list of commits in the deployment, as well as a file diff. In future, we'll also be including the Jira issues and pull requests.

We've also improved the chat notifications for Stride, HipChat and Slack to keep your entire team in the loop about the releases, once they go out.

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.

From Too Slow to Too Fast: Learning to Manage Deployments

Fifteen years ago nobody complained about shipping features too often. Today some teams have a different problem. New features are rolling out from software teams faster than they and the rest of their company can keep up.

In the past, when a new feature went out, it was a big deal. The whole company knew and the whole company got involved in prepping and getting it launched. Everyone was ready, and often waiting. We did "box shots" where the new release was photographed as an actual box, or prepared a media kit that was shrink-wrapped and mailed to customers. In that era, customers and company leaders complained about products shipping too slowly, and dev teams did whatever it took to make the big launch event deadline. Sluggish, buggy, late and over-budget were common results.

As an industry, we pivoted hard toward speed. Speed mattered above all. We praised the fast teams and admired their ability to ship hundreds or thousands of times each year. We've talked about how fast the "car" can go or how powerful the engine is, as an analogy for how often a team can deploy. But we often failed to focus on the rest of the vehicle and the people in it.

• The brakes, that actually enable us to go faster by providing control.
• The dashboards, that bring all the right information to the right place at a glance.
• The windows, that give you visibility into what is happening outside of your lane.
• The indicators, that enable communication between teams to help them to collaborate better at high speeds.

Continuous delivery and this focus on speed have introduced a new set of problems. Teams with advanced continuous delivery practices and their stakeholders often struggle to keep track of all the work going through their deployment pipeline. Novice teams are worried about making more mistakes, faster. And it doesn't only affect the developers.

• Developers commit changes, then review and merge them into the master branch, but don't know when (or where) those changes are deployed.

• QA engineers don't know whether a change is available in the test environment.

• Product owners know development on a particular feature is partially complete, but don't know which bits are live and which bits still need work.
• Sales and marketing don't know when to announce changes or launch a sales campaign. The new feature can be live before they hear about it.

DevOps engineers responsible for deploying changes can't see exactly what they're about to release to customers, so they just cross their fingers and hit the "go" button.But teams are aiming for the speeds of tomorrow by stitching together the tools and practices of yesterday. Teams throw more tools and integrations at the problem, then have to stumble around looking for the information they need.

That's why we didn't build a separate deployments product. Those already exist but the problems remain.

Instead, we’ve built Bitbucket Deployments and made deployment status visible right next to your source code in Bitbucket. Bitbucket Deployments is a core part of Bitbucket Cloud and it allows teams to track, preview and promote their deployments with confidence.

With Bitbucket Deployments, you can view a summary of the current state of each environment, a full history of every deployment, and a summary of the changes that went out in that deployment. We've also added the option to build manual steps into the pipeline, such as when a deployment moves to staging, or production.

As your confidence levels go up, as your reliability increases, we want you to be able to accelerate. Release faster if the business needs it. Adopt more automation if the business needs it. Or, slow down for a bit to make sure you've got your pipelines running the way your team wants.

Faster shouldn't be the only thing people talk about when praising leading edge software teams. Better software, beautiful software, and meaningful software are good goals too.

With Bitbucket, Bitbucket Pipelines, and Bitbucket Deployments working together as a single product, your build engineer may even be able to start their transition back to being "an engineer". It only takes a single line of code to enable deployment tracking in your Pipelines YAML configuration.