Here at [BB] we’ve gone through a few iterations of version control with each generally improving and iterating better upon the last scenario. This isn’t a common thing we do and generally seems to reflect the state of how much time we have vs our needs.
A quick trip down memory lane
Back in the very early days of BB (we’re talking RP08 and before) version control was essentially copy paste files, and if there was a cockup the only (known) good version was probably on the server so that’s where you’d go to fetch it from. This is very bad for a number of reasons however we won’t dwell on those. It’s in the past!
Those that played GMod from 2007 until about 2013 and using addons such as Wiremod might remember having to install tortoiseSVN, a subversion (SVN) client. At some point (roughly 2009) BB moved on to this for the single gamemode at the time we had – RP09. Setting up repos (self-hosted) was painful with SVN and there weren’t any “easy” public solutions available without paying for them. Sure Googlecode existed but that mandated your source was always publically available which we didn’t (and still don’t) want.
SVN also proved to be painful with multiple people working on it if you didn’t strive to keep up to date with each and every commit. Hell, forget about branches – those don’t even exist (or at least, didn’t at the time)!
At some point in 2008 – 2010, GitHub and Git started making stronger waves. While Git had been around since around ~2005 it hadn’t really picked up popularity until services using it became a thing. Leapfrogging Mercurial (another version control system) it absolutely stormed the development world and today it’s seen as the gold standard.
Only the problem for us was the original problem we had with SVN – places at the time such as GitHub still mandated your code was public and it wouldn’t be until later they supported private repositories; though only for those willing to pay. Services like Bitbucket and GitLab were still coming to fruition with their usage models and at BB we were getting pretty fed up with SVN.
If someone else won’t do it, do it yourself
So I ended up looking for self-hosted solutions and at the time settled on Gitolite. On the 4th of October, 2012 I installed Gitolite and at 21:27 made our first push. With immediate success we pretty much stopped using SVN for our mainline projects and everything became Git based. Any projects we weren’t actively developing remained on SVN until we shut down Montreal.
We ended up going through a few revisions of Gitolite to gain access to a few features (mainly how authentication and different pub / private keys worked) and it served us well up until the point we stopped using it.
But why stop using Gitolite?
Microsoft suddenly acquires GitHub for big dosh
Something Gitolite did very well was act as a version control system but the peripheral stuff such as builds (for executables / docker containers), documentation and bug tracking had become somewhat more cumbersome. Building a docker container required me to boot up a virtual machine on my PC (as I was using VMware) and setting up shared drives and so on which weren’t without their own issues. We used forums for bug tracking & documentation and while we had branching strategies for multiple lanes of work within Gitolite it wasn’t as streamlined as it could be. It also meant visibility to anyone outside of development (i.e. anyone that wasn’t Killermon or myself) had no idea what was coming up unless we actively brought it up.
I had started looking around somewhat lightly for decent integrations or a better overall solution; this wasn’t a case of we were flexing at the seams but why should work we’ve already done once continue to require a human actively involved?
And then Microsoft acquires GitHub.
And then private repositories become free.
Oh and GitHub actions (build systems) were stable and a thing.
The first one, not great as Microsoft do have a habit of squeezing the market. By proxy of the acquisition however it meant that Microsoft were willing to make sweeping changes that (for now) benefit the consumer and so the plan came to be we’d host everything under my account over at GitHub.
However it turns out even with a pro (paid for account) there were things that didn’t play too nicely on a solo account because at the end of the day a Pro account is meant for more personal projects that can accept contributions as opposed to a greater project that spans many elements. And then Microsoft went and made it so a user in a team cost $4, the same as an individual Pro license. Teams solves many of our problems and thus BB-Games was formed.
It isn’t perfect. The tradeoff however for the feature sets we get make it more than worthwhile. There’s two sticking points I have, namely:
- If you want to make deployments “easy”, you need an extra “seat” for the server that that’s going to be part of that deployment process. You can work around this in a number of ways but none of these things are ideal. $4 is $4 and I have a decent-enough paying job so for the time being I’ll absorb that cost.
- Non-development users require a seat as well. It doesn’t matter if they’re an “outside collaborator” or someone who literally just needs access to the boards / issues / wiki feature. To gain access to a private repo they need a seat. There’s a middle-ground in that you can have a public repository that’s “issues-only” but that doesn’t really cover details you might want to keep sensitive. A workaround at least is to use webhooks to “stream” out updates so at least they can see context and snippets of what’s going on.
For what it’s worth in terms of disclosure purposes, the “free” version of Teams has private repos as well and that would serve us just fine but they lock away a number of features that are insanely useful and so that $4 per user is worthwhile.
So what was multiple systems working in loose tandem (and requiring regular maintenance) has been merrily offloaded on to a cloud platform where I pay ~$12 a month (not counting my own personal pro account) for an insane amount of goodies.
We’ve been with GitHub since April this year and we haven’t had any desire to move back; if anything we’ve actually integrated with it even more tightly (as per the last blog post). Here’s hoping Microsoft don’t go screw it up.