Moving To Gitlab
Microsoft dropped a bit of news earlier this past week, when they announced their $7.5B acquisition of GitHub. It’s been fascinating to watch the company whose CEO once called open-source a cancer embrace Linux and open-source more generally. Between LinkedIn and GitHub, they’ve bought access to an entire generation of programmers who never would’ve even glanced at Visual Studio or .Net. Those old enough to remember 90’s era open source will no doubt recall that “embrace” is but merely step one of a more complete strategy, so a little skepticism can be forgiven. There was enough skepticism among developers to precipitate a flood of migrations from GitHub to alternative services such as GitLab, prompting the Twitter hashtag #movingtogitlab. Having already made the move myself in both professional and hobbyist capacities, I say: Welcome!
On the professional front, we had an opportunity to migrate the dev team at my work earlier this year. We had previously used Manuscript, formerly “DevHub”, formerly “FogBugz” / Kiln for our git management and issue tracker. It had become increasingly clear their direction (or lack thereof, in regards to Kiln) was a poor match for our team’s needs. When months, and then years passed by without any updates to Kiln, even the FogCreek diehards on the team admitted it was time to look elsewhere.
I can’t recall how or when GitLab first got onto my radar, but while bemoaning the state of Kiln I would every so often check in to see how the product was growing. What at first seemed like a GitHub knock-off had grown into something quite different. Their aim is to be a complete DevOps solution: Issue tracking, git management, and continuous integration all in one. At the same time, the API is robust enough to enable integration with other tools, should you prefer an alternative for any of one of those. “Merge Requests” enable GitLab Flow, something I’ve been able to easily enforce in our team’s repository. Coming from a git management solution whose UI primarily focused on Mercurial (and thus “branch repositories” rather than proper branching), this was a revelation.
The single greatest source of joy in this transition has been replacing a clunky Jenkins setup with GitLab’s CI. While Jenkins is a fantastic project, we never had the staff resources or time to really make something of it. With a team as small as ours, you need to find force multipliers that let one dev do the work of a hundred. I’m a Software Developer / Architect, build systems are something I struggle to get right. GitLab CI not only let me easily parallelize the build, and spread it across a modest build server farm, it integrated the control and monitoring back into the UI the developers were using to integrate + review code!
On the hobbyist side of things, as of today I have moved my blog to GitLab Pages. Much like GitHub Pages, they offer free hosting and https. Free private repositories let me hide the Markdown source / Hugo infrastructure behind the website, and the CI system automates deployment of the site on every git push. Just last week Apple announced Xcode 10 integration at WWDC, which makes the choice of where to store hobby projects an easy one.
I wish Microsoft and GitHub the best moving forward. I believe Microsoft has been making the right moves to earn developers trust, despite their history. As for myself, I’ll be stashing my code on GitLab.