Transitioning from TFVC to Git

September 30, 2020    DevOps Culture Process Git TFVC

Transitioning from TFVC to Git

I’ve had the opportunity to work for a company for 2 years now. The have a lot going on. They use TFVC, which works, but I quickly realized how much I like Git over TFVC.

I “grew up” with TFVC. Then a previous company decided to make the transition. It took us all a bit to get used to Git and learn it, but after using it we never looked back.

"Is it ever a good time to switch source control?"

~a knowing co-worker

I think that now is the time and here’s how I/we went about transitioning. (as I write this on 9/11/2020 we are in the planning and training phase)

Az DO = Azure DevOps tool (on premise or hosted)

TFVC = Team Foundation Version Control, the tool used for Source Control developed by Microsoft. It was the main tool I used from 2006 to 2016 or so. It’s better then SourceSafe was :-).

The Business Value Case / Hypothesis

We shouldn’t move to Git just because it is a shiny “new” toy (it’s not new anymore, but there is still that perception from teams that are using TFVC). We have to have a return on investment (internal training, planning, migrating builds/releases/codes, dealing with interruptions as we learn, etc). My hypothesis/value proposition is this

Moving to Git from TFVC will increase developer productivity, improve the code review process, reduce onboarding training costs, attract talent, boost moral/Net promoter score and encourage more continuous integration of code. The benefit gained and time saved will far outweigh the cost of time (migration planning, execution and overcoming obstacles).

I don’t have hard evidence, but from past experiences and people I’ve talked I see this as working well.

Steps to a Transition

Step 0 - Introducing the idea, gauge interest, is it the right time?

I found myself bringing it up on occasion (nudge, nudge), not to sow discord, but I really felt and knew that switching to Git would “improve daily work” and help developers to be more productive. It would also reduce training time for new hires, possibly help attract talent and make me more happy in my daily job. There has been a shift in culture in the last year and I’ve been able to bring up some safe to tries and have heard support from the team on wanting to move to Git.

I recommend proposing these changes as a “Safe to Try” experiments. Write up a hypothesis, steps you want to take and how you wil measure the results.

Survey

I created a survey (with input) on Microsoft Teams. We had about half respond. It was a normal Bell curve of responses. After the survey, we learned some things and felt like we could continue moving forward. Here are the questions we asked:

  • What department are you in (Dev/QA/tech writers/other)?
  • How would you rate your familiarity with Git as a source control tool?
    1. What is Git?
    2. I’ve heard of Git
    3. I’ve learned about Git, but haven’t used it much
    4. I’ve used Git in the past/present and am proficient in it
    5. I’ve used Git in the past/present and would like to help teach and train others to use it here.
  • What is your reaction to the idea of migrating from TFVC to Git?
  • Have you used TFVC outside of our company?
    • If not, how hard was it (how much learning time) to become comfortable with TFVC?
  • What things should be considered for the Circle if more safe to try experiments are proposed for moving to Git?
    • Does your development process prohibit the use of Git?
  • What source control tool would you prefer?
    • TFVC, Git, Subversion, something else
    • If you answered “something else”, what is it?
  • Do you have other things you want to share?

Step 1a - Training

Put together training resources. I have a lot in my article Some Git Help.

