none
TFS Check-In Policies Best Practices

    Question

  •  What check-in policies do you use when developing as a team? Any best practices/pitfalls? Please share your experiences.

    Friday, September 09, 2011 3:50 PM

Answers

  • + 1 Gary,

    I have the following check in policies set up in my enterprise,

    1. Check In Comments - Ensure the user adds comments against check ins, an immature team may see useless comments, but a bit of training and vigilant monitoring in the early days can help the team mature to provide meanigful comments, that are of great help when release managers are performing merging or a developer trying to trace the changes through version control to identify the cause of a bug.

    2. Work Item - Associate work items to check ins, this is essential and allows you to perform end to end tracibility in your project. Futher to this, if in your build definition you have the option 'Associate changeset to work item' - you will see Team build updating your work items and associating changesets to them.

    3. Code review - Allows you to enforce and track code reviews, a good one for teams that have a balance of senior and junior developers.

    4. Unit Test - The unit tests and code coverage to enforce the developer unit tests the code before pushing the changes in to version control.

    5. Exclude files - My enterprise uses re-sharper, initially we started having developers check in resharper solution files in version control as well, some developers checked in random external dll's as well, some accidently checked in massive changes to config files as well. This policy allows you to exclude check in against certain extension types, over course this can be overridden if required but raises an alert and can be monitored if need be.

    Other policies can be set up as well, but there is very thin line of difference between ensuring the team follows best practices and force rules on the team and they start finding work arounds :)

    HTH
    Cheers, Tarun


    Please remember to mark the replies as answers if they help.

    Tarun Arora

    Blog: http://geekswithblogs.net/TarunArora  Subscribe in a reader

    • Marked as answer by johnzst Monday, September 12, 2011 2:04 PM
    Sunday, September 11, 2011 12:43 AM
  • Thanks Tarun and Gary for your kindly help.

    Hello johnzst,

    Thanks for your post.

    Apart from Tarun’s and Gary’s replies, I also get some more additional information, I hope it can help you better understand the TFS check in policy.

    1). Some check-in policies are involved in the TFS itself, and some are here after you installed TFS power tool. For example, ChangesetComments, CustomPathPolicy, ForbbidenPatternsPolicy and WorkItemQueryPolicy are involved in the TFS Power tool, you need to install TFS Power Tool to have them shown.

    2). You can also create one custom check-in policy which may meet your own requirement. Please refer to this article for further information:

    http://msdn.microsoft.com/en-us/library/bb668980.aspx

    Thanks.


    Vicky Song [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by johnzst Monday, September 12, 2011 2:04 PM
    Monday, September 12, 2011 8:29 AM
  • On the Microsoft Minimum Recommended Rules I'm assuming you are talking about the default rule set in FxCop ?  I haven't spent a huge amount of time with this tool yet.

    Gated check-ins are exctly what I'm recommending as part of the second paragraph.   This would also roll into Gated Builds, but you'll need to get a build automation strategy in place to really take advantage of that.  Its not difficult, just something you want to plan out and get a consensus on in your teams.  Another consideration would be to require a work item be associated with the check in (user story, bug, etc.) but I would recommend starting light and dialing in just what you need to get the results you are looking for.

    Thanks,

    Gary

     

    • Proposed as answer by Gary GauvinMVP Sunday, September 11, 2011 7:50 PM
    • Marked as answer by johnzst Monday, September 12, 2011 2:04 PM
    Saturday, September 10, 2011 1:40 PM

All replies

  • Hi John,

    Minimally I'd recommend enabling a manditory checkin comment to capture the nature of the changesets.   The only pitfall to this I've found is that you need to monitor and enforce good, relevant comments otherwise you'll end up with just useless data.  Also, they can just use the Surpress Message function to get around it so you'll need to vigilant on it.

    Depending on your organizations use of Visual Studio's automated testing, another thing to look at would be unit tests that are run at check in to ensure that at least some basic testing on checkin is done.  A caveat to keep in mind with this is that you need to set permissions to prevent devs from disabling or modifying these tests to check in things that wouldn't pass.

    Thanks,

    Gary

     

     


    Saturday, September 10, 2011 1:50 AM
  • Thanks Gary. What is your take on the Microsoft Minimum Recommended Rules and Gated check-in?
    Saturday, September 10, 2011 3:04 AM
  • On the Microsoft Minimum Recommended Rules I'm assuming you are talking about the default rule set in FxCop ?  I haven't spent a huge amount of time with this tool yet.

    Gated check-ins are exctly what I'm recommending as part of the second paragraph.   This would also roll into Gated Builds, but you'll need to get a build automation strategy in place to really take advantage of that.  Its not difficult, just something you want to plan out and get a consensus on in your teams.  Another consideration would be to require a work item be associated with the check in (user story, bug, etc.) but I would recommend starting light and dialing in just what you need to get the results you are looking for.

    Thanks,

    Gary

     

    • Proposed as answer by Gary GauvinMVP Sunday, September 11, 2011 7:50 PM
    • Marked as answer by johnzst Monday, September 12, 2011 2:04 PM
    Saturday, September 10, 2011 1:40 PM
  • + 1 Gary,

    I have the following check in policies set up in my enterprise,

    1. Check In Comments - Ensure the user adds comments against check ins, an immature team may see useless comments, but a bit of training and vigilant monitoring in the early days can help the team mature to provide meanigful comments, that are of great help when release managers are performing merging or a developer trying to trace the changes through version control to identify the cause of a bug.

    2. Work Item - Associate work items to check ins, this is essential and allows you to perform end to end tracibility in your project. Futher to this, if in your build definition you have the option 'Associate changeset to work item' - you will see Team build updating your work items and associating changesets to them.

    3. Code review - Allows you to enforce and track code reviews, a good one for teams that have a balance of senior and junior developers.

    4. Unit Test - The unit tests and code coverage to enforce the developer unit tests the code before pushing the changes in to version control.

    5. Exclude files - My enterprise uses re-sharper, initially we started having developers check in resharper solution files in version control as well, some developers checked in random external dll's as well, some accidently checked in massive changes to config files as well. This policy allows you to exclude check in against certain extension types, over course this can be overridden if required but raises an alert and can be monitored if need be.

    Other policies can be set up as well, but there is very thin line of difference between ensuring the team follows best practices and force rules on the team and they start finding work arounds :)

    HTH
    Cheers, Tarun


    Please remember to mark the replies as answers if they help.

    Tarun Arora

    Blog: http://geekswithblogs.net/TarunArora  Subscribe in a reader

    • Marked as answer by johnzst Monday, September 12, 2011 2:04 PM
    Sunday, September 11, 2011 12:43 AM
  • Thanks Tarun and Gary for your kindly help.

    Hello johnzst,

    Thanks for your post.

    Apart from Tarun’s and Gary’s replies, I also get some more additional information, I hope it can help you better understand the TFS check in policy.

    1). Some check-in policies are involved in the TFS itself, and some are here after you installed TFS power tool. For example, ChangesetComments, CustomPathPolicy, ForbbidenPatternsPolicy and WorkItemQueryPolicy are involved in the TFS Power tool, you need to install TFS Power Tool to have them shown.

    2). You can also create one custom check-in policy which may meet your own requirement. Please refer to this article for further information:

    http://msdn.microsoft.com/en-us/library/bb668980.aspx

    Thanks.


    Vicky Song [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by johnzst Monday, September 12, 2011 2:04 PM
    Monday, September 12, 2011 8:29 AM
  • thank you everyone for your answers.
    Monday, September 12, 2011 2:04 PM
  • You wouldn't happen to have any resources to reccomend for developing a build automation strategy, would you? I am trying to migrate from a monolithic build process to a modular, gated overall build that would be fed by gated check ins and was looking for some suggestions/guidelines/best practices. Any direction is greatly appreciated.

    Thanks

    Tuesday, August 14, 2012 4:11 PM