Over the weekend, I spent time getting my GitLab account, working with a single repository, and migrating the CI script from GitHub to GitLab.

The biggest issue was the CI script, and why shouldn’t it be? There’s rarely a “one script fits all” regarding CI scripts. When I started this project, I had issues getting the CI script working in GitHub. After a few pushes on the one branch, I eventually got there. Migrating this script to GitLab’s CI ways was more straightforward than I thought, but I still had a few issues I managed to resolve.

In addition to all the usual source code management goodies that GitLab offers, a few stood out.

Private repositories are available on GitLab’s free tier. Having used GitLab in the past, I already knew this, but it’s refreshing to see that GitLab is sticking with offering this feature on a free tier.

Feature flags are available on GitLab’s free tier. They are a means of configuring how your code behaves by using toggles and checks to ensure that it only carries out certain functionality. I have a number of feature flags in my application, but they are all based on a YML file in the source code. I will be migrating these to GitLab, though, so that I can toggle them without having to deploy any changes to the YML file that controls them.

Error tracking is available on GitLab’s free tier. Previously, I used Sentry for this, but GitLab also uses Sentry under the hood for their own error tracking feature. Yes, I can probably get more information by having a dedicated Sentry account, but at the moment, I am just checking to see if users raise any errors in the application.

For developers building on the side, these features on GitLab’s free tier are of great value and definitely swing my vote from GitHub to GitLab. Over the next few weeks, I hope to migrate the feature flags over, use more of GitLab’s platform, and see what it can help me with.