Shipping a new feature always brings a mixture of emotions, no matter your role in getting it out the door. The sense of accomplishment is sweet, albeit tempered by the knowledge that there are so many cool things that aren’t shipping in this iteration… but you also get that spike of anticipatory excitement when you think of shipping those cool things in future iterations. The whole thing is like chipotle-spiced dark chocolate with PopRocks (this actually exists, and should be its own food group).
So it goes with Bamboo’s deployment capabilities, which we started shipping this summer. And today life is a little sweeter because we’ve just delivered Bamboo 5.2 with a much-requested enhancement that we’re very excited about indeed!
Deploy directly from branches
Each team has its own workflows around branching, so we’ve made branch deployments very flexible in terms of the use cases they cover, and the mechanics of making them happen. The primary use cases I’ll cover today are:
- Deploying a development branch to a low-level environment for testing
- Using a release branch model, rather than releasing from master (or trunk)
- Deploying from long-lived branches that contain the supported versions of your product
Automatically triggering deploys from feature branches
Dev branches for user stories and bug fixes are a great way to push changes to your repo, thus enabling CI to run against them, without subjecting the rest of your team to broken builds and test failures while the work is in progress. Most teams who use feature branches don’t ship from them, but do deploy that code to internal environments for exploratory and performance testing. With branch deploys in Bamboo, you can configure the deployment trigger for any environment to automatically deploy the artifacts built on a given branch – either at scheduled intervals, or with each successful CI build of that branch. Isolation and automation: definitely better together.
You can even use the two trigger types in combination. Let’s say you have a shared environment dedicated to performance testing. Throughout the day, deploy master there whenever it builds successfully – for most feature branch teams, builds of master are usually the result of new work being merged in, so you’d want a gut-check on performance right away. Then overnight when the repo is idle, schedule deploys from each developer’s branch at appropriate intervals so everyone gets performance feedback on their work at least once a day. (Recall that deployment jobs can conclude with a script, Ant or Maven task that kicks off performance tests.)
Releasing from a release branch
For those of us less bullish on branches, putting work in progress directly on the main code line and occasionally cutting a release branch is more appealing. While master or trunk gets deployed to the test environment, release branches are the ones you deploy to staging, and ultimately production. Each build you deploy has a rich and flavorful set of changes – the dark milk chocolate (say, 55% cacao?) of branching strategies, if you will.
This pairs nicely with the create release button found throughout each deployment project. You want a human decision around when to cut and deploy a release candidate, rather than an automated trigger.
Shipping updates to supported versions
If you don’t live in the SaaS world, you probably have to support multiple versions of your software simultaneously, and occasionally ship critical fixes, back-port security updates, etc. This means maintaining version branches for a very long time – years, most likely. These branches are usually deployed to a common location, like a website or external repository, where customers can pull down updates to the versions they’re using. Like a super-dark chocolate, this branching strategy is very powerful in the right situations.
In this case, you’ll have a very specific build that you want to ship. It’s not like the previous case where you’ll deploy several release candidates to staging before promoting live. For these branches, the best way to turn builds into releases is with the create release button found on build result screens. Select the successful branch build of your choice, then deploy it out.
Being able to release from a branch by no means makes Bamboo deployments “feature complete.” We’ve got a lot more in store, so stay tuned because we’re shipping new goodies every six weeks or so. In the meantime, we hope that branch-based deployments will make your nine-to-five more palatable, just as a fine chocolate delights your palate.
Get Bamboo 5.2 today, and upgrade your instance or start a free trial. Now if you’ll excuse me, I hear a certain creamy confection calling my name!
