Continuous integration is a tall order, even in an ideal scenario: a small team working on a green-field project where test and deploy automation is baked in from the start. Now add legacy code, multiple business units, and thousands of engineers to the equation. Certainly doesn’t make things any easier, does it?
Today we’re delighted to announce the release of Bamboo 5.6, with a host of features designed to better support CI at enterprise scale. So to all you 100-agent users out there: if you haven’t updated your installation in a while, now is the time!
Easy triggers via Stash
Each large company is different, but there’s at least one thing they all have in common: lots of repositories. (Even mid-sized outfits like Atlassian have hundreds of repos!) Most often, repos get built when the CI server detects a change. Think about what that means for the CI system’s performance, though. Polling hundreds of repos every minute is quite a resource hog.
Now when you link Bamboo to Stash, you can leave this problem behind. Stash will call out to Bamboo as soon as a change has been pushed to a repo. No polling. No webhooks. No special repository configurations required. With Stash and Bamboo, it Just Works™.
Naturally, we hope this entices more Bamboo users to try Stash. But we wouldn’t leave our existing Stash customers in the lurch. We’re pretty sure you’ll want to take advantage of this new trigger in most (if not all) of your builds, so we added a companion feature to make that easy. A bulk update option for triggers is now available, which means you can scale up Git without scaling server load or scaling your build engineers’ overtime hours.
Cloning for deployments
“Exhibit B” in our support for CI at scale (and your build engineers’ work/life balance) is cloning for deployments. With Bamboo 5.6, you can clone entire deployment projects, or clone the deployment tasks and settings for a single environment.
Getting ready to construct continuous delivery pipelines for lots of applications? Create a baseline deployment project and use it as a cloneable template. Adding new test environments to an existing project? Simply clone the configs for an existing environment and all the tasks, variables, triggers, etc. will be copied over–cutting your set-up time in half (or better).
Last is an addition that I’m personally very excited about because I’ve heard so many customers asking for it. Usually it goes something like… “I have a couple of really critical builds that we can’t afford to let sit in the queue. How can I make sure they’re executed the moment they’re triggered?” Or, especially in the case of larger customers… “My business unit paid for 10 new servers to be used as build agents, but whenever we need them, they always seem to be running builds for other projects. So. Frustrating.”
In two-birds-one-stone fashion, we’ve solved both problems by letting you make any agent dedicated to specific projects, plans, and jobs on the CI side, or specific projects and environments on the deployments side. And yes: you can mix ‘n’ match, which is great for continuous delivery pipelines. A build plan and all the environments it’s deployed to can be serviced exclusively by a single agent (or multiple dedicated agents if you want to run build jobs in parallel).
But remember: capability is still king. If your build job requires Git 1.9, and the dedicated agent only runs Hg, nothing will happen at build time. Check out our handy guide to requirement/capability mapping for more details.
One of our areas of focus across all of Atlassian this year is to better serve our enterprise customers. This release introduces only a few of the ideas we have in this vein for Bamboo. Download your distribution of choice, then drop us a line and let us know what you think!