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,