Dec 6, 2007

What I like about TeamCity: Pre-tested commit

I am one of the TeamCity developers so you can surely consider my opinion to be biased. But I am speaking here of a typical problems that any of you can experience and will try not to brag about my product too much ;-)

I'm a software developer. And though TeamCity is not an individual tool like IntelliJ IDEA, I'd like to present TeamCity features which ease my life as a software developer.

Pre-tested commit

In days before TeamCity, I used to write the following command line:
kir@work:~$ ant test && svn ci -m "FBQ-3324 fixed"

As you see, all I want is to ensure that my changes don't break tests and commit them the to version control afterwards. Usually, I wrote such a command once a day, right before going home.

Why I did so? Running the tests was a rather long process, because there were plenty integration and functional tests. And this situation is quite normal for non-pet projects. And still, I want to run all the tests to ensure that my changes won't break the build and the team is not affected by problems in my code.

Unfortunately, running a full suite of tests on the own machine is a luxury I can afford only when going home (or in the lunch time). Usually the computer load caused by running tests is pretty high and interrupts the productive development process.

Back to TeamCity. My current use case is as follows:

  1. I do some modifications in the code, write more tests
  2. I send the changelist to TeamCity and mark build configurations to be built with my changes. I also set checkbox "Commit if build successful" (see the illustration screenshot below)
  3. I continue working with the code (edit same files, write more tests)
  4. If TeamCity builds were successful, my IDE got the corresponding notification and my changes made in position 2 are sent to the version control. I continue working with the code, preparing for the new pre-tested commit.
  5. If the TeamCity builds were unsuccessful, I get the information about failed tests, navigate to the failing stacktrace (all within IDE), and fix discovered problems. I.e. the build with my problematic code was run on TeamCity build agent and didn't affect the version control and my team mates' work.
  6. The TeamCity build may be unsuccessful, but no new tests has failed (this information is also provided by TeamCity). In this case I may decide to force commit of my changes. I am on the safe side when doing that, because TeamCity IDE plugin remembers the state of my code when remote build was initiated.

So, as you can see, I am pretty confident that my changes won't break the build and the bad code won't go to the version control. And I like this.

What happens, when someone else commits changes and these changes conflict with mine? In such case, my commit will be rejected and IDE plugin will notify me about that. I'll have to update changed files from the version control and resolve the conflict manually - no unexpected magic here.

Please note, that TeamCity supports this scenario with different IDEs, including IntelliJ IDEA 6.0/7.0, Eclipse, and Visual Studio, with minor variations.

This feature is described on the JetBrains site in more detail, but may be it's better to try it and see for yourself.

Good luck and successful builds,


Jeff said...

Thanks for covering this topic!

We are currently evaluating TC now and are still in the early setup stage.

On the topic of Delayed Commit,
Could you please explain how some operations are handled by TC.

3 developers each invoke a delayed commit build, seconds apart. Each would be comparing their own changes against the same code base. As each build passes, how are the commits handled. Does each commit happen as the build passes or in the order the builds are invoked?

In general we want to know how well the Delayed commit will perform with many active developers etc.

Any insight would be appreciated.


Kir Maximov said...


In case of several delayed commits the first winner will commit successfully. In case of conflict, second developer will get notification that the build was successful, but IDE won't commit the changes.

In this case, there are two options for the developer:
1. update and run second delayed commit
2. update and force commit if she is sure that the merge won't cause any new failures.

IDE has an option to force manual commit of the pre-tested build (and in this case it will commit sources which were tested on the server, even if the local copy of the sources have been changed).

In house, we usually go with option 2 and it works quite ok.


Jeff said...

Thanks for the reply,

"IDE has an option to force manual commit of the pre-tested build (and in this case it will commit sources which were tested on the server, even if the local copy of the sources have been changed)."

I am looking for this feature in my Eclipse plugin, but I cannot find it.
When we run a delayed commit, often another commit causes a commit fail for another developer. By that time , he has updated his code. How is it possible to submit the tested Changeset? Is it possible that this feature is only available in Intelij?

Kir Maximov said...


Unfortunately, this feature is not implemented yet in Eclipse plugin. We plan to implement it in Calcutta, next version of TeamCity.
You may watch/vote for


HARI said...

Hi Kir
Can you explain how emma works with teamcity.
E.g. Code coverage is enable through Temcity Configuration and we want to get code coverage report but when we run the code all classes are 0% percent.

So I need to know how we can get te code coverage properly.