“Super-powered CI with Git” webinar recap

Work smarter, better, and faster with weekly tips and how-tos.

Last week, Tim Pettersen and I held a webinar on optimizing your CI system for Git. We had a great time putting it together, and attendees asked some truly excellent questions, so I think we can safely call this one a success. To sum up, we covered…

Why branch-and-merge workflows are so effective (and easier in Git than in SVN, et al)

Strategies for reducing build times

How to reap the benefits of “pure” CI without piling changes willy-nilly onto a central branch

Git hooks that reinforce your testing discipline

Watch the video

Of the nearly 2,000 people who registered, not everyone could make it (hey, we know how that goes!) so we want to share the video recording here.

Q&A highlights

Again, some really excellent questions were asked. And we provided some pretty excellent answers, if I do say so myself! Click on any of the questions below to jump straight to that point in the recording.

Bonus Q&A

Here are a few more questions that we weren’t able to answer before time ran out.

From Nicolaj…

Q: “Is it possible to poll a Bitbucket repo, and only build if there’s a new tag?”

A: Not currently. Bamboo supports automatically building branches (which you can limit by a regular expression if desired) through its auto branching feature. There is a feature request open to support the behavior for tags here “BAM-13618 – Support tags in Git repository” if you’d like to cast your vote and leave a comment.

From Doron…

Q: “Can you elaborate a bit about the build configuration creation? How do you involve

A: Definitely run performance and/or load tests against dev branches – even just one run as a gut-check before merging upstream, if nothing else. I recommend using a manual trigger for performance test since running them with each commit tends to be impractical. And make your CI server do the cloning work for you each time you create a new branch (Bamboo does this out of the box; Jenkin’s build-per-branch plug-in also does this). Set up the base build configs with a manual trigger so the branch build clones inherit that.

From Nirav…

Q: “The example that you gave during the presentation only talks about single repo and building

for that repo only. What if there are hundreds of repos needed for a single build. e.g Android

system builds. Do you have any examples or case studies for that scenario?”

A: At Atlassian, each of our product repositories depends on a huge number of other modules that live in separate repositories. For example, Jira 6.3.1 shipped with 334 embedded dependencies, both open source and internally developed. The way we handle builds is by layering a dependency management tool (in our case Maven) on top of Git. Each module is built and versioned independently and the assembled artifacts are stored in a repository. When we build the product core, Maven pulls down these pre-built artifacts for us, rather than building them each from source. This is convenient for us because we develop and build each component independently and the core product changes more often than each individual dependency. I’ve found this pattern seems to work best for most development teams and would recommend it over building everything from source on every build (as you’d often end up redundantly rebuilding the same commit over and over again, which wastes time and resources).

However, if, like in the Android system case, you need to build multiple repositories at the same time, you can use Bamboo’s multiple repository build feature.

From Kannan…

Q: “During auto-merge how we can avoid merge conflict as many developers working

on the same project?”

A: Actually, I’d say you should embrace the merge conflict! The sooner you discover them, the easier they are to deal with. The great thing about pre-build merges is that they surface both merge conflicts and integration conflicts.

From Thomas…

Q: “Is there a way to automatically add build information to pull requests?

Q: “We’re using the Git flow system of branching, and it is possible that our build

plan/strategy varries between the master and develop branches. How do you handle

this with Bamboo?”

A: Lots of teams have certain builds that run against master, and a different set that run on the branches (typically a sub-set of what runs against master). For each build plan in Bamboo, there is an option to automatically apply the build to dev branches – or not. So you can simply enable that for some builds, and disable it for others. You can also set a regex that Bamboo will use to determine whether to apply a build to branches or not. For example, you can have Bamboo apply a build to branches that have “hotfix” in their name, but not branches prefixed with “feature”.

From Daniel…

“No question. Just wanted to say that BitBucket and Sourcetree are awesome.”