In this case I would prefer to start a personal build. 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. Personal builds can be useful here in case if your distribution cannot be created on your PC. Or you need to send a patched version of your distribution to a client. Sometimes you need to test your fix manually. Not all of the functionality can be covered with tests.
#Teamcity personal build code
Personal builds allow you to keep good quality in your code base during long refactoring tasks. If results are looking good I may decide to commit changes that were run in this personal build. 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. 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). Usually in this case I am starting a personal build and continue my refactoring which could change the same component again. For example, you've rewritten some component, your code compiles again and you feel that change should work fine. Often refactorings can be split in parts. Personal builds are very useful for testing your code during refactoring. With help of TeamCity build agents you can run your personal builds on different platforms in parallel and thus save a lot of time.
#Teamcity personal build full
In other words, they are useful when you are not able to run full suite of tests on your developer PC. 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. So when these features are useful? Below I tried to summarize our practical experience of working with these features. 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. Third, automated commit actually is performed from IDE. This works because before starting a personal build content of modified files corresponding to this build stored on disk elsewhere. Moreover starting from TeamCity 3.0 you can manually check-in these versions when personal build finishes. 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. You can even modify same files that you just sent to TeamCity via remote run. Second you can safely modify your files while personal build is running. However from my experience this rarely causes problems. Sometimes this causes build failures when you and other developers modified the same files, but your colleague has already committed his changes.
When a build starts your changes will always be integrated with current trunk. There are some things that user of these features should be aware of.įirst of all TeamCity currently does not allow you to run personal builds with your changes only. In TeamCity such builds are called personal builds. Pre-tested commit feature just adds automated commit to version control system if build was successful. 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. TeamCity has two interesting features: pre-tested commit and remote run.
0 kommentar(er)
