0

We're working on a system where we're going to be making a lot of changes over the next year or so. We use Azure DevOps with TFVC. Our plan is to develop, test internally, release into a staging environment for the client to test internally, and then release into the live environment once the bugs are ironed out, but we want to do this in fairly small iterations, so we're not releasing massive changes at once and we can get early feedback on changes to make sure we're on the right track and don't get flooded with loads of issues to fix after a big update.

The problem that is worrying me is that once we've released into the testing environment, it is going to take time for the client to test it, and during that time, we'll have been working on other improvements/bug fixes. If the client simply says that everything is fine, I can use VS to Get Specific Version as of the time we released the staging version and build and release that to live, but if there are any issues that come up and we need to fix those, we'll end up having to get the client to test all of the new stuff that we've been working on, and we may be in the middle of large changes that aren't practical to release to staging.

I've looked at TFS branches, but they seem to mess up the paths and be a pain to set up and work with, and I feel like they aren't really for this kind of situation.

How do people generally solve this problem?

(I appreciate that many people will argue that Git is a better source control system, but I'm specifically asking how to do it with TFVC)

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
wizzardmr42
  • 1,634
  • 12
  • 22

1 Answers1

1

Branches in TFVC are far from lightweight and can make switching between branches locally awkward.

The changing of local paths when switching is hard to avoid, it can be done by changing your workspace definition, remapping the folders and forcing a get latest.

Another option to use here is git tfs, it will allow you to use TFVC on the server, but Git locally and get the local benefits (including multiple local branches and the ability to switch between them in place).

A technique to work with environments and approvals while development is ongoing is to create promotion level branches. One branch for active development, branch from that a branch for the next environment (test) and then the next (acceptance?) all the way to you reach production.

 Development
 \— Test
       \— Acceptance
             \— Production

Each time development has stabilized enough, merge the code to Test. Any issues can be fixed either directly on Test or by fixing them in Development and then cherry-picking.

The larger the distance between Development and Production the harder it will become to keep the branches in sync.

An alternative is to use release branches basically collapsing the above structure a bit:

 Main
 \— Release 1
 \— Release 2

Active development happens in Main, code is merged and hot fixed on release branches. Any changes made on a release branch must also be merged back.

There is a better solution

Instead of trying to be more productive by working ahead on new features, can you help the client test the potential releases faster? In that case you won't need to wait too long for the testing to finish, can provide super quick fixes and then switch focus on more new development. It will prevent all kinds of issues with merging, reappearing bugs from code that wasn't merged back to main correctly etc.

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
  • The ALM Rangers have created a Branching Guidance for TFVC in the past. You can probably find a copy somewhere. We have changed the guidance to follow the latter advice in my answer, try fixing the problem that cases you to have long-lived branches. – jessehouwing Sep 25 '20 at 22:10
  • I had a feeling someone was going to mention Git. I've never really liked it in the past when I've used it and there are complications that we've got about 20 different DevOps projects for different clients, most of which use a shared DevOps project for our common code, so switching to Git would be quite a big job. Unfortunately the client has limited time available to test, and we don't have the business knowledge to have confidence that everything is working correctly. Do you need to update linked projects to use git tfs though? When you say locally, does that only work for 1 coder? – wizzardmr42 Sep 27 '20 at 13:30
  • Each coder can check out TFS branches and switch freely locally. The server would remain unaware. – jessehouwing Sep 27 '20 at 16:35
  • But shared projects or shared code outside of your branches would cause problems. Can you break the dependencies using nuget packages of shared code? – jessehouwing Sep 27 '20 at 16:37
  • But your real bottleneck is at the testing capacity. Solving that will make the rest of the problems go away. Working around it will only remove the need to fix that, but will keep your work a mess. – jessehouwing Sep 27 '20 at 16:39