Using Bamboo's deployment projects for fun and profit
There's no such thing as a "devops tool" – but if there was, it would be Bamboo.
Delivering software projects is complicated business at the best of times, particularly when it comes to deploying changes, and there are lots of opposing forces at work. Speed vs. stability. Quality vs. quantity. Transparency vs. efficiency.
The JIRA Software / Bitbucket / Bamboo combo is a great example of how tools can make traceable deployment pipelines possible, with integrations that surface the right information in the right places. Let’s take a closer look at how the connection works, and how Bamboo's deployment projects put some of software development’s fiercest rivalries to rest!
Build meets deploy
Traditional tools are mainly focused on either "build" or "deploy", and do one or the other well. But with Bamboo's deployment projects, you can bring builds and deployments together.
Devops isn't about tooling, it's about collaboration.
Knowing this, we've added features to Bamboo that help devs and sys-admins work better together. First, sys-admins can automate their deployment work using the same tool developers and QA use to automate their build and testing process. They can also see how the artifacts have been tested when assessing risk around a release. On the flip side, testers, developers, and product managers get a window into the Ops world with the ability to see where a version is running right now.
Let's break things down a bit and look at all the pieces, and how they fit together. Creating deployment projects in Bamboo is as easy as build plans. You select Create Deployment Project from under the Create menu, give your deployment project a name, select the build plan and branch you'll be deploying from... et voilà! You've now established a connection between your builds and your deployments.
Next, let's set up your environments in Bamboo (you can have as many as you need). For each environment, you'll define things like permissions and notifications, as well as any dedicated agents. And of course, the deployment jobs that you want to run, with each step represented as tasks – just as you use tasks and jobs in your CI builds. On the deployments side, however, there are tasks for steps like pulling in artifacts, SSH'ing to servers, transferring and unpacking files, and running smoke tests.
Each environment also has its own set of deploy triggers that let you choose whether you want the deployment to be kicked of after a successful build, as a cron job, a push-button deploy, or any combination thereof. Automated triggers run the deployment project when there is a green build on your plan or the branch you selected when creating the deployment project. If you want to wait a certain amount of time before deploying, scheduled triggers (i.e., cron jobs) are there to help. For manual deployments, navigate to your build result summary page and click on that little cloud icon for your target environment, under the actions column.
With your deployment project and it's environments in place, we can now turn our attention back to the stuff that'll get deployed there.
Once your builds and tests are complete, you deploy the artifacts to an environment on your network by converting them into a release, which lets you track its progress through your environments. Bamboo releases act as a container for your artifacts, plus a wealth of related information: commits, JIRA issues, which builds produced and tested the artifacts, which environments the release has been deploy to, and by whom.
Note that although versions in JIRA and releases in Bamboo are not tied together in any programatic or enforceable way (JIRA's versions represent your public-facing releases, while Bamboo's releases are unique identifiers for the builds that are deployed along the way), it's easy to get a complete picture of what happens between any two versions when Bamboo is linked with JIRA. An issue marked with FixVersion “1.3” in JIRA may have been implemented in an application version called “1.3-RC1”, “1.3.0” or even back in “1.2.9”. Click the Deployments link from the Development panel inside your JIRA issue to compare the issue's FixVersion with what's been deployed in Bamboo.
Cause meets effect
Connecting JIRA issues with releases in Bamboo is simple. If you're using JIRA Software, you create a branch using the create branch link inside issues. And assuming you have Bamboo, JIRA, and Bitbucket integrated, the issue will automatically be linked with all commits made on that branch, as well as all the resulting builds and deployments.
Otherwise, if not branching from within a JIRA issue, you can include the issue key in the commit message when submitting the code (something most developers do instinctively anyway). Bamboo will see that key and add it to the list of issues you worked on since the last version. Also, if Bamboo detects a JIRA issue key in a comment posted on the "build summary" page it will pull that JIRA issue automatically and connect it to that build or deployment project.
To summarize all the above... When Bamboo, JIRA Software, and Bitbucket are integrated, your issue key goes to Bitbucket when you branch from within JIRA, all Bitbucket repository details travel to both Bamboo and JIRA, and all build and deployment status gets transferred from Bamboo back to JIRA and Bitbucket. It's a helluva round trip – thank goodness the tools do all the linking for you. Each member of your team can look in their preferred tool and understand how the project is coming along.
Dev meets ops
In addition to cross-pollinating dev- and ops-centric information by way of deployment projects and releases, Bamboo makes it easier for teams to communicate about release readiness. First, being able to comment on releases means the team can share thoughts on what was found during testing or what infrastructure changes might be needed to release it. Unlike email, comments are fully democratic – everyone can participate, regardless of whether they were included on a send list – and create an open record to refer back to later.
Second, each release can be flagged as Approved or Broken. An approval communicates the sign-off from QA, while a broken flag alerts Ops that a release may be delayed, and spurs devs into action.
Speed meets control
With per-environment permissions in Bamboo, you can automate deployments to any environment, while still having control over who can initiate those deploys. For each environment, you can set permissions for users and groups that control who can configure a deployment job, who can execute it, and even who can view the deployment information for each environment. With the right set of permissions in place, developers and QA can self-service deploys to the lower environments, while production and other sensitive environments stay locked down.
Bamboo was the first tool of its kind to give deployments the first-class treatment. It's a true continuous delivery tool, that can walk you through the delivery process from code to deployment. I've summarized a metric ton of information here, so be sure to refer to the docs for more details as you set up your deployment projects and environments.
on a related note...
Bamboo, Docker, and building web apps
A practical use case scenario that combines the power of Docker containers with Bamboo’s strong Docker features for building and deploying a web application. Check it out.
Put it into practice
Continuous delivery from code to customer
Bamboo is a continuous delivery tool that ties automated builds, tests and releases together in a single workflow. Take the tour to learn more.