background: I am the only developer in a company, and I am forced to be the system administrator as well. We also have to upgrade a couple of times a year with a gun to our head. i.e. there is no possibility of delaying the upgrade.
This is what I have been doing
version 1: dev and release branch.
Before upgrade create "Version 2 Release" from "version 1 release" branch.
Once code is upgraded, generate build from "Version 2 Release" and apply to PROD.
After prod is upgraded, create "Version 2 Dev" branch from "Version 2 Release" and apply pending changesets from "Version 1 Dev" to continue working.
Do you see any problems with this? Our branch size if < 500 mb.
I prefer above approach (which is non-standard, had to learn on the job) because there is no headache of merging back the branch once code is upgraded. There is also no need to generate a build and do sanity check after merging back. Further, my earlier branch remains active in case there is any last minute code fix needed on prod.
Your approach seems quite practical given your constraints and the need to minimize risk during upgrades.
By creating a new release branch before the upgrade, you avoid the complexities of merging back changes, which can be error-prone.
Keeping the earlier branch active allows for quick fixes if needed, which is crucial in a production environment.
You can also check the doc Choose a branching strategy with a DevOps mindset for this topic.
Need to mention is, DevOps product team gradually plan to phase out TFVC in all new projects and organizations, they added no new features to Team Foundation Version Control (TFVC) in past years. Git is the preferred version control system in Azure Repos. You can consider to migrate the TFVC to git type repo to get more feature and security in future. Please check the link for the details.