Designing deployment methods for a growing startup tech team
eLeague.gg is rapidly growing behind the scenes, and this is especially true in regards to the tech development team behind the scenes.
Our current development team consists entirely of one person (yours truly) and my duties involve:
- Coding behind all the site’s actions (more on this later)
- Designing everything visitors see on the site
- Writing all the content on the site
- Designing the structure of the site, processes and user flow
Not to mention all the maintenance involved…! So the obvious solution, is to bring on board more people! The exceptionally talented1 :
- PSmith a long time LAN party regular at my events and volunteer admin both at my events, and at PAX Australia
- SirSquidness the well known server/network/LAN guy from Respawn LAN, Melbourne (also same for PAX Aus PC Area)
So…. What’s the problem? #
Well, since I started out running LAN parties, and doing gaming events - all my sites have always been bespoke, from the ground up creations. All involving myself as the sole designer, and sole developer. I’ve never had to answer to anyone and in fact, never had to consider that someone else might come in and develop on my sites/projects. Again, this is certainly horrible practice and not something any developer should really do.
And so again, as eLeague.gg started up - guess what I did? Haha…
And now? What is the solution? #
Git branches. I already develop everything and store it through a personal Git repository system (I use Phabricator for my Git repo management needs).
As it currently stands, I keep:
- A branch called staging: this is for testing, development and experimental content creation.
- A branch called production: this is for everything that is on the live eLeague.gg website.
While this stops me from accidentally implementing broken features (sort of) it’s still not ideal for three developers working all at once on eLeague.gg’s core code. So we’ve developed a way to organise ourselves in such a way that each developer is independent, but bases their code off a singular source of truth.
This looks like (click to enlarge):
What’s more important is the flow of code as signified by the arrowheads in the diagram above. Developers should in theory, only ever be pulling and pushing features in both directions from the Dev(elopment) Branch. And all features should be internally vetted within the Tech Team before being pushed to the Pre(flight) Branch, and then onto the Production Branch if all goes well with the rest of the team.
Some caveats:
- No more than a single developer should be working on a single feature at a time. If multiple developers are needed, then one dev needs to stop working on said feature, before another dev takes over.
- There is a degree of potential data and code entropy over time between all three branches - dev, pre and produciton. As such, only JT (me) will have access to being able to merge ‘backwards’ from Production > Pre > Dev.
- Setting up for three developers simultaneously also means we now have a bigger delay in rolling out features as everything needs to now be spec’d, documented and planned out.
I suppose it’s a great little situation to be in that I can start working on eLeague.gg in earnest with a team, and now I should hopefully be able to focus more on not just the technical development of eLeague.gg, but the rest of it too!
1: This list of people does not use names they uses their drivers’ licenses. Our team has many people with the same given names so to help differentiate, we refer to each other by our gamer nicknames.