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.
Related
I have a scenario I am hoping someone will be able to help me think through and determine the best way to handle. The tools I am using are Visual Studio 2013 and TFS.
We had a developer leave our company abruptly, and he has a lot of code changes for a client project which were not yet checked in. We have the code base with his changes locally. We also have the client's TFS server with the latest code. I do not have documentation of his changes, so my goal is to find all the code changes he has made. Keep in mind I also do not have access to his machine, I just have access to the local code base which he was working on, which includes his changes.
I began by comparing his code with the client's code on TFS, and looking for changes. However the client has also made some changes to their code in the 2 months since this developer began working on this project. So within those two months he made some changes locally and the client also made some changes which were checked in on TFS.
When I compare his code to the latest copy of code on the server, I can see the differences, but I can't seem to tell who made the changes. If a method was modified, I see that different versions exist on TFS and in this local code, but I cannot tell who made the change. Did the client make the change to the code, and the newer version on TFS makes my version look out of date? Or did this developer make the change to the code, making the server code look out of date? As the changes done by our developer were not checked in, I do not have a history showing me who made the changes to the code. What would be the best way to determine the changes our local developer made?
So, to sum it up: I have compared his local code to server code, and have seen the differences, but the client has also made changes to code since he acquired it. So the differences between his code and server code could either be due to his changes or client changes, but I don't know which.
I see a few ways which could make your life easier, but it requires you to know which version your developer initially downloaded. With that version (Changeset, Label, Date) you can make a comparison against the local workspace and find all the changes to that version on the server.
Workspace version
You can initiate the diff from the commandline (as well as from Visual Studio, but command lines are much easier to post on Stack Overflow):
tf folderdiff c:\sources "$/TFSProject/Path/To/Sources;C12345" /recursive
/collection:http://your.client.tfsserver.com:8080/tfs/ProjectCollection
/view:different,sourceonly
In the place of C12345 you can either enter the Changeset number that was used to create the workspace on your developer's machine or the label (use Llabelname instead of Cnumber) or the (approximate) date (use D2014-12-20).
This will output a list of files that have changed locally against the version that was used to create the workspace. Now you can list each file individually using:
tf diff c:\sources\changedfile.cs /version:C12345
(or use the same version spec as above if you used Labels or a Date).
There is another option, if the workspace is still registered on the TFS server, and that is to compare against the workspace version:
tf folderdiff c:\sources "$/TFSProject/Path/To/Sources;Wworkspacename;owner" /recursive
/collection:http://your.client.tfsserver.com:8080/tfs/ProjectCollection
/view:different,sourceonly`
Followed by:
tf diff c:\sources\changedfile.cs /version:Wworkspacename;owner
You do not need to own the workspace in order to do this, but the server must still have a record for that workspace on the server. You can try finding the workspace using the command:
C:\Sources\>tf workspaces /owner:avanade-corp\jesse.houwing /computer:jessehouwing
/collection:http://your.client.tfsserver.com:8080/tfs/ProjectCollection
Collection: http://your.client.tfsserver.com:8080/tfs/ProjectCollection
Workspace Owner Computer Comment
----------------------- ------------- ------------ ----------------------------
JESSEHOUWING Jesse Houwing JESSEHOUWING
The example above would lead to:
tf folderdiff c:\sources "$/TFSProject/Path/To/Sources;WJESSEHOUWING;Jesse Houwing" /recursive
/collection:http://your.client.tfsserver.com:8080/tfs/ProjectCollection
/view:different,sourceonly
Create a shelfset
If you do have the option to get access to the system (even if logged on as a different user) you can take ownership of the workspace and create a Shelveset of the changes. You can then unshelve these changes on a more recent workspace and Visual Studio will prompt you to resolve merge conflicts. TFS will know which changes were made by the other party and will try to auto-merge the changes as best it can.
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.
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.
I am managing a build lab and have several products/branches to provide service to and I would like my build machines not to be specialized to any one product/branch.
The scenario I would like to have is that souce and all tools needed to build it are checked into source control and just sync and build with some prep/env setup before hand via script.
This is very doable with Visual Studio and many other tools. Is it possible with Xcode? Has anyone gotten a scenario like this to work?
Some system components may need to be shared. Since this is such an atypical scenario, documentation will not be readily available. I would suggest asking on the Xcode-users mailing list that Apple maintains, as you may get a more certain answer.
I doubt if this possible. There are 2 possible ways I know of.
First, which we also follow in our project:
Source code for all projects in checked in the common repository.
A remote server is configured to point to this repository.
Remote server has XCode pre-installed. A pre-written scripts with steps including workspace cleanup, checkout fresh code, build the code, package the output is already feed into the remote server. Of these XCode related commands are using xcodebuild.
Remote server can be configured in 3 ways: a) Build the source code on every checkin, b) Build the source code triggered by user, c) Scheduled building of the source code.
Build results are emailed to the configured email addresses.
Second way is the continuous integration with MAC OS X server.
Just in case you found out the exact system config you are looking for, please post an answer here to enlighten us as well.
I'll try to make this as straight forward as possible.
Currently our team has a VSS database where our projects are stored.
Developers grab the code and place on their localhost machine and develop locally.
Designated developer grabs latest version and pushes to development server.
The problem is, when a file is removed from the project (by deleting it in VS2008) then the next time another developer (not the one who deleted it) checks in, it prompts them to check in those deleted files because they still have a copy on their local machine.
Is there a way around this? To have VSS instruct the client machine to remove these files and not prompt them to check back in? What is the preferred approach for this?
Edit Note(s):
I agree SVN is better than VSS
I agree Web Application project is better than Web Site project
Problem: This same thing happens with files which are removed from class libraries.
You number one way around this is to stop using web site projects. Web Site Projects cause visual studio to automatically add anything it finds in the project path to the project.
Instead, move to Web Application Projects which don't have this behavior problem.
Web Site projects are good for single person developments.
UPDATE:
VB shops from the days gone past had similiar issues in that whatever they had installed affected the build process. You might take a page from their playbook and have a "clean" build machine. Prior to doing a deployment you would delete all of the project folders, then do a get latest. This way you would be sure that the only thing deployed is what you have in source control.
Incidentally, this is also how the TFS Build server works. It deletes the workspace, then creates a new one and downloads the necessary project files.
Further, you might consider using something like Cruise Control to handle builds.
Maybe the dev should take care to only check in or add things that they have been working on. Its kind of sloppy if they are adding things that they were not even using.
Your best solution would be to switch to a better version control system, like SVN.
At my job we recently acquired a project from an outsourcing company who did use VSS as their version control. We were able to import all of the change history into SVN from VSS, and get up and running pretty quickly with SVN at that point.
And with SVN, you can set up ignores for files and folders, so the files in your web projects dont get put into SVN and the ignore attributes are checked out onto each developer's machine
I believe we used VSSMigrate to do the migration to SVN http://www.poweradmin.com/sourcecode/vssmigrate.aspx
VSS is an awful versioning system and you should switch to SVN but that's got nothing to do with the crux of the problem. The project file contains references to what files are actually part of the project. If the visual studio project isn't checked in along with the changes to it, theres no way for any other developer to be fully updated hence queries to delete files when they grab the latest from VSS. From there you've got multiple choices...
Make the vbproj part of the repository. Any project level changes will be part of the commit and other developers can be notified. Problem here is it's also going to be on the dev server. Ideally you could use near the same process to deploy to dev as you would to deploy as release. This leads into the other way...
SVN gives you hooks for almost all major events, where hooks are literally just a properly named batch file / exe. For your purposes, you could use a post-commit hook to push the appropriate files, say via ftp, to the server on every commit. File problems solved, and more importantly closer towards the concept of continuous integration.
Something you may want to consider doing:
Get Latest (Recursive)
Check In ...
Its a manual process, but it may give you the desired result, plus if VS talks about deleted files, you know they should be deleted from the local machine in step 1.