DevOpsGroup has joined Sourced, an Amdocs company. Read more about this partnership and what this means for the future in our blog.

DevOpsGroup Blog Repository Migration – Leave the kitchen sink!

Repository Migration – Leave the kitchen sink!

Part 3

Written by Technical Consultant Stewart Osborne Linux Automation specialist, RedHat Certified Engineer and DevOps Practitioner.

Migrating your existing version control repositories to Git repositories can be as simple or as complex as you make it. Depending on your existing VC software, there are many different migration tools and scripts out there which allow you to fully convert your existing repositories to Git, including the full audit history of those repositories, with additional options for migrating feature branches, etc.

Start by getting consensus on exactly how much of your existing repositories are required by discussing the subject in your Git Migration meetings. Do you really need the history of the entire repository, or will the last 3 months of history suffice?

You shouldn’t plan on decommissioning your existing VC repositories immediately after a migration to Git. Switching the old repositories to “read-only” will ensure that any history or branches that have not been migrated are still available to the organisation should they be needed. With this in mind, try to take an “MVP” approach to the migration and ensure you only migrate what you actually need.

Don’t assume you need everything that is currently residing in your repositories. If your repositories are only 6 months old, that might be the case. Otherwise, there will almost certainly be things in there either aren’t needed or have no business being in a VC repo in the first place. Do you have binary files in your repos?? …I know you shouldn’t, but have you looked recently?

If you are using a migration tool such as “git svn” for example, nothing will cause you more pain than having the odd .PDF or .MP4 file in there for the migration script to trip over.

Do some housekeeping before using such tools and make sure that you are migrating repositories containing only flat files.

On the other hand, you may determine that you have no need to migrate any of your history, as long as it is still available somewhere for reference. If that is the case, simply clone the “head” of your existing repositories, initialise Git in the directory and push the newly created Git repository to your new git server or service.

Regardless of how much of your repositories are being migrated, it is worth doing a trial run of the migration to Git as soon as you are prepared to do so. Not only will this highlight any problems with the migration process as early as possible, but a successful trial migration of your repositories to Git will allow for your engineers to test any new build or deployment processes that have been changed. This will allow for sanity testing of engineering efforts and enable the testing of new build & deployment processes before your old repositories are switched to read-only.

In our final blog post from Stewart, he takes a look at Big Bang or Iterative Migration? Coming soon!

Part 1: The Big Git Switch – Migrating to Git to increase your flow

Part 2: Training – Git Good!

Leave a Reply

Your email address will not be published.