7

Development teams are often plagued by builds in version control being transiently broken. The entire team's productivity can come to a halt while trying recover from a build broken by one person.

Is there software that would allow hosting Git in a way that prevents breaking builds in version control by not accepting commits that fail to pass tests in the first place? The usage scenario could for example look as follows:

  • The software runs on a server that continuously pulls revisions from Git repositories that developers have published.
  • For each pulled revision, the software builds the revision and tests if it passes the unit tests.
    • If it passes the tests, the revision is merged into the "stable" branch.
    • If it doesn't pass the tests, it is rejected and the revision is not merged into the "stable" branch. The developer is forced to correct the revision and resubmit it.
  • Developers by default pull from the "stable" branch that should never be broken—in the sense that tests do not fail—and are more productive as they spend less time being blocked by broken builds. And the usefulness of such a system grows with the team size.

A few notes:

  • Git's pre-commit hooks and similar are not satisfactory in this case. The solution should be automatic and enforced on the server side for each commit.
  • Looking for a solution that has been implemented and thought out as far as possible, instead of writing a system like this myself from scratch.
Markus Miller
  • 3,695
  • 2
  • 29
  • 33
  • This sounds like a really awesome idea - but has one problem: how are you going to deal with merge conflicts, given that the system is automated? – TreyE Nov 04 '10 at 21:20
  • 1
    Surely you can reject the commit that failed with a merge conflict and inform the developer they have to update and merge manually to resolve the conflict. A typical someone got there before you scenario. – Jonathan Holloway Nov 04 '10 at 21:23
  • Ok, so in that case you'd want to make a distinction between 'failed due to test' and 'server is too dumb to merge'. – TreyE Nov 04 '10 at 21:32
  • How about http://stackoverflow.com/questions/4096182/what-are-the-pillars-of-continuous-integration/4096407#4096407 and http://stackoverflow.com/questions/3209208/what-is-the-cleverest-use-of-source-repository-that-you-have-ever-seen/3209767#3209767 ? An intermediate Git repo can be enough. – VonC Nov 05 '10 at 07:15

3 Answers3

1

I think this is more a build server feature that ties into a VCS such as Git. TeamCity does have support for this, but I've not tried it so I can't comment on how good it actually is.

http://www.jetbrains.com/teamcity/features/delayed_commit.html

The Hudson guys have been discussing it for a while, but I've yet to see it in a release.

http://wiki.hudson-ci.org/display/HUDSON/Designing+pre-tested+commit

Jonathan Holloway
  • 62,090
  • 32
  • 125
  • 150
1

We use gerrit and hudson. It is what android and Cyanogenmod use as well (along with many others).

Gerrit allows for code review and automatic building of every commit with automatic rejection of those that fail tests.

Hudson runs the tests.

Hudson: http://wiki.hudson-ci.org/display/HUDSON/Designing+pre-tested+commit

Gerrit: http://gerrit.googlecode.com

This system works well with the repo tool to have a large number of small repositories, this will reduce merge conflicts which have to be handled manually via a rebase.

Note: it is quite a bit of work to get up and running if you have a large existing code base, but totally worth it.

NorthIsUp
  • 17,502
  • 9
  • 29
  • 35
0

It's a really good idea. Bamboo supports this quite naturally. Several Bamboo customers as well as teams at Atlassian have this exact methodology setup and working to great effect. Bamboo has event listeners which can tell (without polling) when a commit is pushed to a 'test verfication' repo and then verify it by running the tests before pushing to the stable branch. www.atlassian.com/bamboo

Brendan
  • 408
  • 7
  • 8