This blog is the final part of a series.
To ensure a successful migration, you need to follow these key steps:
- Choose the repository strategy.
- Choose the branching strategy.
- Integrate git in your CI/CD pipeline.
- Train your newbies.
- Migrate your code.
- Delete the TFVC repositories.
- Stay informed of TFS releases that close the feature gap with other git servers.
Our Own Migration Journey
Once the department’s key players were convinced migration to git was a must, we had to get it done. The following steps were taken in order to successfully migrate our code base.
First things, first. Training has proven to be important, especially when talking git. Two one-hour opt-in sessions took place (basic and advanced) so people with weaker l background could attend and people with stronger backgrounds could be identified as mentors to newbies.
Migration note: Hands-on sessions with real-life situations are key here. Theory has to be kept to a minimum. People interested in git plumbing will google it for themselves. Others will rely on training to solve everyday problems. Remember to train your members as close to the migration date as possible.
We decided to use pull requests for code reviews, since this has been included in TFS. We could have used something like gerrit, but past experience some developers have had with collaboration and continuous integration told us this solution wouldn’t work.
We protect the master branch with pull requests, mandating the work item to be linked, a reviewer to accept the changes and whenever possible, a build to be successful. This created an interesting situation in which our pipelining was implemented using Jenkins. The Jenkins hook in TFS wasn’t suitable for our needs. Therefore, we had to configure a TFS build. Its only purpose was to trigger a Jenkins pipeline and wait for the result. The result is then translated into a TFS build result. This has the advantage of forcing a pull request to succeed a given pipeline before merging it into the master branch. This gives us confidence that a production-ready master branch is available at all times.
Whenever possible, we tried to migrate the history along from TFS to git. For this purpose, we used git-tfs. However, there were some occasions when commits were too large for the HTTP transport to push on the remote. Note here we were forced to use HTTP since TFS did not support SSH (Secure Socket Shell) at the time. Therefore, while the local repository was fine, we were stuck with not being able to push it. We had to decide not to bring the history with the code for the first few repositories. However, we discovered the Visual Studio git client applies some tricks, so we were able to push all commits.. The final recipe was to use git-tfs to create the local repository and then Visual Studio to push it to TFS. The steps are:
- Create the repository on TFS
- Protect at least the master with pull requests
- Migrate the code with git-tfs
- Push the local repository using Visual Studio’s git client
Finally, there were decisions made to create distinct repositories per application or component.
Finally, the department needs the courage to say farewell to TFVC. The longer the department lives in a limbo state between TFVC and git, the more disgruntled the members will be. Past experience shows us that the CI/CD pipelining prevents us from turning on the kill switch Therefore, the pipeline has to be git-ready prior to migrating the code. Once the code is migrated, the associated pipeline is adapted quickly and downtime is reduced to a minimum.