From too slow to too fast: learning to manage deployments

Work smarter, better, and faster with weekly tips and how-tos.

Fifteen years ago nobody complained about shipping features too often. Today some teams have a different problem. New features are rolling out from the 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 waiting. We prepared a media kit that was shrink-wrapped and mailed to customers. In this 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.

Balancing speed and control

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 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 has introduced its own 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.

Announcing Bitbucket Deployments

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

There’s a lot waiting for you in Bitbucket Deployments. Click here for deeper information on its features.