Our team's project solution has several individual projects associated with it, one of which is designed to serve as an underlying framework for our application layer -- call it "FrameworkProject". Only in rare cases should the code for this project be edited, and in these cases I would like to be able to approve the changes to the code. Is there a TFS capability that would allow me to achieve this?
We're using VS2010 and TFS2010.
You have several options:
Implement a custom check in policy and work item type. TFS Code
Review Workflow
Look at Team Review
Implement a process that enforces that any changes must be shelve-set first allowing for a code review. Once the review has
taken place then based on permission the allowed member checks the
code into the Project.
Hope this helps.
Here are a few other options:
You can use check-in locks to prevent check-ins. You can do this by locking the top-level directory that you want to protect. Now, if someone tries to check-in, the check-in will fail and you will need to have an internal process where you review the change, temporarily unlock the folder and allow the check-in to proceed.
You could probably implement a gated check-in workflow that would send an email to you when a check-in was submitted to the given paths. From there you could have some approval process that would allow the gated check-in to complete.
You may create a "working" branch of your framework and revoke checkin rights from the main branch for everyone except the reviewers.
When someone needs to do a change, he has to change the working branch and a reviewer then has to merge the changes to the main branch in this step he will review all changes using his preferred diff tool on the mergeset before checkin in. He may revoke the merge and request fixes by simply undoing his working copy and optionally checking in review comments into the working branch.
Related
I'd like to get rid of an override reason for some code that I've been working on, where previous shelvesets I made from it required an override reason to deal with checkin policy warnings, but where the current version does not.
However, while I can see in Team Explorer the field for override reason when my code violates checkin policy, I can't see the field when it doesn't violate the policy.
Short of deliberately making my code violate checkin policy, how can I empty out the override reason?
The shelveset saves and stores not only your file revisions, but also the Comment, the list of Related Work Items, and check-in notes (if you evaluate policies before shelving).
Select either of the following check boxes:
Preserve pending change locally : By default, this check box is selected. When this check box is selected, your pending changes
(including the comment and the Related Work Items list) are not
removed from your workspace. If you want to clean your workspace to
work on another task, you should clear this check box.
Evaluate Policies and check-in notes before shelving: When you select this check box, all check-in policies are evaluated before the
shelveset is created.
So you could uncheck Evaluate Policies and check-in notes before shelving when you are trying to unshelve. This will not keep any override reason in Team Explore.
If there is any override reason cached in Team Explore. Just manually delete them.
According to your situation, since you are working on multiple shelvesets and not check in pending changes frequently.
Since check in policy will only validate when you are trying to check in pending changes. There is no need to Evaluate Policies and check-in notes for all shelvesets each time. Which may make things complicated and confused.
The best way is unchecking this option during the shelve. And make sure you do not
violate the policy after finally check in option.
Hope this is clearly and helpful.
We are using Microsoft Team foundation server for version control where multiple developers are working on a branch and check in and check out the code.
How can a developer A be notified via email or SMS that his code got overwritten during the checkin by developer B.
Developer A needs to know this ASAP because the code changes of developer A will not work when its deployed into QA.
We are tring to save time in a fast paced development environment and trying to avoid code overwrite issues.
The easiest way to allow continuous parallel development and prevent a checkin from one person breaking the code of others, is to use a CI server. TFS supports this through Team Build.
Though it's preferred to run team build on a dedicated build server, it can be installed side-by-side on your main TFS server and it's possible to install the Controller component centrally and use your developer's workstations as agents.
There are two types of build triggers that can help you out here:
Continuous Integration - this triggers a build of all code directly after every checkin. It will tell you quickly that something did not compile. If you are doing unit tests it can even run these and tell you that a test is failing.
Gated - this will force a developer to shelve his code and will only check in the code when the build of the latest version plus the changes in the shelveset succeed. This may seem even better, as the code in source control will never be in a broken state, but in reality I prefer the ci trigger. The main reason for that us that Gated builds can't happen in parallel (due to their nature) and can actually delay the notification that the code is broken.
You can easily configure email alerts through webaccess on specific build outcomes. You can also configure alerts on source changes, but there is no option to only warn people who have edited these specific files before.
You can also run the Build Notification tool from the task tray to show a notification in Windows.
Though this will not tell the person whose code has just been overwritten that it's no longer working, it will tell the person I rewriting that code that he should pay more attention when checking in ;).
Of course you can configure a team alert that notifies everyone when the build breaks (as that's generally called), and there are funny ways to show the build status through small apps like "siren of shame", which provides a build monitor service that can be connected to a USB alarm-light that turns on and provides noise whenever someone does something stupid.
If you need to avoid this problem during check-in & merge, then I would recommend disabling multiple check-out. This allows file to only be checked out one-at-a-time and can prevent confusion on team projects.
If you need to do farther down the line, you can create TFS Alerts when any code is checked in and sent out to a distribution list, but it would not notify when specific contributions from a specific developer is altered - only a list of altered files during the check-in.
We are starting to work with feature branches and we want to set up a check-in policy that only allows check-ins to the baseline when they have an associated code review.
The new code review workflow in 2012 is quite nice, since you can easily interact with the developer and other reviewers, and comment lines of code directly. Nevertheless it seems like MS didn't think the use case fully because we easily run into the following problem:
The developer works on the feature branch checking-in/shelving and forward-integrating regularly.
When she wants to integrate the feature, she merges back into the baseline and requests a review on these pending changes.
The reviewer makes several comments and now she has to change some code. Where does she do this?
Option 1: Go back to the branch, edit the code and check-in the changes in the branch. Undo the pending changes of the first merge. Merge and request a review again. Repeat until there are no more comments. Check-in the merge.
This is not so nice because all the review comments are in the pending changes of the merge, and she has to work on the branch where she doesn't see the comments directly.
Option 2: Make the edits directly on the pending changes of the merge. Request a review again. Repeat until there are no more comments. Check-in the merge.
If she wants to continue working on the branch, she would have to make a forward integration because the changes from the review are not there.
Either way, the second review is always very annoying, because you have no way of only seeing the changes between the first and the second review, since you are always diff-ing with the baseline.
Am I missing something here? Is there another option that allows reviewing the changes from a review?
Does anyone have a better way of feature branching and code reviewing?
New: Using VS and TFS2013, still no improvements :(
You're not missing anything. This is an unfortunate problem associated with the way Code Reviews were implemented, they can only be linked to one changeset, not to a range of changes.
If your team is used to a high frequency of checkins on their feature branches, then having every individual changeset reviewed using the tool may be a lot of overhead. But that would be my recommendation.
There is a trick, it's not ideal, but it may help. You can check out (on your feature branch) all files that were changed since the last checkin. Then request a review. It will create a shelveset with your changes and associate that to the review. That way you don't have to perform the merge prior to requesting the review. Just make sure you merge the latest version from main into your feature branch before pulling this trick. There are 2 major drawbacks to this:
While all changed files will be linked to the review, the changes since last review won't be highlighted automatically. The reviewer would have to manually do a "Compare to version" and pick the compare target.
There is a limit of 4000 (from the top of my head) files that can be associated to a review, so that may pose a limit to which files you can review as a group (I hope you're not changing 4000+ files between integrations into main).
I think the title explains what i need. We have a very big development department. Everyone checkins and checkouts codes on TFS. But before the checkin operation, an administrator or project manager (or some desired people) must control the code and then confirm or cancel the checkin operation. Because some codes may be incorrect or dangerous. Do you know a tool like that for TFS?
Thanks!
You probably can do it customizing your process on TFS/VS but what we use where I work is:
1) developer does changes and instead of check in, creates a shelveset.
2) manager check shevesets and checkin or send it back to the developer for some rework.
It works fine as long everybody respects the process.
You can have a look on shelvesets here: http://msdn.microsoft.com/en-us/library/ms181403(v=vs.110).aspx
Hope it helps.
We are going to use TFS 2010 for a new project and I'm looking for a best practice and knowledge/experience about using the policy check in option when developing as a team.
I've found information about all this but not really that much information about best practices and what dev teams opinions and experiences about policies, which they used and perhaps should have used.
Which policies did you use?
What was your experience?
What would you recommend?
For instance have you used Microsoft Minimum Recommended Rules and did you use them all?
Information and your experience is appreciated.
The most essential check-in policies are:
Comment Policy - require comments for all check ins.
Work Item association - this should be mandatory as without it you cannot group change sets to a particular stream of work. You need to be able to do this for merging and rolling back changes wholesale.
Gated Check In - While not a policy as such (you need to create a gated build) it prevents developers from checking in code that breaks the build. If you created linked builds across your code base you can ensure your solutions are never broken by check in again. I've done it and it works.
There are many others (we use a Gemini item association policy) and you can write your own as we have. It's not that hard and you can tailor them to fit.
This is more of a discussion question, which is not the type of question StackOverflow usually wants, but I'll bite.
The policies that for me make sense are:
Builds policy
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.
Work item Query
We want people to select their work from the current sprint/iteration. So it's handy to verify that the work people are checking in against is actually pre-approved work.
Custom Path Policy
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 had a couple of projects where time tracking was done (for MSF CMMI) and we used a custom policy to ensure people updated their hours on every checkin.
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.
Merge only policy
This policy allows you to specify a couple of branches that can only receive merges of already checked in work on another branch.
Forbidden Patterns Policy
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 polcies installed on their machines. The Team Foundation Server Power Tools can help you out with the distribution, but those are not deployed and configured on all developers workstations by default.
Also available in blog form.
Try each of the check-in policies to see if they provide value to your team.
Some of our Team Projects require only a check in comment. Some require a comment and a work item. Some require a successful build. It all depends on what the team requires.
Don't try to follow someone else's best practice. Determine what works in your environment.