CODEWITHSUNDEEP
azure-devopsbranching-and-mergingtfvcazure-repos
wizzardmr42
wizzardmr42

Reputation: 1644

How to organise development lifecycle with TFVC

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)

Upvotes: 0

Views: 49

Answers (1)

jessehouwing
jessehouwing

Reputation: 114641

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.

Upvotes: 1

Related Questions