A blog about Regular Expressions, .NET and everything Microsoft that crosses my path.
Which Check-in policies do you use with your projects?
Team Foundation Server allows an administrator to define a Check-in policy to ensure all code that is checked in conforms to a certain standard and that a minimal set of quality attributes have been applied to that code. Not all of these policies make sense in every situation and implementing them can be negatively perceived by the development team. It's often better to explain (over and over again, in person) the benefit of doing things right, them let a tool tel people what to do.
Please comment on any great policies I might have missed or ways to be able to remove these policies in place completely!
The policies that for me make sense are:
This policy prevents a build queue of failed builds after someone breaks the build. You will actually be warned that the build is currently broken, so that someone can fix the build before continuing.
Work Item Association
We need work item association to ensure we can trace checkins to work being done an through that to testcases.
We use this policy once in a while in Team projects that house more than one project and where we want to increase quality or security on one project, but are not interested in bothering the other project. Or to prevent certain checkins on the current release branch, but don't want such stringent policies on an old release that is still being maintained.
We verify a few things which you could do through checkin-policies by failing the CI build instead. This is done mostly to save time on the developers machines.
Code Analysis Policy.
Instead of using a checkin policy for this, we use a CI build which will fail if certain Code Analysis rules are broken. This allows us to let the developer builds skip Code Analysis on every build. People will learn pretty quickly how to prevent these rules from triggering anyways.
We're not using any other policy. The Require comment for change set policy is something we sometimes use, but most teams actually don't need a policy for this after some time. Having no comments on a checkin is frowned upon by most and this resolves itself.
We're not using any policy to enforce Code Coverage or Number of warnings. These can be added to the build if needed through build process customization.
We use Gated Checkins on branches that require additional verification. Such as release branches and branches that are followed by automatic deployment.
We often allow developers to by-pass any checkin policy without penalty. Same goes for gated Checkins. It is up to the developer to use these rights wisely. Breaking a deployment is something you cannot do too often before being noticed by the team ;).
There are a few interesting custom policies out there as well, but I know only a handful of people who actually went as far as to use these.
I've sometimes used these to ensure no /bin/debug, .exe or .dll was checked into a //src/ folder in TFS.
There are a few more policies from 3rd parties, but I've never used those. These include:
The Checkin Policy Pack and that page lists a couple of extra policies that I've never had to use either.
One of the reasons for not using too many 3rd party policies is that all team members need to have the polciies installed on their machines. TheTeam Foundation Server Power Tools can help you out with the distribution, but those are not deployed and configured on all developers workstations by default. Based on my answer to a (rather old) question on StackOverflow.
Jesse is passionate trainer, mentor and coach helping teams improve their productivity and quality while endeavoring to make work an activity's fun. He uses Scrum, agile practices and a selection of tools to do so.
Before focusing specifically on Agile methodologies and Application Lifecycle Management, Jesse used his knowledge and expertise in Microsoft .NET technologies including the .NET Framework, C#, ASP.NET and WCF to build solutions and he worked with a multitude of other languages and technologies including Java, PHP and Coldfusion.
Jesse has worked on a number of projects, each special in its own way in a very diverse set of companies, including education, government, finance and supply chain management. Some very small and specialized, others spanning multiple continents and working with broad subjects.
Over the years Jesse has developed training material and taught on a number of Software development subjects such as Scrum in particular, but also Testing using Visual Studio, Object Oriented Analysis and Design, Design Patterns, UML, Regular Expressions and the .NET Framework.
He love Regular Expressions, LINQ and other code riddles, they're like sudokus and can be real brain teasers. He's married with Charlotte has his first daughter on the way and I takes photos everywhere he go.