Your typical day consists of writing new code, running local tests, and then integrating your changes with those of your team members.
If you are going the "agile" way, you would synchronize with your team by updating your sources with the changes of others. Then you re-run all tests and check-in this state to the VCS. As you run tests on your personal desktop, this obviously blocks your work. The natural consequence is that you do not run all tests as often you should run them. As a result, you get lower code quality and a jeopardized schedule.
It's even worse if you first commit your changes to the VCS, and only then a "regular" build detects the defect you've introduced. Unstructured or haphazard interaction leads to bad code in the code base - and that is both a developer's and project manager's nightmare.
How to keep the main build clean, the sources compilable and, at the same time, run all unit or functional tests before committing them to the VCS? In short, how to keep the code base healthy?
One solution to these seemingly mission-impossible-type tasks are **Personal builds**. Personal builds are made possible with TeamCity, which allows testing your changes and running tests remotely and comes with integration
plugins for Eclipse, IntelliJ IDEA, and Microsoft Visual Studio.
Once downloaded from TeamCity's web UI and installed, your IDE plugin takes developers' changes and those in the project code base and merges them together. A personal build is, in fact, much like a "regular" build run on TeamCity, only the code doesn't get committed. The huge advantage, therefore, is that if a personal build fails and TeamCity detects one or more problems, both the real build and the code base remain safe and sound.
The mechanism of creating personal builds is simple. Once your project is set up, TeamCity fetches your teammates' changes from the VCS and integrates them together with your modified code. If some tests fail or if other problems occur, you are immediately notified about this - right in your IDE (thanks to the IDE plugin). If the tests pass, you can safely commit your changes, or just have TeamCity do it for you, without crossing your fingers and taking a deep breath. This way you won't be seeing any unhappy faces from the other team members whose work could have gotten delayed by your broken code.
Of course, personal builds are not a one-size-fits-all solution to all developers' problems. However, they do a great job of eliminating bad code in the VCS. The feedback loop becomes shorter as you gain full control of your code changes and get rid of manual operations and common hardware slowdowns and bottlenecks. The topping on the cake is: try as you might, you can't do anything wrong with the code base. Just enjoy reverting and retesting your changes any time you want!