DevOps in Game Dev: The Beginning

This article is crossposted from the Future Proof Games blog.

This is the first post in a series that covers different areas in devops as applies to game development.

In early November, I attended and gave a brief talk at DevOpsDays Charlotte 2015, a conference dedicated to exploring ideas around the modern movement of operations informed by and possibly run with development practices. 

The typical, most obvious example of devops is the automation of builds and deployments of websites or software. Not moving files to servers via FTP and manually running a stack of database scripts (or worse, editing files on the server itself!), but having a system where you can push a button and roll out a new version… or roll back a broken version. 

The philosophy is broader, however. It's taking the same design approach to processes as one would to develop an app/game/website. That design approach includes things like:

To be clear, the "processes" I'm writing about are everything about how you:

Devops is most often discussed in the context of web development (and was at the conference). That's a subindustry with lots of money, time, and mid-sized groups of people who can put their heads together and innovate. With less desperation to survive than the indie game dev scene, they have more luxury to try stuff that might not work. 

As a web developer by day, I want to help bring some of these processes to game development, and the conference gave me a lot of ideas to improve upon what we're already doing. In my talk and in conversations with other people, I really pushed the idea of doing this on a shoestring budget. I bet lots of us indie devs are using shared hosting, for instance, which a web dev company would tend to scoff at. Some of us might not even be using Agile or sprints or kanban for managing our work. 

I've written indirectly on some this process refinement already in my post on getting indie dev services to talk to each other. I want to build on this and talk about the system of continuous improvement that we should be striving for.

I don't promise I can always propose free options if I discuss tools. Sometimes the free options just aren't the best. But what I will propose will generally be within our budget as a team with one game that didn't sell amazingly (Ossuary) and a game in alpha with nothing to buy in it yet (Exploit: Zero Day). 

Stay tuned for posts on philosphy, retroactives, automation, testing, emergencies, and more.