Hold a workshop. Do a book club using (https://git-scm.com/book/en/v2). Learn together. Setup a Git playground repo with assignments.

Here’s a nice cheat sheet of TFVC to Git terminology.

Some Assignment Ideas

  • Assignment - add your name to a readme.md
    • Get latest, create local branch, change, make commit, create PR, get feedback,
    • Before you complete the PR (Pull Request), add a short description about yourself (where do you live, what do you enjoy, family information, etc). Make the commit push to the PR
    • complete PR
    • What did you learn?
  • Assignment
    • Experience how it’s faster
    • Rename, delete and move files in Visual Studio (no hang)
      • Do the same in TFVC in Visual Studio and compare
    • Switch branches
    • Git pull (or pull latest in VS)
      • Do the same in TFVC Source Control Explorer in Visual Studio and compare
    • What did you observe?
  • Assignment - Deal with merge conflict, rebase from master
    • How to simulate?
    • Merging Changes Together - Using Git
    • What did you learn?
  • Assignment - Merge into the next branch
    • Cherry-pick into new server branch
    • Cherry-pick your change to RC
    • What did you learn?
  • Assignment
    • Amend Commit- Create a branch Add a commit, add another commit and amend it
    • In Visual Studio
    • In the command line
    • Reset to remove a commit - Create a branch, add a commit, reset that commit to remove it from the history
      • In Visual Studio - Git history
      • note: Make sure you are in the correct branch before using reset

Step 1b - Planning

Training and planning can be done in parallel. There are many questions to be answered and actions to be prepared for. Microsoft has a great guide that you should start with. They have a checklist at the bottom.

Here are a few questions to consider:

  • Can you move smaller pieces at a time in Safe to Tries?
    • How long can you live with using TFVC and Git at the same time?
  • Are you going to have a mono-repo or multiple repositories?
    • Mono repos have benefits and challenges. They can be organized by folders. Google and Microsoft are 2 examples of using mono repos. I think they are nice as you can use feature flags and continually ship the latest software. You don’t have to ask, is this code in that branch. You don’t have to continually merge code and wait for gated check in builds. You need a lot of automated test coverage for confidence.
    • Maybe you need multiple repos? It could be related to how you release things. Are they all released in a set with the same version or separately.
    • I don’t have the answer to this question, but I think that mono-repo is easier for the transition and you can break things out into different repos later if you desire.
  • How are we going to handle branching?
    • Is time to move to Trunk Based Development? (that would be my vote ;-)).
    • Checkout Microsoft’s guide I linked above for more ideas.
    • Coding Blocks had an excellent podcast conversation about the different branch workflows.
  • Where should we store binaries, dlls(use Nuget), exe and zip files so we can get them out of source control (that will be backed up)?
    • If you don’t you will have a huge .git folder. You can also consider Git LFS.
  • What builds and releases need to be updated?
    • Create copies, delete the old ones after the migration
    • How are you handling versioning of dlls and the release?
    • Does this affect the installer creation?
    • Can you switch to building artifacts and passing them along, instead of rebuilding the code in each step?
  • What branch policies are needed?
  • Who are the Git “gurus” or “champions” that will help others and do trainings?
    • This is essential. People are going to have issues as the learning curve is bit steep. There need to be people available to help untangle bit branch messes and walk through the process. Eventually more will become comfortable with Git.
  • Can you delete old branches?
    • not necessary for Git, but will make things a lot cleaner
  • Can you clean up your repo and make it smaller?
    • look for zip files, dlls and exes (use Nuget instead)
    • use Git TFS, git tfs quick-clone ..` the repository and use WinDirStat to find big files
    • I found almost 1 GB that can be deleted or moved out of the repo!

Azure DevOps

  • Is this a good time to migrate from on-premise Azure DevOps to hosted (or GitHub)?
  • Do you need to arrange your Az DevOps Teams to align and combine?
    • If different connected products are in different teams and repository, it’s harder to use the tools to align work and search code.

Create a Road Map

The team is excited (most of them, others are telling you to make sure you don’t interrupt their work) and you’ve done some training. They need to know when the change will happen. This will give them motivation to understand Git and practice.

Step 2 - Practice before migrating

You can use Git for your daily work before the migration using Git TFS. This tool creates a bridge between TFVC and Git. You can use this to practice and/or keep your git repo up-to-date until the migration happens.

Start this as soon as you can. I was unable to migrate history (the project was more than 5 years old with lots of branches), but I did have all the history since I started using Git TFS.)

install with choco install gittfs (or run the installer from Github)

git tfs list-remote-branches (find the branch you want to put into Git)

git tfs quick-clone ... (clone the branch without history)

use git checkout master git tfs pull to get latest and history gets built up

use git checkout {branch} and git rebase master as normal to update existing branches

use git tfs shelve xyz (-f to overwrite) to get your changes into TFVC (use the shelveset and check that in)

Practice the migration. Microsoft has a guide on how to do the migration. You can use the UI or git-tfs. Maybe you should try both.

Step 3 - Continue to communicate the plan and do training

Send out reminders that this migration is happening. Be prepared, please send us feedback!

Consider a weekly study on https://git-scm.com/book/ru/v2, a Teams/Slack channel, practice assignments.

Are the builds and releases ready to go?

Step 4 - Perform the migration

Are you using Git TFS or copy paste into your new git repo?

Check in, verify the builds and make sure you can release your code (release works, installers are created and work, etc).

Step 5 - Cleanup after the migration

  • Make TFVC repos readonly
  • Delete old builds
  • Notify the team

Step 6 - Evaluate and continue to make improvements on the process

Are developers happy about the change? Consider another survey to find out the new constraints and attack those to improve.

Enjoy life more as a software developer and a team (saving time and avoid frustrations)!

Continue to learn about ways to use git.

Consider changing your branching strategy to increase velocity and reduce complexity.

I hope this was helpful. If there are things you think I missed, I'd be very interested in hearing from you.


comments powered by Disqus

Please consider using Brave and adding me to your payment ledger. Then you won't have to see ads!

Support me and download Brave!

Use Brave