Feature:

Continuous delivery process in four steps

By James Denman

TheServerSide.com

The developers at Edmunds.com kicked their efforts into high gear with the implementation of a continuous delivery process. There are four major pillars of the process at the online publisher of automotive information -- automation, DevOps, cloud infrastructure and a development philosophy that looks at everything as software. Here, we look at each.

Automation

For Stephen Felisan, vice president of engineering and operations at Edmunds.com, "the first big hurdle to overcome was making automation a first-class citizen in people's minds." Automation, he pointed out, isn't just nice to have in a continuous delivery system; it's a must-have. Today, the development team at Edmunds looks at everything they do to see what they can improve with automation. "Today it feels natural," Felisan said, "but in the beginning, automation did not feel natural."

Automated processes were seen as inferior to manual processes, and some people feared they could automate themselves out of a job. Felisan also pointed out that automation reduces fatigue and allows for time to focus on more interesting work. Using newer automation tools such as Puppet and Chef, as well as new cloud services, also helped in the process.

DevOps

Taking a DevOps approach tore down the operations wall that used to block the developers' view into production issues. "Things are more transparent and more synergistic," Felisan explained. Before taking a DevOps approach, deployment was the single toughest task developers did regularly -- taking up more than 25% of their developers' time. Combining automation and DevOps techniques reduced that deployment time to practically nothing, which gave developers an extra eight hours each week to ensure that code was reliable and easy to maintain.

Cloud infrastructure

Edmunds uses public cloud resources through Amazon Web Services and their own proprietary virtualization on premises with private hardware inside the firewall. In both cases the advantages are the same. According to Felisan, extensive virtualization gives them development, testing and production environments that aren't just available at a moment's notice -- they are also more consistent than manually provisioned environments.

The hundreds of thousands of individual settings and configurations managed automatically by their virtualized environments each day used to require huge amounts of hardware, with individual configurations for each appliance. With a virtualized architecture, new environments can be supported automatically. Older environments that are no longer used can quickly be spun down to free up resources for new projects.

Software-centric philosophy

The previous three components -- automation, DevOps and cloud infrastructure support – are what Ajit Zadgaonkar, senior director of software engineering at Edmunds, calls the most important philosophy: viewing everything as software. "We can leverage software best practices on everything," Zadgaonkar said. This means his development team can use automated tools, such as static and dynamic analysis, on things not traditionally seen as software.

Content management, for example, benefits from viewing editorial copy as software. Edmunds adds tags and metadata to the copy, which allows them to dynamically present content to the consumer in new ways. That metadata information is all viewed as software, so it's all available in the source code.

Edmunds puts all its service-level agreements (SLAs) into the source code as well. This makes it easier for developers to debug and fix problems when performance goals are missed. Felisan said the development team now has all that information at its fingertips, so there's never a question of what to do or who's responsible when services interact.

The team is also experimenting with taking the continuous maintenance concept one step further. Edmunds might be able to automate the process of fixing integration errors that pop up based on the best practices in their SLAs. "We're taking it slow because it's sort of scary not to have human intervention there," said Felisan, "but we have had some success already."

For more information

Discover more here: Continuous delivery and continuous integration.

10 Jul 2014