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:

coding in the IDE

creating unit tests

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.

When ready to submit, you initiate pre-tested commit using TeamCity plugin (bundled in TeamCity installation).

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.

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.