Personal builds: practical experience

TeamCity has two interesting features: pre-tested commit and remote run. Remote run feature allows you to send your changes to TeamCity server and run a build with them without performing actual commit to a version control system. Pre-tested commit feature just adds automated commit to version control system if build was successful. In TeamCity such builds are called personal builds. There are some things that user of these features should be aware of.

Under the hood

First of all TeamCity currently does not allow you to run personal builds with your changes only. When a build starts your changes will always be integrated with current trunk. Sometimes this causes build failures when you and other developers modified the same files, but your colleague has already committed his changes. However from my experience this rarely causes problems.

Second you can safely modify your files while personal build is running. You can even modify same files that you just sent to TeamCity via remote run. Automated commit will check-in those versions of files that were sent to TeamCity when your personal build started, not the last changes you've made. Moreover starting from TeamCity 3.0 you can manually check-in these versions when personal build finishes. This works because before starting a personal build content of modified files corresponding to this build stored on disk elsewhere.

Third, automated commit actually is performed from IDE. So if you start a personal build with automated commit and then close IDE the commit will not be done until you start your IDE again.

Returning to practical usage...

So when these features are useful? Below I tried to summarize our practical experience of working with these features.

Personal builds are useful when you have a lot of functional tests (which are usually slow), or when you need to run your changes on several platforms with different software. In other words, they are useful when you are not able to run full suite of tests on your developer PC. With help of TeamCity build agents you can run your personal builds on different platforms in parallel and thus save a lot of time.

Personal builds are very useful for testing your code during refactoring. Often refactorings can be split in parts. For example, you've rewritten some component, your code compiles again and you feel that change should work fine. This is a good time for personal build. Usually in this case I am starting a personal build and continue my refactoring which could change the same component again. TeamCity IDE plugin will notify me when build finishes or when a first failure occures in the build (I prefer to have such notification for builds with my changes). And do not forget that TeamCity works hard to provide me with information about failures at the same time when they occur, so if I've broken something I'll soon be informed about that. If results are looking good I may decide to commit changes that were run in this personal build. Personal builds allow you to keep good quality in your code base during long refactoring tasks.

Not all of the functionality can be covered with tests. Sometimes you need to test your fix manually. Or you need to send a patched version of your distribution to a client. Personal builds can be useful here in case if your distribution cannot be created on your PC. For example, TeamCity contains Java / .NET and C++ code. I work mostly on Java components and I do not have Visual Studio installed so I cannot easily build a TeamCity distribution on my PC. In this case I would prefer to start a personal build. There were several cases when a personal build of TeamCity was installed to our internal server (where all Jetbrains projects are built) to check whether performance improvement or other critical fix we've made actually works.

Usually project build scripts and make files should be modified very carefully since a little error in these files can brake all of your builds. Personal builds are good choice when you need to check modifications in such files.

TeamCity does not have functionality explicitly designed for code review, but it is still possible to do a pre-commit code review with help of personal builds. For example, a developer could send you a link to a successfully finished personal build. First of all build results can tell you much about the change. Second you can review changes with help of TeamCity diff window and then make a final decision about it.

For those who never used TeamCity I hope this summary helps you better understand how personal builds work and in which cases they can be useful. If you are using TeamCity for day-to-day work feel free to share your experience with these features.