6.4. Remote builds with TeamCity

In section 6.1, I mentioned that you should use the same build scripts locally that you use for the central build, but running builds and tests locally has drawbacks. One major drawback is that the procedure allocates your local desktop to this task—you can’t work on other things, or your work is at least delayed until the build is finished. Another drawback is that your private environment probably isn’t equal to the central one that hosts the build server. But you don’t want to trigger the central build server during your development because you don’t know whether your software contains bugs or doesn’t integrate. Besides that, the central build server normally pulls sources out of the VCS that are already committed to VCS. You don’t want to commit your untested changes to the VCS merely to see if they’ll build successfully. One solution is to run your private build using a centralized build server.

To test how successful your changes are, you can create personal builds in JetBrains’ TeamCity (www.jetbrains.com/teamcity/) using its remote run feature. The modified files are submitted to the server, bypassing the VCS. In addition, using the pretested commit feature, the project codebase always stays clean: If the tests fail, the code isn’t integrated into the codebase, the developer can safely work on a fix, and the team’s work isn’t interrupted. If the build is successful, the changes are committed to the VCS automatically (this is an opt-in request). From there, the changes will be automatically integrated into the next regular integration build (see figure 6.3).