Let's walk through creating a standard Build VM
You are here
TFVC Policies You Should Use
Azure DevOps TFVC have some policies that help prevent issues.
We'll take a look at a few that I would recommend.
One the check out side, we have two that i would recommend. They are to enable Multiple Check-out and also Enable get latest on check-out.
Enable Multiple Check-out
This will allow more than 1 user to edit a file at a time. If there are any conflicts, they are resolved before check-in by the party causing the potential conflict. If you are familiar with AX 2012 development, typically you would have 1 person work on 1 element at a time. That is no longer a requirement or even a suggestion as we have better tools to resolve conflicts now.
Enable Get Latest On Check-out
This will will do a get latest on the element you are checking out at time of check-out. This is helpful in making sure you have the latest code in the branch, even if you are getting latest frequently as there may be some changes you aren't aware of. You can still run into conflicts later but this is a preventative for that issue. Also, If you have a more junior resource that isn't as fastidious or disciplined with their get latest cadence, this will help prevent issues from stale versions of files being committed because they simply failed to do a get latest on their own.
Simply requires that the changeset have some comments. You should also have a standard for what your comments look like so they contain meaningful info.
Again, a simple policy that requires you associate the changeset with a work item. Depending on how you set up your work items and boards, this could be product back log item, a task, a bug or any custom work item you create. We just need something to associate the changeset with.
Work Item Query Policy
This is a more advanced option and requires Microsoft Visual Studio Team Foundation Server 2015 Power Tools. Similar to the Work Items policy but this limits the available work items to a specific query specified on the policy. This could be used to limit association to work items that belong to a particular user (like @me) or for a specific iteration path. This requires an association and limits what we can associate the changeset with.
This is a more advanced option and requires Microsoft Visual Studio Team Foundation Server 2015 Power Tools. This will allow you to define patterns for files that aren't allowed to be checked in. This can be helpful when creating a new package and model and you have a development resource that isn't sure what to check in and doesn't ask for help. Looking at the below screenshot, you can see a few different files and folder that aren't required for source control and are generated artifacts from the source so we don't need them.
We can filter out some common items we know we don't want like so
When you have these check in policies enabled, when staging a commit, you'll see this:
If you are going to use the Work Item Query Policy of Forbidden Patterns policies, the Microsoft Visual Studio Team Foundation Server 2015 Power Tools are required. If you do not have these installed, you will get an error when checking in even if the conditions for the policies are met.