Gated check-ins / pre-tested commits for Git?

Question

I'm looking at migrating from TFS (Team Foundation Server) to Git, but can't find anything matching TFS' support for gated check-ins (also called pre-tested or delayed commits).

Atlassian Bamboo has no support for gated check-ins. TeamCity does support it ("delayed commits" using their terminology), but not for Git. Using Jenkins by itself or Jenkins+Gerrit has huge drawbacks and doesn't come close to the gated check-in functionality in TFS. (Drawbacks explained by the creator of Jenkins himself in this video: http://www.youtube.com/watch?v=LvCVw5gnAo0)

Git is very popular (for good reason), so how are people solving this problem? What is currently the best solution?

Solution 1

We have just started using git and have implemented pretested commits using workflows (I finished testing this just today).

basically each dev has a personal repository which they have read/write access. The build server TeamCity in our case, builds using these personal repositories, and then if successful pushes the changes to the 'green' repository. Devs have no write access to 'green', only TeamCity build agents can write to that, but devs pull common updates from 'green'.

So dev pulls from 'green', pushes to personal, TeamCity builds from personal, pushes to green.

This blog post shows the basic model we are using, with GitHub forks for the personal repositories (using forks means that the number of repositories doesn't get out of hand and end up costing more, and means that the developers can manage the personal builds, as they can fork and then create the team city build jobs to get their code pushed to 'green'):

This is more work to set up in TeamCity as each developer has to have their own build configuration. Which actually has to be 2 configurations as TeamCity seems to execute all build steps (including the final 'push to green' step) even if the previous build steps fail (like the tests :)), which meant that we had to have a personal build for the developer, then a another build config which was dependent on that, which would just do the push assuming the build worked.

Solution 2

Check out Verigreen - A lightweight, server side gated check-in system. It verifies each commit before it finds its way into the branches the system protects. Verigreen will not allow any failed CI commit to break the integration, release, or any branch that need be protected. Moreover – it's a free, open-source project.

How it works: Verigreen intercepts check-ins and runs verification in an ad-hoc branch - so that in case of failed commit, only the relevant developer is affected.

• A pre-receive hook intercepts and creates an ad-hoc branch of the code.
• Verification is run via a Jenkins job. The verification job content is fully configurable.
• The verified code is merged back into the protected branch whereas a failed commit is blocked with a notification sent to the developer.

Decisions are made based on the following flow:

For more information, please see the wiki or Verigreen.io site

Solution 3

I think that after October 23, 2013 the answer can be - Automatic Merge in TeamCity.