Interview with Claire Maynard, Head of Product Marketing for Bitbucket Cloud at Atlassian

“Bitbucket Deployments sits next to users’ source code and is configured with a single line of code”

Gabriela Motroc
Bitbucket
Claire Maynard

With the newly-launched Bitbucket Deployments, 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. We talked with Claire Maynard, Head of Product Marketing for Bitbucket Cloud at Atlassian about Bitbucket Deployments and how it brings visibility into all steps of software release process.

JAXenter: The complexity of managing many tools combined with the difficulty of automating the process result in major roadblocks to getting software into the hands of customers quickly. How can we change that?

Claire Maynard: Bitbucket Cloud solves both of those challenges by offering an all-in-one solution for building, testing, and shipping value to customers. Within Bitbucket, users can plan their projects with a built-in Trello board, collaborate on code with pull requests and automatically test any changes pushed with Bitbucket Pipelines. Yesterday we announced Bitbucket Deployments to allow teams to visualize and easily promote your changes between their environments.

JAXenter: What is Bitbucket Deployments and how can it bring visibility into all software release process steps?

Claire Maynard: Bitbucket Deployments is a new way to track, preview and promote deployments across environments. Deployments provides a dashboard where users can see their environments — test, staging, and production – and the current status of each. This includes the last successful deployment, as well as any errors and in-progress deployments. This dashboard provides a single place to see exactly what changes are live in each environment, a central place for everyone who needs to know what’s where in your continuous delivery process.

There’s no need to manage or maintain a separate tool – developers can visualize, promote and troubleshoot deployments using a unified dashboard.

In addition, the dashboard includes a full deployment history with a list of every deployment to each environment. Users can see which build went out, who deployed it, and when it was deployed. The list is filterable, allowing visibility into a single environment or trace a release across multiple environments.

Bitbucket Deployments is the first deployment solution that sits next to users’ source code and is configured with a single line of code. There’s no need to manage or maintain a separate tool – developers can visualize, promote and troubleshoot deployments using a unified dashboard. Very soon, this information will broadcast to the user’s Jira board and automatically transition issues so all the tools (and teams) stay in sync.

JAXenter: Could you give us an example of how Deployments will work?

Claire Maynard: Below is a step by step example of how teams can use Bitbucket Pipelines with Deployments to take code to the customer.

  1. A developer works on a branch in Bitbucket and commits the code back to Bitbucket. This change automatically kicks off a build in Pipelines.
  2. Pipelines runs the build and gives the developer a green build: passed
  3. The change is automatically pushed to the Test environment so the developer can visit the Deployment dashboard and see that their latest change is in Test.
  4. The configuration they’ve set up in Pipelines is that builds are automatically pushed to their Test environment, but manual to staging and production. This allows teams to do any extra manual testing before pushing to production if necessary.
  5. A development manager or release engineer can come to the dashboard and see the latest build in Test. They can see exactly when and who pushed this change to Test. If they open the deployment summary, they can see the list of commits and a full diff of all the changes in that release. Coming soon, they will also be able to see all related Jira issues.
  6. If the development manager is happy with the changes, they can hit a deploy button to push the changes to Staging or Production.
  7. If there is ever an issue with a release, the team can view a full history of deployments. With this complete and detailed history of every deployment, investigating problems becomes much easier. The team can quickly confirm the cause of a bug and roll forward with the fix.

JAXenter: Was there a need for such a feature? 

Claire Maynard: Teams are deploying code faster than ever, thanks to continuous delivery practices and tools like Bitbucket Pipelines that support automated cloud-based builds and deployments. But there’s a catch.

When we talk with teams adopting continuous delivery, we hear how they often struggle to keep track of all the work going through their deployment pipeline.

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.

Teams are deploying code faster than ever, thanks to continuous delivery practices and tools like Bitbucket Pipelines that support automated cloud-based builds and deployments. But there’s a catch.

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.

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.

In each case, teams have to fumble around across different tools to find the information they need. Deployments are going out frequently, but without proper visibility and traceability, the process feels chaotic. This chaos leads to fear. Teams are anxious about making a critical mistake, like releasing a feature that isn’t ready or regressing an important bug fix.

JAXenter: DevOps consultant Paul Reed said in a talk at DevOpsCon that automation can lead you astray. Do you agree with his statement? 

Claire Maynard: Automation is a friend to software development and the only way we can increase efficiencies to ship value faster. But as mentioned above, with automation, teams can often feel overwhelmed because they have to keep track of what’s shipped, what still needs work or if there are any issues. They are fearful that when something is automatically pushed to production, there may be an issue and they won’t know how to find and fix the problem. We can improve this with better visibility and traceability solutions like Bitbucket Deployments, giving teams the confidence to ship often.

SEE ALSO: Automation is the arm capable of doing actions but you also need eyes and a brain — like in the human body

JAXenter: Has automation become a problem of its own self?

Claire Maynard: Automation itself is not the problem. We need automation. It’s the only way we get to speed. However, this focus on speed without a discussion on how to control that speed responsibly is where the problem lies.

We’ve all seen (or given) presentations 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.

Similarly, Bitbucket Deployments gives teams the controls, the visibility, and traceability for software delivery at speed.

Thank you!

asap

Author
Gabriela Motroc
Gabriela Motroc is an online editor for JAXenter.com. Before working at S&S Media she studied International Communication Management at The Hague University of Applied Sciences.

Comments
comments powered by Disqus