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.

Q: We’re interested in using the Atlassian Git Essentials toolkit with Bamboo to deploy code changes as they are made. Is the Bamboo integration straightforward when working with Git via command line, as well as when working through the web UI?

Q: Do you have any recommendations on how to employ CI and Git with database schemas and data?

Q: What is the difference between Git and Mercurial?

Q: What version of Stash and Bamboo will let Stash trigger the builds (instead of polling)?

Q: Does the Stash/Bamboo backend integration also apply for hosted Bitbucket/Bamboo?

Q: Can you explain more about Git rebase?

Q: How does this all work with Mercurial?

Q: My team uses SVN. Each user creates a branch for a day and each of our commits is really a feature build. Would our method still work ok when we get move to Git or should we update our workflow?

Q: Next step in CI would be testing and tagging the repo if the tests are successful. Any suggestions around this? 

Q: Are Git hooks written in a language that is internal to Git?

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

advanced tests like performance tests? (I come from a load testing perspective.)”

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?

(success/failure)”

A: You absolutely can! You can also prevent a pull request from being merged until it has a green build. We use this feature internally at Atlassian to make sure merges don’t break our stable branch builds.

From Kevin…

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.”

A: Agreed (wink). Also, they’re both free.

Hungry for more?

We’ve got more webinars and articles coming throughout the summer and fall as part of our Git Together series. Stay tuned for more good stuff!

 

Anyone can be good, but awesome takes teamwork.

Find tools to help your team work better together in our Git Essentials solution.