As part of its plan to improve the performance and reliability of GitLab, the company has announced it is migrating the site from Microsoft Azure to Google Cloud Platform.
According to the company, it wanted to move to GCP so that it could run GitLab on Kubernetes.
Earlier this year, GitLab shipped native integration with Google Kubernetes Engine (GKE), which has the most robust and mature Kubernetes support available. Moving to GCP was the next step in the plan.
Though this plan has been in the works for months, this announcement comes shortly after Microsoft announced its acquisition of GitHub. In a statement given to SD Times reacting to the acquisition, Sid Sijbranij, CEO of GitLab, said, “Microsoft likely acquired GitHub so it could more closely integrate it with Microsoft Visual Studio Team Services (VSTS) and ultimately help drive compute usage for Azure.”
Once the GitLab migration to GCP is complete, the company will continue to work on improving stability and scalability of GitLab.com and will move its worker fleet to Kubernetes using GKE.
GitLab has been using Geo to plan for the migration, which allows for full, read-only mirrors of GitLab instances and can be used for a planned failover to migrate GitLab instances.
The company has been maintaining a Geo secondary site of GitLab.com that is running on GCP. According to GitLab, this secondary site keeps an up-to-date synchronized copy of roughly 200TB of Git data and 2TB of relational data in PostgreSQL. The company was initially concerned about latency due to the large amount of data needed to transfer, but after initial testing it determined that latency and bandwidth would not be bottlenecks in the transfer.
In addition to the Geo transfer, GitLab has also migrated all file artifacts such as CI Artifacts, Traces, file attachments, LFS objects, and other file uploads to Google Cloud Storage.
The company is working to ensure smooth failover from Azure to GCP by rehearsing it in a staging environment one to two times per week. The failover currently takes two hours and involves four steps: a preflight checklist, the main failover procedure, the test plan to verify that everything is working, and the failback procedure which is used to undo the changes to prepare the staging environment for the next failover rehearsal.
The failover is currently scheduled for July 28, but GitLab has stated that it will only conduct the move once it is completely satisfied that all serious issues have been addressed, that there is no risk of data loss, and that the new environment on GCP is ready for production workloads.
