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:
- Teams that deploy completely automatically can get visibility of deployments to one or more environments. You’ll now know what deployments went to production in the last few days, and quickly jump into the specific changes that went out in each.
- Teams that deploy automatically to test and manually to production can have a combined dashboard that shows automated and manual deployments. You can filter down the deployments to just see what went where.
- Teams that are limited to deployments to test and staging can track just these deployments in Bitbucket. For production deployments done in another tool, we’re planning future APIs to support registering production deployments made outside Pipelines.
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 AWS, Microsoft Azure, Google 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.
