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.

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.

(This is part 3 of a series on applying devops principles and practices to game development. The main post is here and all posts can be found under this tag.)

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?

(This is part 2 of a series on applying devops principles and practices to game development. The main post is here and all posts can be found under this tag.)

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 ...