In the IT industry, the need for migration can raise several questions in your mind. Like what will be migrated and what measures should be taken to perform the particular migration. And the major concern is whether there are any chances of losing data. Losing even a tiny fraction of the data in transition can impact the performance of the application. So, in that scenario there are several measures that need to be kept in our mind while performing any sort of migration is taking a backup of the data, software configuration, and if any plugin is required for the software so that should also be checked. Apart from that migration should always take place when the least traffic comes on the application.
So, recently we got a requirement where we had to upgrade a self-managed Gitlab Community Edition(CE) from 11.11 to the latest version i.e., 15.4.
While upgrading Gitlab to any other version you might face many problems related to incompatible versions. So, for a successful upgrade, we’ll discuss the GitLab requirements for the upgradation and will also share the analyses that we found while following through this blog post.
As the requirement was to upgrade Gitlab to the recent version, you might wonder what’s the big deal in it!
But hold on!! It is not as easy as it is looking as you can’t upgrade a version from 11.11 to the latest released version directly with no downtime. So, after doing groundwork on it, we analyzed several strategies for achieving it.
The first way is upgrading it by accepting downtime which means we have to go through a major version upgrade though it is less complex, downtime is what we can’t afford.
The other way comes with zero downtime, upgrading to a newer major, minor, or patch version of GitLab without taking your GitLab instance down. It can be achieved if one minor release at a time is upgraded for example from 13.1 to 13.2, not to 13.3 and also releases can’t be skipped as database modifications may be run in the wrong sequence and will leave the database schema broken so, keeping all these points in mind database migration should also be taken care of.
And as this is a very tedious job with plenty of pros and cons for the same and also it will be a time-consuming task, this is not a cup of our tea, so we’ll have to go back to the drawing board.
We thought of drilling down into this further, and so we came up with the thought of only migrating repository, users, groups, and other meta info via API.
Migration of Gitlab resources. Did I hear it right?
YES, you heard it right!
Let’s suppose an organization is running a self-managed GitLab version of 11.11 and is having major resources that you can’t afford to lose such as users, repositories, groups, etc. So in that case we’ll be setting up a newer self-managed GitLab of version 15.4 and will be migrating all the GitLab resources from the older version to a newer one.
Sounds good right !!!
But now you might be thinking how is it possible? Does gitlab provide any functionality like this? Or anything else. So, calm down, it’s a long journey and just a click of a task but we’ll look into this in the next blog.
CONCLUSION
In this blog we have covered the different strategies of GitLab migration on the basis of requirements and now will see you in the next blog with how will we be achieving it.
Please let us know in the comment section if you have any other suggestions or strategies about the approach. Thanks for reading.
À bientôt!!
Blog Pundits: Deepak Gupta and Sandeep Rawat
Opstree is an End to End DevOps solution provider.
Connect with Us
Thank you for sharing
Nice write up. I’m really interested to see parts 2-?? When can we expect them?