views:

207

answers:

3

I'd like to know how "delayed commit" functionality works on CI servers that are not integrated with the source control repositories. Conceptually, the process works like follows:

  1. Check in code changes
  2. CI server builds the changes
  3. If the build passes, the code is committed to source control repository
  4. If the build fails, the code is not committed to the source control repository

Most CI servers work by polling the source control repositories for changes and then pulling down the code. So in the delayed commit scenario, are developers checking their code into the CI server rather than an actual source control repositories and then the CI server is passing on the code to the repository? Or alternatively are the CI servers just rolling back changes if the build fails?

I'm thinking of two continuous integration systems in particular. Team Foundation Server is going to offer this functionality in the next version, but it makes sense because the Team Build (CI system) within TFS is integrated with the source control repository. However, in the case of Team City, TC is able to connect to any source control system and is not necessarily integrated with or even on the same server as the source control repository. How is this working?

Edit: Opening a bounty on this question in the hopes that I can get some more possible answers.

+2  A: 
Christopher
+1  A: 

It does something like that:

TeamCity Pre-test commit

so it is the client machine that does the commit. Not the server. The SCM does not matter in that case.

Marcin K
+4  A: 

You might want to check this link

c0mrade