As Git solidifies its position as the version-control-of-choice in the workplace, Stash is delighting those workplace Git users. And it’s no surprise: Stash is fantastic for organizing repos, digging into the code, and managing the flow of code from branch to branch. But…
If you’re not using Bamboo for continuous integration and delivery in combination with Stash, you’re not maximizing Stash’s full potential. Here’s why.
Efficient use of time & build resources
One thing nearly all companies who use Git have in common is that they tend to have a lot of repositories. This is especially true in the case of enterprise-wide Git adoption, but it’s not unusual for a 10-person team to have a 20-repo project. And each of those repos has to be hooked up to the CI system in order to be built, tested, and deployed as part of an application. Once connected to Stash, Bamboo fully automates this operation. Every time a new repo is created in Stash, Bamboo discovers it and pulls in all the information needed to build from it, even if the repo has tight controls around who can write to it.
This not only saves a set-up task, it also means that teams who don’t control the repository (or have access to the source code through any human-readable medium) can still pull it into their builds. Let’s say my team works on a shopping app that depends on a core billing service, whose code is highly protected because so many other teams rely on it. I can do a fresh build of the billing service with each CI run so changes to my app are always tested against the latest changes to the billing service–without having to request special permissions from IT or asking someone from the billing team to set up that part of my build for me. There’s no need to sacrifice efficiency in the name of security, or vice versa, in order to get multiple teams contributing effectively to the same project.
In the same vein, having lots of builds polling lots of repos looking for changes amounts to a lot of wasted CPU cycles for the CI server. To solve this, Stash repos can call out to Bamboo and pro-actively trigger the appropriate builds when new changes come in. Of course this can be done with any version control system and any CI server. But with Bamboo and Stash there are no special configurations, scripts, or webhooks requires. Simply choose this as the trigger type for any build, and boom–it Just Works™.
Ease of testing on branches
Fans often rave about how much easier branching and merging is with Git, compared to centralized version control systems. The fact is, branching in Git isn’t much different from branching in SVN. It’s easy merging that makes Git stand out. And the triviality of this operation allows teams to fully exploit the power of branching workflows, which is why Git teams tend to have so many active branches.
If all those branches were to go un-tested until they are merged upstream, that upstream code line would be an utter wreck. Unstable, unreleasable, and unusable for creating new branches. Unless you’re running CI on development branches, you’re defeating the purpose of making them in the first place. Bamboo makes this dead-simple by detecting new branches and automatically putting them under test. By the time the first commit is pushed to Stash, Bamboo has already made sure the branch will be tested just as rigorously as master. All without any action from developers or build engineers.
While in-process testing is at the core of CI, there is also a need for system-level tests that make calls across a network, as well as manual exploratory testing. Both require the application to be deployed to an environment. With Bamboo, you can automatically deploy branch builds that pass in-process CI to testing environments for further inspection. With a mini continuous delivery pipeline in place for development branches, you can verify changes from every angle before introducing them into master or a stable version branch. This is exactly how the Stash team works, and they ship a new version every 5-6 weeks. Coincidence? Maybe. But then again, maybe not.
Many of us carry some pretty heavy emotional baggage around merging. And why shouldn’t we? In the SVN days, merging a branch into trunk took a couple hours if you were lucky (or the better part of your weekend, if you weren’t), and the accompanying code freeze was a drag on productivity. A rather frustrating affair, all in all. But no more.
Along with Git’s native ease of merging, Bamboo and Stash come together to shore up our confidence when it’s time to push changes upstream. Each time Bamboo builds a branch, it can merge in any other branch, then run CI on the merged code. Wondering how your changes will integrate with changes from the rest of the team? Just tell Bamboo to merge master into your branch with each build, and you’ll spot integration problems before they become… well, actual problems. This also prevents “branch drift”, making the final merge into master smaller and easier.
And speaking of that final merge, let’s talk pull requests. They’re the new standard in peer code review, and Stash has about 100 slick features that make them incredibly effective. One such goodie (I’ll have to cover the other 99 in a future post…) is displaying build status from Bamboo right there in the pull request. The simple green/red icon gives reviewers an at-a-glance gut check as to whether the code is safe to merge up. And clicking on the icon reveals additional details: which build/s have been running against the branch, when they were last run, and how many tests passed or failed. It all adds up to a high degree of certainty about merging upstream, with zero time wasted digging through emails or build logs.
So what if I told you that you can make Stash more powerful? I hope you wouldn’t just take my word for it. Grab a copy of Bamboo, connect it to Stash, and try all this out for yourself.
ps: For all you Jenkins users out there, Bamboo’s build importer tool drastically reduces the time needed to switch over. Awwwwwwww, yeah.