TFVC Branching and Build Pipeline

(0) Share

Report

Posted on by HAIRUL HAZRI

1,214

Hi,

Due to incoming All-in-one deployable package enforcement, I'm trying to setup version control and build pipeline.

I have successfully created a build pipeline using Microsoft-hosted agent.

My next challenge is to setup the whole development & deployment workflow, when I don't even know how to use TFVC.

We have 1 DEV, 1 UAT, 1 Production environments.

Our typical situation is we will have multiple requirements in DEV with some of them deployed to UAT. Among the multiple requirements deployed to UAT, we will need to deploy only partial of them to Production, depending on which has given the permission by customer to be deployed. Customer will test the deployed customization in UAT according to their best interest, not necessarily will follow the order or deployment. We even have customization in UAT pending for testing since last year, but a recently deployed ones can go into Production first.

I simply follow the recommended folder structure:

Metadata is mapped to K:/AosService/PackagesLocalDirectory

Projects is mapped to UserId/Documents/Visual Studio 2015/Projects

After I check-in everything to Azure Repos, I convert Main to branch, and create DEV branch from Main.

At this point, how do I make changes on DEV branch without affecting Main?

I created K:/AosService/PackagesLocalDirectory-DEV folder and map it to DEV/metadata.

I created UserId/Documents/Visual Studio 2015/Projects-DEV folder and map it to DEV/Projects.

When I try to open any solution from DEV/Projects, Cloak menu appeared:

I don't understand what's going here. I don't want to cloak the folder. I'm just trying to open any element in DEV branch, make changes, and merge to Main. What did I do wrong?

Thank you.

I have the same question (0)

All responses (7)

Answers (5)

Sort by

Verified answer

Martin Dráb 239,660 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

If you development branch is DEV and not Main, your development should be mapped to DEV. For example, K:/AosService/PackagesLocalDirectory should be mapped to $/.../Trunk/DEV/Metadata instead of $/.../Main/DEV/Metadata.

Also, consider whether you shouldn't change your processes as well. The changes abandoned in UAT may influence your tests in UAT - you'll test something else than what you'll have in production. That you successfully test something in UAT doesn't mean that it'll work in Prod or that it can be deployed there at all. Also, you cherry-pick changes from UAT and deploy them to Prod without integration testing.

You'd benefit from switching to formalized releases. Changes excluded from deployment should be removed from UAT (which should be relatively rare), then you do integration tests in UAT and then deploy the tested version to production.

Was this reply helpful? Yes No
Verified answer

nmaenpaa 101,172 Moderator on at

Like (0)

Report
Copy link

Link copied!

You can only deploy the complete UAT contents to Prod, you can't pick individual customizations.

If you need to test stuff that is not going to prod, you will need one more test system.

And you need a separate branch for each codebase that must be deployed to some system.

1) First develop in DEV branch - and possibly deploy the contents of this branch to a "DEVTEST" system.

2) The accepted changes are migrated to MAIN and deployed to UAT

3) UAT contents gets deployed to Prod.

Was this reply helpful? Yes No
Verified answer

nmaenpaa 101,172 Moderator on at

Like (0)

Report
Copy link

Link copied!

Additionally, today you can map your VS to only one branch at a time. And that branch must be mapped to AOSService/PackagesLocalDirectory.

For merging code to Main branch you should have another dev system which is mapped to Main branch.

MS is working on making it easier to switch between branches, and have multiple codebases on your dev system. But today it's not possible. If you want to work with multiple branches on the same dev system, you always need to delete your old workspace, create a new one, get latest, build and sync when changing branches.

Was this reply helpful? Yes No
HAIRUL HAZRI 1,214 on at

Like (0)

Report
Copy link

Link copied!

I see. That makes sense now.

But if we were to have the "DEVTEST" system, our customer will need to subscribe & pay for the new environment am I right?

This is unexpected. I was hoping we can keep our current practice and implement version control+build automation without costing our customer more, especially a new environment subscription.

Regarding the removal of Tier 1 Microsoft managed VMs, I understood that qualifying customers will get Azure credits to deploy a new DEV from Azure portal.

Is it possible to somehow deploy "DEV" & "DEVTEST" only with existing subscription? I mean, we should be able to completely control the VM specs, right? Does that make sense?

Was this reply helpful? Yes No
Verified answer

nmaenpaa 101,172 Moderator on at

Like (0)

Report
Copy link

Link copied!

If you are developing customizations in the project, you will need more environments than what are included in the D365FO subscription. There's no way around it.

- Whenever you deploy code to Prod system, you deploy the entire codebase of UAT

- You said that you want to test functionalities that are not allowed to be part of the next Prod release

This means that you need two test systems.

Normally you also need a Golden configuration system. Additionally you might need a system that always has the same codebase than Prod, so that you can export Prod database to it for quick debugging of critical prod issues (Support system). Each developer needs their own Dev system. And so on.

Was this reply helpful? Yes No
HAIRUL HAZRI 1,214 on at

Like (0)

Report
Copy link

Link copied!

Thank you Nikolaos for the clarification.

One more thing. You mentioned that :

"MS is working on making it easier to switch between branches, and have multiple codebases on your dev system. But today it's not possible."

Is there currently any ETA for this to be available?

Was this reply helpful? Yes No
Verified answer

nmaenpaa 101,172 Moderator on at

Like (0)

Report
Copy link

Link copied!

It's been announced a long time ago but I'm not aware of any ETA.

Last year it was supposed to be available in preview but as far as I know, it's not - at least not in public preview.

docs.microsoft.com/.../platform

Was this reply helpful? Yes No