My development team is using TFS for source control. My current plan is to have a new shared branch created each sprint for the developers to use for all their tasks.
What is the best way to ensure that the developers are performing forward and reverse integration every day for that branch? In other words, how do I make sure they are constantly getting the latest code set from the sprint branch and checking their code in as well?
There is no such VS extension can force developers to get code from TFS and check in frequently and continuously.
If which you want is to "get the latest " and avoid TFS force you/colleagues to resolve conflicts before checking in.
However, TFS redefined what "Get Latest" does. In TFS terms, Get Latest means get the latest version of the files, but ignore the ones that the server thinks is already in your workspace. Moreover, doing a get latest is good practice, but not mandatory. There is no such settings.
There has been some similar questions in SO and got an amazing answer, below links for your reference:
Is performing a Get Latest mandatory before checking in in TFS so you do not overwrite/lose code?
Why doesn't TFS get latest get the latest?
As a workaround, if you really need this feature in your team, you could set up a reminder such as meeting reminder in outlook 4:00PM to remind your colleagues, they should merge their work in the branch at the end of day. Just couldn't force them to do this.
This is a people problem, not a tooling problem. There's no way the tool can force their behavior when it comes to committing their code or merging branches. It's just part of workflow discipline, which will come with time.
Related
I am used to working with Perforce and I really like the ability to be able to group checked out files under different pending changelists. For example, if I am working on two bugs at the same time and the changes made for them can be grouped separately.
I am unable to find this functionality in TFS. Is this supported? If no, what is the best practice around it?
I am using VS 2015 Professional with TFS Server 2015.
No, it's not supported with pending changelists in TFS for now.
To be a workaround, this is possible using the Suspend/Resume feature in Visual Studio 2012 and above. It will allow you to keep multiple shelvesets, associated to multiple workitems. Only problem is that you can't have all two bugs open at the same time, so you'll have to check them in one by one.
More detail info please refer this link: Suspend your work and manage your shelvesets
I just started using TFS last week in a new job. My previous experience has primarily been with Subversion and one thing I liked about Subversion is that it forces you to get latest before checking in anything that would be conflicting. Furthermore, you have to resolve conflicts (or explicitly mark them as resolved even if they aren't really).
In TFS it seems like people are inadvertently wiping out other people's changes from time to time when 2 people have worked on the same file. I'm sure this is certainly due to inexperience with TFS, but it seems like the workflow of Subversion made it harder to do this and while I regularly had to help people resolve conflicts in Subversion, I don't remember having any real issues with people wiping out other people's code accidentally.
Is there a way to make TFS force you to get latest AND resolve all conflicts before checking in?
This could depend on a few things but most relevant could be the workspace setup (local or server). For example, the server workspace provides you the option to enforce the get latest. Other differences could include the types of locks available under each workspace type.
Here's a couple of post on the subject:
http://msdn.microsoft.com/en-us/library/bb892960.aspx
http://blogs.msdn.com/b/phkelley/archive/2013/05/29/server-workspaces-vs-local-workspaces.aspx
I'd like to know if it's possible (and how, if anyone has ever done it before) to have Mantis Bug Tracker "tickets" automatically imported/transformed into TFS work items.
We use mantis to keep track of development and TFS as a Repo. Every check-in made to TFS must be associated with one work item. Right now, these two systems are not integrated which causes, for example, that the ticket 100 is relative to the work item 497 without no way of knowing that one is relative to the other.
I've looked at TFS Integration Tools but was unable to install it for some reason at this time.
So, how can I have an automation process that "imports" Mantis tickets into TFS work items automatically? Is this even possible?
There is a plugin for source integration which supports Git, SVN and Mercurial (experimental).
https://github.com/mantisbt-plugins/source-integration
I am not aware that there is something similar avalaible for TFS, but it should be no big problem to implement TFS integration based on the framework which is offered by the plugin.
In TFS there is an option in Visual Studio to "Keep Items checked out when checking in" what is the purpose of giving such an option?
I am trying to build a reporting tool to find out the list of files that are checked out, so in the case the user has set the above option would my report be accurate, since the developer can always claim that "Hey, all my changes are checked in"
How do i reflect those kind of checkout in my report?
I use this feature when part of what I'm working on is needed by another developer, but I haven't actually finished the whole task.
Your report would still be accurate, as it's a true reflection of the system - the code really is checked out, and the developer is probably still working on the file. The only way you can truly know if all changes are checked in is by comparing the current version from source control with each developer's locally checked out copy, which isn't going to be feasible for reporting purposes, and is probably of limited value.
In a modern CI environment it's very common to commit changes and simply keep changing the very same modules.On the other hand, once a milestone is reached, the developer will simply commit the changes & start working on something else.So, I think it's very natural for TFS to provide with this configurable flag.Another major feature in the TFS ecosystem is gated-checkin: is this mode the commit is shelved, built & committed once all that has succeeded. If it weren't for this option, the developer would have to stand still & wait until the process has finished.I would disagree with a developer stating "Hey, all my changes are checked in": our principle in the team is that everything that is checked out is being developed, anything else is/should be either shelved or committed.You could consider a rule that all pending changes of each developer get shelved at the end of the working day. I am personally against any such measures, but would surely examine them as a option if my devs wouldn't adapt to the principle.If you would agree to the above, your second question would become rather obsolete: In my opinion there aren't several 'kinds' of checkouts.
Currently our build solution is set up using TFS + MS Build scripts.
TFS is also being used as a CI server.
I've seen several posts on this site telling people about other CI solutions.
Are there any compelling options to move to another Solution for our build system?
Or in other words what are we missing out on by using TFS?
EDIT
We are using TFS for source control / issue tracking and I think this is a good solution, im just wondering about the other options for build server / CI server integrating with TFS.
The main problem with TFS is that if you have a server crash, restoring your source code is non-trivial. This is unbelievably bad since the most important aspect of any source control system must be to be fail-resistent, at least if you perform all backups as you should.
IMHO the greatest benefit of TFS is that everything is integrated in the IDE: work items, bug tracking, CI, Code analysis, ...
I have used TFS in the past but my current company use SubVersion/Team City/FogBugz to implement the same functionality provided in the TFS solution.
I would say that from a technical implementation perspective, you can gain additional features from a non-TFS system that TFS would be a nightmare to configure.
However, that said, one of the biggest reasons for not going for TFS is the cost of running such a system. The big advantage of TFS is the integration of everything which makes people use it more as the more you put in, the more you get out. The worst case scenario is a system that people can’t be bothered using which adds no value to the company’s development.
In my opinion, if you are already on TFS and can afford to stick with do, do just that!