Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
DevOps in Game Dev: The Philosophy
In the second post on devops in game development, be convinced as to the importance of spending time and effort in always improving your processes.
This article is crossposted from the Future Proof Games blog.
(This is part 2 of a series on applying devops principles and practices to game development. The main post is here and all posts thus far can be found on the FPG blog.) If nothing else about this series proves directly useful to you, take this one thing home:
Don't get stuck in a local maximum.
—Michael DeHaan, creator of Ansible
Keep moving and keep improving.
Very often, we find a system for ourselves that works and stick with it. We just get used to things that are initially annoying or rough, even if we know there might be a "fix" for it. As a result, we accept failure in some areas, telling ourselves "that's just how it is."
We shouldn't just accept those irritants and move on. We should continuously reassess whether those need to continue to be rough spots.
Here's an example: let's say we deploy an update to Exploit: Zero Day every week. We have the deployment process automated through a tool that also does our test builds. Essentially, we tag and push to a particular git branch, and the site deploys.
But a few times a month, the deployment fails because the build server runs out of memory. It's not that a big deal to log onto the server and restart the tool and/or the server, but:
There are other things running on the server that are important,
It interrupts the deployment, and
It can delay the process of building/deploying a site or game by 5-20 minutes.
Finding a solution, though, will cost time and possibly some money, and you don't have much of either.
It's fine, of course, to reboot that box once a week—or better yet, write a cron job to do it—but don't forget that you still have a problem on that server.
Whenever something about your workflow is annoying or slows you down, write it down. Have your team keep a shared list. Revisit it when you do your retrospectives and ask yourself and your team, "Is there anything we can do about this now? How much time and morale will we save if we put some time/money into this now?"
The answer this week (and the next) might be that there's nothing to be done or that it's not worth it. But two months down the line, there might be a new version of the build software with better memory management. Or in six months, you might have steadily increased your income and can afford to beef up that server a little.
In much the same way artists tend to develop an "eye" that shifts how they view the world, practicing this process of refinement can become intrinsic to how you work. Your situational awareness of your work processes and work environment will improve and you'll get more adroit at recognizing problems and being creative in finding solutions.
This won't happen, though, if you just accept all those annoyances. They stack up. They cost time and money. They make your job less pleasant. They lead to stress and burnout.
So in summary:
Keep a team list of process/environment annoyances
Periodically check for solutions
Revisit that list in retrospectives and decide if it's worth fixing now
If you aren't meeting to talk about process problems and solutions, stay tuned for the next post in the series, which will cover retrospectives.
Read more about:
Featured BlogsAbout the Author
You May Also Like