We’ve heard a lot about the Obama campaign’s use of data and technology, particularly demographic data and the cloud. But in terms of DevOps and release management best practices, the campaign’s path was not an unusual one. When trying to get DevOps right, you have to solve the same problems over and over again, and if you don’t solve the biggest one – educating the owner on the iterative nature of DevOps – you’ve got a problem. In the SD News article, “DevOps were the difference on the campaign trail,” Alex Handy describes the Obama team’s experience. When pushing out software releases, the tech team collapsed the boundary between engineering and operations. However, there was a learning curve. The non-technical staffers on the campaign were from the political arena, but none of the technical staff were. The campaigners were used to working in a burst every four years, and their approach was resistant to change. Iterative deployment was highly foreign to them. The campaigners expected to throw specs over the fence, get a product in three months, and yell at a vendor for getting it wrong. That’s not how Obama for America’s tech team worked. Instead there were wireframes and daily interactions between engineers, operations and the field team. This resulted in numerous clashes during the first summer of the campaign in 2011, which came to be known as “The Summer of Messing Up.” It took a while for the stressed-out campaign staff to understand that “messing up” is DevOps for “failing forward,” especially as the team was building everything from scratch, saving virtually nothing of the 2008 campaign’s technology. In due time, the team coalesced, and intensely planned around single points of failure and scalability choke points, which came into play as the campaign’s apps took up 60 percent of Amazon’s medium instances in the eastern US. The technology of release management was straightforward (the team used Puppet), but release management best practices are another thing. Though the campaign was extraordinary in many ways, these challenges are familiar to anyone who has made DevOps work. The battles are not unpredictable, but overcoming them is still a challenge.