Intent Media is now Intent
We use cookies, which include essential cookies and cookies to analyze our traffic. For more information please visit our privacy policy
  • Posted by Intent Media 27 May

DevOps Principles Series: No-Brainer Deployments

At CITCON North America in Austin last year, I conducted a session to show the approach Intent Media uses for doing TDDevops (my name for ATDD combined with DevOps). The room filled, leaving only standing room for latecomers.

Via the CITCON mailing list, Andrew Parker asked me to elaborate on how we determined our “DevOps ground rules” at Intent Media. I was compelled to write about the approach we used.

In this blog post, I want to drill into a key aspect of that approach.

Deployment Should Be a No-Brainer/Almost Zero Risk

Software entropy impacts deployment processes like any other software. We must apply constant vigilance to ensure that they do not become something that only one person understands. Our industry calls that risk the “bus factor”. I get nervous when only one person knows how to deploy an application. We have a critical problem when one person’s luck, happenstance, illness, or disappearance, can bring things to a halt.

We engineers that adhere to a DevOps philosophy (I call us DevOps philosophers) must ensure that deployments have the following properties:

  • Accessible
  • Discoverable
  • Understandable
  • Usable

That usually means planning for the following activities:

  • Automation
  • Promotion
  • Continuous Execution
  • Education


Many DevOps philosophers focus their efforts on automation.

I love tools that make automating our domain easy. When Chef and Puppet came onto the scene, I was excited! I thought, “Finally someone built a reusable tool for this stuff!” I usually say that: “I love both Chef and Puppet.” My friend and colleague Jez Humble joined the Chef crew last year. Andy, my friend I mentioned earlier, worked for Puppet Labs. I know that both Jez and Andy take their continuous delivery practices very seriously.

At Intent Media, people with DevOps expertise partner with development teams. They use their skills to help teams choose the best approach.

Beyond Chef and Puppet, we can choose from a broad range of tools. I am happy to report that we now see teams working with Ansible and Docker. Some teams use a legacy of Bash scripts that read just like the commands someone might execute. Again, I love all the tools. I am done with tool wars. I have moved on to the value war. We use tools that provide value. It is that simple.

Getting the process codified, as an automated “script”, reduces risk. Remember that until this critical step has been taken, the bus factor puts your team, your application, and your company at great risk.


I don’t mean advertising! Promotion, in this context, means two things:

  • Using the same deployment automation in every environment
  • Treating the deployment automation with respect

I find many companies using different, complicated deployment strategies. Those companies might automate each stage, but each one is unique, like a snowflake. Automated snowflakes are progress, but definitely not perfection.

Instead, one automated deployment “script” should describe the deployment process, across all environments. It should live right alongside the application code.

This practice isn’t new. For example, keeping our build description (build.xml, pom.xml, build.gradle) became commonplace as far back as Make. Our deployment automation scripting deserves the same level of respect.

No-Brainer Deployments are ensured by executing the same deployment script throughout the flow to production. In this manner, our automation proves itself over and over again, much like automated testing does. A good team uses this practice for all deployments. It helps ensure that hidden dependencies do not creep in. Promoting also ensures that anyone, even an automated system, can deploy the application, reducing the risk associated with every stage in the deployment pipeline.

Continuous Execution

Any changes to the deployment automation require immediate testing. We call that continuous integration (CI) – a practice that I was happy to popularize while working at ThoughtWorks and beyond! I will paraphrase the CI mantra here: “As soon as any change occurs, I want quick feedback about whether I broke anything.”

For the DevOps philosopher, we already live the CI mantra. We need to apply the same thinking to our deployments. To make it explicit:

Deploying an application is as important as the features delivered by that application. The deployment automation should be as robust as the application it’s deploying.

If we cannot deploy, then our features are useless. In fact, I like to begin new applications with a Hello World fully automated deployment. Note the word, “fully”. From day one, deployment should receive the same respect as any other change. Continuously executing the deployment reduces the risk associated with every change to the deployment process. Just like continuously testing changes made to the application reduce the risk associated with each change.


DevOps philosophers must make education a priority. Teams must be taught why automation, promotion, and continuous execution are important. I no more expect an application team member to know what to do with a Dockerfile, than I do with any other new file type.

That means part of our rollout strategy must include teaching. I use pair programming as my primary teaching mechanism. Classes with groups of engineers work well, but I suggest keeping student to teacher ratio low. With only a small number of students, we teachers are able to impart our ideas. When we take on too many students at once, our ideas can get mired in tactical problem solving. I suggest no more than six students to one teacher.

Documentation can help, though it may be a red flag. I prefer automation that adheres to the intuitively obvious concept. That ideal fits into the category of “self-documenting code“.

When we create truly No-Brainer Deployments, external documentation can be generated, similar to generating API documentation. A good metric to gauge our success is, “How many people on the team know how to deploy the application?” The closer to “all of them,” the better. Again, this hearkens back to reducing risk.

Wrapping Up

Through a combination of automation, promotion, continuous execution, and education, we DevOps philosophers are able to empower our organizations. We free our companies in interesting ways.

In a world where anyone in the organization knows how to deploy, our teams have true freedom.

  • Freedom from a key risk, known as the bus factor
  • Freedom from fear of innovation
  • Freedom from scheduling deployments around people
  • Freedom from having to schedule deployments at all
  • Freedom to allow our changes to flow freely to our customers
  • Freedom to rapidly iterate
  • Freedom to wow our customers, over and over again

I think of the No-Brainer Deployments principle as part of the grease that keeps everything moving with ease. Traditional deployment approaches keep our companies stuck. No-Brainer deployments make teams more productive, happier, and more innovative. As an engineering leader, that matters to me a lot!

Next Time

I will dive into the practice, “One Click Everything”. This practice makes No-Brainer Deployments achievable and improves how we interact with our internal customers!


Paul Julius, “PJ”, is the acting Chief Technology Officer at Intent Media, where he is helping build a world-class software delivery team. Prior to becoming a fulltime employee in May, he spent over a year consulting with Intent Media as Head of Technical Operations, promoting DevOps principles throughout the company. When he’s not leading the software teams, pairing with marketing, diving in with product managers, or helping the company make effective use of technologies, he can be found gardening and beekeeping at his home in South Dakota or planning his next trip to CITCON.

Post Comments 0