In a switch that contains just a subtle hint of saltiness, GitLab has announced that it is to move its code repositories from Microsoft Azure to Google Cloud on Saturday, July 28, 2018. The news comes just weeks after Microsoft revealed it was to acquire GitHub (this happened in early June if you’ve lost track of time). While it’s tempting to see this as a retaliatory step, it is instead just a coincidence. The migration was planned before the Microsoft and GitHub news was even a rumor.
Why is GitLab moving to Google Cloud?
According to GitLab’s Andrew Newdigate, the migration to Google Cloud is being done in a bid to “improve performance and reliability.” In a post on the GitLab blog, Newdigate explains that one of the key drivers of the team’s decision is Kubernetes. “We believe Kubernetes is the future. It’s a technology that makes reliability at massive scale possible.” Kubernetes is a Google product, so it makes sense for GitLab to make the switch to Google’s cloud offering to align their toolchain.
Read next: The Microsoft-GitHub deal has set into motion an exodus of GitHub projects to GitLab
How GitLab’s migration will happen
A central part of the GitLab migration is Geo. Geo is a tool built by GitLab that makes cloning and reproducing repositories easier for developers working in different locations. Essentially, it creates ‘mirrors’ of GitLab instances. That’s useful for developers using GitLab, as it provides extra safety and security, but GitLab are using it themselves for the migration.
Newdigate writes that GitLab has been running a parallel site that is running on Google Cloud Platform as the migration unfolds. This contains an impressive “200TB of Git data and 2TB of relational data in PostgreSQL.”
Rehearsing the failover in production
Coordination and planning is everything when conducting such a substantial migration. That’s why GitLab’s Geo, Production, and Quality teams meet several times a week to rehearse the failover. This process has a number of steps, and each time, every step throws up new issues and problems. These are then documented and resolved by the relevant team.
Given confidence and reliability is essential to any version control system, building this into the migration process is a worthwhile activity.