Yes, you read it right! When Microsoft was acquiring GitHub and many open source communities were moving from GitHub to GitLab, we were moving in the opposite direction! 🏊♂️
Before we explain how we did it, you may like to know why we did it.
Why Did We Move from GitLab to GitHub? 🤔
Last year, we had established an internal decision-making framework to streamline internal projects and improve focus areas among other things.
We questioned many of our internal activities and running self-hosted GitLab was one of them. It ticked following criteria:
- Don’t use two or more systems for the same purpose. Here, we were using GitHub to host our public work for a long time, whereas, GitLab was being used to host all our private work. We asked ourselves if we could host everything on GitLab and the answer was negative. Then, we wondered if it was possible for us to host our private work on GitHub and the answer was obviously positive.
- Don’t use a free alternative just because it’s free. We use WordPress because it’s not only free but it is much better in terms of the feature set. We then questioned ourselves if GitHub starts offering private repos for free, will we still use GitLab? The answer was a definite no.
- Don’t build things that nobody pays for. Like many web agencies, we are plagued with many internal projects that have accumulated high technical debt and requires considerable maintenance effort. I must say GitLab wasn’t a part of it, but we do have a bunch of scripts that were created to maintain our GitLab (example).
- Go SaaS for non-WordPress needs. We have a super smart system team which built a cool project called EasyEngine. However, EasyEngine is good at managing mostly WordPress sites. Therefore, we decided to use SaaS alternatives whenever we are not dealing with WordPress. This was done to reduce the maintenance burden on the system engineering team. Although, we must say maintaining GitLab involves the least amount of efforts and one should not leave GitLab for this reason alone.
Advantages of Using GitHub ✅
rtCamp is still small and agile! So any decision should have real benefits too. GitHub offered many advantages, some of which are listed below:
- Time-Saving: Having the same tool for public/project work, streamlines workflows & the entire process, which results in time-saving.
- Ecosystem: Many clients’ teams are already familiar with GitHub. So onboarding them on a GitHub project takes less effort compared to onboarding them on GitLab.
- Slack: GitHub’s slack integration is literally 1000 times better than GitLab. We love Slack so much that we will always prefer software which integrates better with it.
GitLab Still Good! 🧐
Yep. GitLab, specifically the self-hosted one, has some advantages that we will likely miss.
- Built-in CI: We had a pushback from devs as they were comfortable with GitLab CI. Luckily, GitHub Actions were launched. By all means, rtCamp has fallen in love with GitHub Actions and we will soon share plenty on the same subject. We just hope GitHub doesn’t charge a fortune for it.
- Backup: We trust GitLab’s backup in Amazon S3 cloud a lot more than that of GitHub’s. If tomorrow GitHub nukes our account along with their’s, we will be staring at more damage. Although it’s highly unlikely, from a pure probability perspective, the GitLab + S3 backups feel more secure. Please understand, the concern is not with GitHub losing hard drives or backups, it’s with GitHub killing a company’s account. A risk we run into with all SaaS vendors. It’s the same risk we have with Google Suite, Slack, etc! 😬
- Cost: Self-hosted GitLab has a low operating cost. The typical “price estimating tools” generally consider an exorbitant amount of human effort for self-hosted software. But managing GitLab never took more than an hour, a month. This included updating to a new major version and a few minor versions, every month. But the overall advantages would offset the cost difference, in the long run.
- Namespaces: GitLab has namespaces for our clients. We now prefix repo names with the clients. Also, some time ago, we moved to “one repo for one project” approach, greatly reducing the number of GitHub repos per client. Therefore, the impact of missing GitLab’s namespace is less.
There is a speculation that wordpress.org will move away from SVN/Trac to GitLab.
We would love to see that happen. Anything Git is more than welcome than anything SVN.
As we we are already dealing with an external system in the form of Trac/SVN, dealing with GitLab for our wordpress.org themes and plugins won’t be an issue. We believe that even if wordpress.org moves to GitLab, people will still host their stuff on GitHub, for GitHub’s ecosystem.
In any case, syncing between GitHub <> GitLab (or any git backed system) would be much easier. 🎉
Migration Script 🚚 🏆
The goal of the post isn’t to convince anyone to move from GitLab to GitHub, but in case you’d like to move, you may find our migration script helpful. It’s hosted on GitHub here! 😛
The migration script has a great deal of information to help you out. But please note that:
- We were using a free version of self-hosted GitLab CE: https://gitlab.com/gitlab-org/gitlab-ce/. We don’t know if the script works with the gitlab.com hosted version or with other variants of the self-hosted GitLab version.
- We are using the GitHub paid plan for private repo. You may need it unless your plan is to make all your GitLab private repos, public, on GitHub.
- We used GitHub’s new “work in progress” Bulk API for bulk issue import. It allows adding issues and issue-comments in a single API request. This saved many API calls as we moved around 300+ repos, 10000+ issues/PR and 100,000+ comments. Also, the Bulk API doesn’t send emails during migration.
- Our migration script created issues on behalf of GitHub users who have signed into GitLab using “GitHub login”. We had the option to sign in to our GitLab via GitHub & Google SSO. For users who have no GitHub token in GitLab, the issues were created by rtBot (our GitHub bot account).
As the migration script has served it’s purpose and we have no incentive to develop it further, we won’t be able to provide further support for it. Feel free to use it the way you like. 👋