TeamCity : a continuous integration and build management solution
Posted on | 28 March 2007 |
Tags: continuous integration | tools
I first heard about TeamCity at Javapolis back in December.
It’s definitely the way forward in terms of team productivity and software quality. Finally a tool that does something to aid continuous integration.
What it does is it manages a number of machines that will run all the test each time someone checks code in. This frees up the developer from having to run tests that sometimes take hours. If a test breaks, the checkin is rejected and team members are notified. Then someone can indicate that he/she is working on it. So basically, TeamCity helps communication within a team, which is one of the most important aspects of software development.
They just released TeamCity 2.0 Beta. Anyone is welcome to be a beta tester by downloading it. A test-drive is also available online.
So even if you don’t have that many tests yet, do keep this product in mind because this is the way to go.
Comments
4 Responses to “TeamCity : a continuous integration and build management solution”
Leave a Reply
March 29th, 2007 @ 08:09
Hi Clara,
How is this better than using a standard CI server like Cruisecontrol or Continuum, with a Maven build script? Why would a developer NOT want to run the Unit tests? I think this is a mandatory practice before committing your code. I definitely do not like the idea of a delayed commit. This means task switching for the developer, and most time is lost switching tasks. Why? Because if you commit, you’ll continue to work on something else, and because you haven’t run your tests, you can’t tell what the outcome of your commit will be. So after 10 minutes or an hour you suddenly get a rejection on your commit. You have to drop what you are doing, go back to what you committed try to fix it, commit again, pray that it works this time (as you still aren’t running your tests), go back to the other stuff you were doing, etc etc.
I thoroughly dislike this practice. With cruisecontrol we have a blame system installed, which works like a charm. If the build is broken because someone forgot to run the unit tests before commit (yes, sadly this sometimes happens), everyone in the team gets a mail that the build is broken, and the name(s) of the last committers which contributed to the build. Then it’s easy to figure out who did it, and to fix it.
I for one really don’t see a reason to buy a commercial product which actually provides my team a way to be lazy, and ignore the best practices which they’ve been taught.
March 30th, 2007 @ 07:36
Neither this product nor myself advocate not running unit tests on your code before committing. Nowhere in my post did I say that you don’t have to run your unit tests anymore. But do you also run other people’s unit tests? regression tests? for the entire application/product? every time you check something in?
From what I understand, TeamCity distinguishes itself from CruiseControl or Continuum because it manages a number of machines to run entire test suites. Maybe for companies who don’t have a very large (long running) test suite, this product might not be necessary, but if a large test suite (on a large code base) exists, I wouldn’t want to tie up my machine running all the tests every time I check in, but because the chance is there that something unexpected breaks, it is good to run the entire test suite.
March 30th, 2007 @ 23:53
Clara,
You may also want check out our Parabuild server. Parabuild supported runnig builds and tests remotely for quite some time. You seem to be an expert in Agile, so your opinion is important to us. Please let us know what you think.
Thank you
–Alex
September 30th, 2007 @ 19:22
You may want to also look at Hudson (http://hudson.dev.java.net - some notes at http://blogs.sun.com/theaquarium/tags/hudson). I’m biased but it has many happy users. - eduard/o