Part of our work to make Exploit: Zero Day easier for us to maintain and update was making a job editor for ourselves. Previously, we'd been creating jobs (the storyline missions for the player) using the Django admin interface, which is very nice but makes it difficult to have ...
Tag archives: devops
We talk about:
This month, we talk about the ongoing Exploit: Zero Day job editor development, the dropped "The Majesty of Colors" trademark application, our infrastructural/devops change away from Compass, and the upcoming Rosette Diceless one-shot session on September 30.
This is the fifth part in a series on applying devops principles and practices to game development. You can read the first post in the series, and see the entire series under the devops in game dev tag.
In our post on what the devops philosophy is, we wrote about revisiting workflow annoyances periodically. Sometimes you get more time and/or money. Sometimes you learn of an easy way to solve a problem.
There's something that got a lot easier for us recently: chatops.
"Chatops" is a trendy word for a subset of devops that focuses on streamlining work using extensible chatbots (e.g., Lita, Hubot, and Errbot) in team communication tools (e.g., Slack, HipChat, etc.). We use Lita on Slack, so I'll stick with those as concrete examples.
As a simple-but-nice examples, you might ask Lita to run an automated build for you, and it will connect to Jenkins and run the build you ask for. You don't need to leave Slack open a tab, log into Jenkins, find the job you need, and run it.
Something really important that well-implemented chatops provides is the ability to add context-appropriate information to conversations that are already happening....
We have about 12 different sites or parts of sites that could have outages and two of us to manage them. Some of these have been up for years, and some are newer. Some applications require special installation or debugging, and some must be on differently-configured servers.
When one of those goes down, we both need to know how to diagnose and fix it as soon as possible. So how do we manage that?...
This is the fourth part in a series on applying devops principles and practices to game development. The first post in the series is here, and the entire series can be found under the devops in game dev tag.
In our post on retrospectives, we wrote about taking note of lessons learned (good and bad) after emergencies or breakpoints in your project—after you deliver a feature, or at the end of a sprint or some unit of time. But how do you know what a good breakpoint is? How do you actually incorporate what you've learned in a retrospective into your future work?
Through effective project planning....
In our post on devops philosophies, we emphasized the continuous process of learning and revising, and said that a good place for that to happen is in retrospective (or post-mortem) meetings.
So what is a retrospective?...
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....
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 ...