开发者

How does a "delayed commit" work with source control repositories and CI servers?

开发者 https://www.devze.com 2022-12-16 16:58 出处:网络
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:

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 th开发者_如何转开发is working?

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


Generally you have to use a command line tool or an IDE plugin that lets you submit your code to the CI server. The tool bundles up your changes along with all the relevant project/repository/user metadata, starts a build and then commits it if everything goes well.

In the case of TeamCity, it looks like the server actually submits an approval message back to your computer (from what I can tell from the diagram), then it gets committed from there — presumably so you don't need to have each user's SCM credentials — which could be complex if you use SSH private keys etc. — on your TC server.

But CI servers can integrate with pretty much any SCM system, no matter where the server is located — you just need to give it the correct credentials to get (generally read-only) access.


It does something like that:

How does a "delayed commit" work with source control repositories and CI servers?


(source: kawalerowicz.net)

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

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号