I believe I read there's a way but I can't seem to find it.
I want to see what check-ins and what users have overridden the gated build, or other policies. Where can I look?
The tfs power tools has an alert explorer that you allows you to setup emails if a policy is overridden.
I believe it also allows you to setup a call to a webpage with the information.
Related
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.
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.
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.
How can I protect myself and my colleagues to press on publish production "by accident".
I know I can hide this by right click but I does not want that, I don't want to remove the production publish.
I am looking for a toggle to set it "on" and use it ans set it off again.
Do you know what I mean??
Thanks in advance.
I've adopted the practice of only publishing from a single build machine via script. This eliminates the risk and provides and automated method of publishing. Publishing from a developers machine directly is inherently risky.
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.