9:00 am –
Ahh, release day. You’ve run your test suite with each commit, and a green build has soaked on Staging for two days. Your application relies on a 3rd-party system to process credit card transactions – a critical dependency for your revenue stream. Your team didn’t make any changes during soak time, but you don’t know whether your credit card processing provider did.
Worried? Nah, not you.
You use multiple build triggers to run your tests with each commit, as well as nightly. So you’re guaranteed that integration issues are uncovered whether or not it’s your app that changes.
9:30 am –
It occurs to you that you haven’t released to production since upgrading to Bamboo 4.3, and you rely on the Tomcat Deploy task to make deploys go smoothly. This is an important day for your product – plugin incompatibility issues with v4.3 is the last thing you need.
Biting fingernails? Nah, not you.
Bamboo now ships with the Tomcat, Heroku, SSH and SCP already installed. So you know they’ll be supported and tested for compatibility with each new release.
10:00 am –
You pull up Bamboo, and find your release candidate build, paused on the manual “Deploy to Production” stage. As you’re pulling down the Run… menu, your sys-admin rushes over, wild-eyed with toast crumbs still lingering in his beard. One of the production nodes just died. He can swap in another one, but it will have a different address.
Hosed? Nah, not you.
You’ve got your deploy targets set as variables. You select “Deploy to Production Customized”, override the configured value on the fly with the new node’s address, and deploy the very same build your team worked so hard to vet.
11:30 am –
Sweating bullets? Nah, not you.
You know you can rerun the previous build deployed to production. By rolling back today’s deploy, your team will have the time they need to implement the right solution – not a “right now” band aid.
11:31 am –
Today’s release has crippling performance issues and you need to rollback. That means finding the last build deployed to production. NOW. With hundreds of plans on your Bamboo instance, your dashboard stretches down to the basement. Something about a needle and a haystack comes to mind…
Overwhelmed? Nah, not you.
You pull up the enhanced filter on your dashboard, isolate the project you want, and find that plan in seconds flat.
2:00 pm –
The performance problem has been traced back to the commit that caused the issue, and you need the commit made just before the culprit. But your plan polls the repo for changes every 3 minutes, so if several commits happen during that interval, each revision won’t be built separately – the build will pull from the most recent one. And sure enough: the revision number you need was never built on it’s own.
Distraught? Nah, not you.
You summon your digital scalpel and run a build from a custom revision number – the exact moment in your code’s history when you had all the features you want, and none of the performance drags you don’t.