Written by Technical Consultant Stewart Osborne Linux Automation specialist, RedHat Certified Engineer and DevOps Practitioner.
When you are considering the actual process of migrating your build and deployment processes over to Git, you need to decide whether this will be a gradual effort spanning several weeks (or even months) or whether it would be easier to adopt a “Big Bang” approach and complete the switch-over in a much shorter time-box.
This can be something of a contentious issue for some, so I will attempt to show my reasoning behind each approach.
Here at DevOpsGuys, we consider ourselves a highly agile organisation, and we therefore generally prefer an iterative approach to such changes when possible. But I concede that this is not always practical when migrating your version control tools.
The right choice for your organisation will depend on the level of modularisation of your code base and your associated build and deployment processes.
If you have a very monolithic application to build and deploy, the additional effort of breaking apart your monolith to allow parts of it to be migrated to Git independently will likely require considerable engineering effort. See “Slay the Monolith” for more on this.
If you’re not careful, taking this approach will lead to your migration effort being hampered by the dreaded Scope Creep.
If you are considering an iterative approach to migrating your CI/CD processes to Git, firstly ensure that your application and processes are sufficiently modularised as to allow for areas of the process to be migrated without affecting the rest of the pipeline. If you believe that this modularisation can be achieved as a part of the migration, make sure you have a clear understanding of the work required before you begin. Do not underestimate the effort to modularise a monolithic application!
Using this iterative approach to migrate to Git means that the migration effort can be spread out over a longer time span, reducing pressure on delivery teams and minimising the impact of the migration effort on software delivery. However, there is additional overhead in coordinating this longer migration effort.
The alternative is to plan a “Big Bang” switch-over – To migrate all users and systems over to Git at the same time. This needn’t be as scary (or insane) as it sounds, providing you’ve done the preparation and testing beforehand and the migration work is well coordinated.
As a pre-requisite to this migration, ensure that all of the engineering work has been completed and tested in parallel to your existing VC tool.
This includes all relevant build & deployment scripts, automated processes and VC integrations (Jenkins, Maven, etc). Whilst it will not always be possible to perform full end-to-end tests of these processes in isolation of each other, individual segments which relate to Git functions should be thoroughly tested before the Big Bang.
Something else to bear in mind with the Big Bang approach: You need to allow for a transition period during which productivity will substantially decrease.
In most cases, a Big Bang migration can be completed in a week. That is the time from the old VC tool being switched to read-only, to the time that the entire software delivery pipeline is fully operational again. During that week, it is likely that additional engineering work will be required to correct for teething issues. Users who are new to Git will take time to adjust to the new tools. Make sure that there is understanding from the business that productivity will dip during this time. Release cycles may need to be adjusted or delayed to allow for the migration, so make sure this is planned for!
Regardless of which approach you decide on, always ensure that every step of the migration has a roll-back plan to your existing VC tool that can be implemented as quickly and painlessly as possible should the need arise. The last thing you want to do is leave your product delivery teams with a bad taste in their mouths because a problem with the migration is causing missed deployment windows!
If planned correctly, your entire organisation should be able to roll back to your original tooling (users & systems) with minimal time and effort. Leaving your old repositories available in read-only mode for 3-6 months after the migration to Git should provide an adequate safety net for even the most risk-averse of organisations.
If you’re still reading this, I hope it’s because you’ve found the content useful and that it’s given you plenty to think about when planning your own migration to Git.
If there’s one thing you take away from this blog post, let it be this:
If you have identified your Version Control solution as a constraint of your software delivery velocity, all is not lost. It can be changed without causing chaos and riots, and the resulting boost of productivity is well worth the effort.