Build services are very improve in the TFS 2010. Apart from the many new features introduced in the build services, ‘Private Builds’ are something which is very practical solution for everyday development.
Many time when a developer has changed various classes and completed considerable amount of work, he/she would think to validate the build before checking in the changes. It is always nice to keep the source control in compilable state to avoid any impact on the team using the same source control.
Private build address this issue where a developer can shelve the changes in a shelve-set and queue a private build.
While queueing the private build, queue new build wizard would ask ‘What do you want to build?”. (see following screen shot to understand).
TFS Private buid
Either workspace item could be selected or second option ‘workspace item with shelveset’ could be selected.
In this case, TFS build controller will get the latest source code from the source control and additional it would also download changes from the shelve-set specified. This combination will be used to prepare a build.
There is another option while queueing a new build to select. “Check in changes after successful build”. If this option is selected, successful build will check-in the changes available in the shelve-set.
These types of build are not uncommon in developers. It is mostly a practice where a developer gets the latest source; update the changes and build to verify his/her changes does not break the build. CI builds also does the same thing however if build is broken because of a wrong check-in could still impact the whole team.
In case of private build it works prior to the actual check in and everything happens in isolation to the source control.
In order to ensure that private builds are copied to a separate area, drop location for the private build could be specified in the build process of the build definition.
Drop location of private build in build definition
Under the advance options there is an item as “Private Drop Location”, any build done as ‘Private build’ would be dropped in the specified location. This is useful if any particular test is needed with help of binaries.
After successful build, TFS publishes the outcome of the build validation to indicate whether shelve-set included in the build is fine. Build summary published by TFS Build gives information about validated shelve-set as well indicating that they have been checked in.
However, if build is failed due to either compilation or test failure. Changes indicated in the shelve-set will not be checked in. This is really something very nice to use TFS Build system as a quality gate to ensure all the changes going in the source control are in compile state and tested.
Further:
Private builds (Gated check-ins) are really a great feature of TFS2010. It helps you to achieve benefit of Test Driven Development. What we have been doing now is,
- Write the test cases for each and every rule/requirement specified in the user story (use cases are broken into various small requirement called as user story).
- Complete the development of user stories by developing the code which makes test cases pass.
- Shelve all the test cases code and changes done in the code.
- Request TFS Build to do a private build including the shelve-set.
- TFS verifies and ensure changes in the shelve-set are in compile state and working as per the expectations set in test cases.
- Changes checked in by TFS build using the comments and work item associated with shelve-set specified.
Even if there is any team not using TDD approach could utilize private builds in many scenario where there is concern as “Will my changes break the source code integrity?”.
There are some open source tools available which could help implementing a ‘Delayed Check-in’ process where developer could simply complete the development and shelve their changes. This tool will validate the changes and check in if they are valid.
If you enjoyed this article, please consider sharing it!
