Overtime New Zealand is a social video game league for corporates. Companies get together and play games against each other for bragging rights, e-peen and other critically important reasons, like proving that you’re better at Dota 2 then X_MAIN_RIVAL_FIRM.
So without Further ado, here’s what we’re running at the moment.
I’ll go through our components technology by technology:
Most importantly, Docker
We couldn’t do what we wanted to do with Overtime’s CI / CD without docker. Initially I created docker-compose containers for instances of Docker Registry, Nginx, and MongoDB and our Web App. The plan was to containerise those components because it would allow us to scale up instances of our web app and MongoDB in case our load got crazy high. An ambitious design requirement, but much better for the long run. In fact nearly every design decision we’ve made technologically has been focused on “What will make our lives easier in the long term”. We do this voluntarily so making money immediately and as quickly as possible isn’t such a huge issue for us! It’s nice.
We had a bunch of technical issues with Nginx not liking being containerised and not linking to our other containers properly. That resulted in us shifting it to the VPS itself and using it for reverse proxy and routing, it’s working pretty nicely so far.
We run separate production and test environments. Local builds are automatically built and dockerised on commit, are automatically deployed to our test environment with 0 loss of service. When we’re ready to go to prod, we just retag the docker image in question as prod rather than test. Docker picks up that there is a new image available and redeploys in the same way as our test environment, meaning we also get 0 down time. We still plan our deployment windows for early in the morning just in case something breaks but the process seems pretty solid so far.
Our Web App
Overtime uses a Java 8 back end with an Angular front end. Once the application is complete, players will be able to register themselves and their teams, sign up for tournaments, track points, rankings tables identities, and communicate with organisers and other teams. We have a dedicated slack team for overtime and we’re planning on our players being automatically enrolled into slack on sign up. I also want the enrollment process to add them in to relevant channels (they might get a private team channel and enrollment into open game and interest channels) - but we’re still thinking about how that would work!
We’re using MongoDB because we really like it’s object paradigm, it’ll make it easier for us to manage our data long term.
Speaking of building:
We use Bamboo for our CI/CD work, initially we used Jenkins but found it unreliable, prone to random failures and difficult to set up, maintain and extend. Bamboo is a much more user friendly solution. We had set up our build server as an additional docker container on the first VPS but thinking about it, we wanted to ensure that development work could never impact production environments. Because of the size of our VPS it was possible that our build container could cause production issues by hogging up resources while building things. An edge case but with the focus on the long term we decided on separating that out on to it’s own VPS with its own resources.
Project Management
We use Taiga.io for project management. It has the option for sprint or kanban set ups, it’s a hosted solution and it’s free, which fits our budget! Taiga is also open source which means that we can take it, self-host and extend it should we ever need to provided we comply with the licence, which is another bonus.
Wrap Up
That’s all the detail I’ll go in to for now. I hope this helped you, if you want any more detail or you’d like help with your own projects, let me know, I’d love to see how I can help!