Elizaveta has posted 4 posts at DZone. View Full User Profile

Avoid Broken Code in Version Control: Use "Pre-tested Commit"

  • submit to reddit

How often do you blame colleagues that have submitted changes to the repository and gone home, while the build turned out to be broken? Wouldn't you like a nice way to avoid such a pain? TeamCity's pre-tested commit is the feature that does exactly this job.

The concept of pre-tested commit emerged from typical software developers' workflow and their daily chores:

  1. coding in the IDE
  2. creating unit tests
  3. submitting changes to the version control system and waiting for feedback

It's all right if the modified code integrates correctly and the tests pass, but, unfortunately, it is not always this way. The changes can break the build and finding the reason of broken builds and the responsible takes time. Meanwhile, the development process can freeze and, even worse, the deadlines can be missed. Pretty bad perspective, but appears to be not so rare, isn't it?

We decided to change the state of affairs and help you avoid the "5 o'clock check-in problem", as well as many others. TeamCity's pre-tested commit alters the standard development scenario and allows you to remotely verify code changes before you upload them to the project repository. Let's now find out how it's done.

  1. You code in your IDE (currently Eclipse, IntelliJ IDEA and MS Visual Studio are supported)
  2. When ready to submit, you initiate pre-tested commit using TeamCity plugin (bundled in TeamCity installation).
  3. TeamCity runs a full build with your tests across different pre-configured platforms and test suites but your changes are not uploaded to the VCS until the build is successful.
  4. When the build is complete, TeamCity notifies you on its results and can automatically submit your changes to the repository if the build succeeds. Otherwise, the code is not submitted, and you can safely work on the fix.











While your build is being created, you can modify even the same piece of code and add more unit tests. If TeamCity finds out that your changes conflict with those of your team mate, you can still be sure you are on the safe side because TeamCity notifies you on that, and your code is not integrated into the code base.

Your team can keep on working all the time, and you always have a clean code, less time is spent to discover the integration issues because you know who broke the build, and the project just moves on in its rhythm.

You can learn more about pre-tested commit on the dedicated web-page.

Your rating: None Average: 5 (5 votes)
Published at DZone with permission of its author, Elizaveta Revyakina.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Guillermo Schwarz replied on Mon, 2008/02/04 - 10:10am

Nice, but...

We check-in code several times a day in our own developer branches (they are nore like Jira branches). So instead of relying on ant or maven to compile and pass all regression tests before a check-in, we rely on maven to verify the same before merging into the trunk.

The advantage of using branches is that we can safely commit without affecting other developers and in case our local disks go bust, we have a backup in SVN.

I've used LuntBuild for several years now. LuntBuild tell you the status of the repository after the commit has taken place (at least you have a commit). What is the advantage of doing the verification before the commit? *I mean besides never checking-in somethign that doesn-t work). Take into account that the important use case is not taking out something that doesn't work, LuntBuild gives you exactly that, because it flags every repostory number as either good or bad.

Cheers, Guillermo. 

Michael Hüttermann replied on Mon, 2008/02/04 - 12:32pm in response to: Guillermo Schwarz

Hi Guillermo,

there are plenty of different scenarios how to set up your VCS, to develop artifacts and when/how to use branches. Development branches are not so common in my opinion, because they also have drawbacks and some kind of overhead and error-proneness (only my opinion). Release branches are more common I think. Independent from that .. I think it is an agile principle and best practice to detect defects as soon as possible if you use development branches or not ... and the pre-test commit can help here.

In my opinion it is very unique not only to detect defects early but also transfer test runs and builds to a central machine. This is exactly the advantage of the pre-test commit .. not to check something in that is broken. You know .. in the agile world you should run your tests before you commit something ... and with TeamCity you do not need to block your own development machine for that and keep on developing. Another advantage is that you keep the main build clean with that ... if the system detects an error it is part of your personal build, not the central project build ... this will increase the quality of the artifacts dramatically and your peers will say "thank you". ;-) But the process is seamless ... if your "pre-build" is successfully, it can be commited automatically.

Please also classify this TeamCity feature in the whole bundle with its complementary features. It is part of the collaboration support .. remember e.g. that TeamCity can notify you directly after discovering errors in the tests ... even if the build is still running.

Seeing and having access on all builds, old and broken ones, what you describe, is a main feature of all CI-Servers. Also TeamCity has this basic feature of course but sets additional features on top (you do not need to use them but you can). Did you try TeamCity? It is really comfortable retrieving old builds with TeamCity with its Web 2.0 UI. You can monitor there too who is working on a broken build, which commit break the build if happened, and so on ..  I think TeamCity a comprehensive collaboration suite which supports agile development schoolbook-like.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.