I checked in a few source files I'd been working on as I left work tonight. I didn't bother syncing with version control, running the unit tests, or even building the project. Hey, we have a continuous integration server, what could possibly go wrong? If you're anything like I was, right now you're screaming, “Dude, {CruiseControl, AntHill, Hudson} is going to fail and you're going to spam me with build failures all night!”
No, no I'm not. See TeamCity is different. And different is better. Build failure spam? No more. Waiting for a success message before going home? Nope. Lengthy clean and full rebuilds before checking in? Thing of the past. Can't compile because you synced just after someone else checked in garbage? Never again.
Here's the architecture of traditional Continuous Integration products:
You submit your code to version control, then CI pulls the source from version control, builds, tests, and sends out the success failure message. Traditional CI products don't claim to keep version control clean and error-free, they just claim that you'll know about it when it happens.
Here's the architecture of TeamCity:
You submit your code to the CI server, it merges your new files into the existing source, builds, tests, and only checks the files into version control if they are clean and error-free. Version Control can no longer become corrupted. Submitting garbage to the build server won't effect any of your teammates; they'll never see your bad files. No one will ever be spammed with build failures because TeamCity won't let version control ever lose integrity*.
What do you do when you check in? Sync, clean, build, test, and then submit, right? How long does that take? 15 minutes, 30 minutes? Why don't we just let the CI server do that for us. Having TeamCity do this for me is saving at least 15 minutes a day. That's a 3% increase in performance from just switching to a different CI server. I think in 5 years we'll look back at these “traditional” CI products and consider their architecture naïve. TeamCity is simply doing CI the way it should have been done in the first place.
And the best part is that I'll never again have to call my wife after 5 PM and say, “I can't come home yet I have to wait for my build success message.”
* In practice, there are still occasional build failures because nothing stops an eager developer from checking in files through their version control client. Damn those command line users! (Of which I am one)
7 comments:
When multiple developers commit to the same project, will TC use different build agents for the same code base to verify the changes? I.e. dev 1 commits at 10am and a build starts, at 10:05 dev 2 commits. Will the second commit start on a different agent if one is available?
Yes, separate build agents are used. Which is nice, because any one pre-commit build will only have one person's change list in it, and a distributed build will generally be faster b/c you'll never be bottlenecked waiting for the previous used.
There is still the possibility of a post-commit build failure, though. If two people pre-commit simultaneously and there is a version control conflict/merge issue, then I would expect that the first person whose build completes would get checked in, and the 2nd person whose build completed would have their build fail on the final "check in to VC" step. But if the conflict results in a failing unit test then both users will have their code checked in which causes a post-commit build to fail.
So you might still get some build failures. It is possible, and I should never use words like "never" and "always".
I don't mean to sound like the JetBrains rep, but I've been really impressed with this product.
Hamlet,
You might check out our Parabuild. It handles cases when changes that break the build do get submitted to the version control system, such as integration merges that you described.
We call this killer feature "unbreakable scheduled builds". With Parabuild your nightly and daily builds will be clean even if the head of the code base is broken.
Regards,
Slava Imeshev
More on TeamCity personal builds and when they are useful: http://teamcitydev.blogspot.com/2008/03/personal-builds-practical-experience.html
sinema
kurtlar vadisi pusu
This feature of TeamCity relies heavily on IDE, and it is only available for Visual Studio, IntelliJ and Eclipse for now. For developers using other IDEs (or even do not have an IDE), QuickBuild 2.0 might be a good choice to do continuous integration builds before commit. It includes a free community edition which allows to use up to 16 projects without any other limitations. For details, please checkout here
thank you great post
murat
muratoloji
Post a Comment