My team has recently upgraded from VSS to TFS 2013. In the past, there was a hard and fast "no checking in until the Item is complete," rule, but this is being challenging by a couple of newer team members, who have experience with Agile.
At the moment, I am working on a rather large change. In the past, per our existing rule, I would not check in until it was fully complete (about two months' worth of work). With TFS, we have some other options available, however, and we strive to get to an Agile process. When talking about this with the team the other day, the two newer members were adamant that I just check in my changes (to the trunk, which is our dev branch). My problem with this is that many of the files I changed are commonly modified in each release cycle. If I check in before the feature is ready for release, and they then merge their changes with my changes, we can now not release either change until mine is ready.
The current solutions on the table for this problem are:
- Create a branch specifically for this feature. This does not mesh with our chosen branching strategy (code promotion), but is considered a special case.
- Use a shelveset. This way, at least my code is backed up on the server, and I can merge it all later when I am done.
- Use My Work (honestly, I just found out about this feature a couple hours ago). Same basic principle as a shelveset, though it seems to be "better practice."
Which of these (or perhaps #4?) is the best solution to our current problem? We are aware that in general our processes have issues, and we are working on them, but it will take time to implement an actual Agile process in which the work is broken down such that checking in early and often is easy and causes zero issues.