Edmunds.com, a popular supplier of online automotive pricing tools, thrives on constant innovation. Innovation requires experimentation, which can imply serious risks. Keeping the balance between fast turns and safe steering has required a lot of change in IT at Edmunds.com. Taking on continuous software development let the engineering and operations teams try new ways of programming without introducing undue instability.
According to Ajit Zadgaonkar, senior director of software engineering at Edmunds, there was -- and is -- a shift in the company's focus on technology. The business is driving interest in new technologies such as automation and cloud infrastructure, as well as new techniques such as DevOps and design thinking. When implemented properly, these components naturally add up to continuous software development.
The vice president of engineering and operations at Edmunds Inc., Stephen Felisan, called the switch to continuous delivery a tremendous success, with huge benefits to both the development team and the organization. However, the successes were met with no fanfare whatsoever. According to Felisan, before implementing continuous software development, he heard a lot of complaints about the difficulties of deploying, and afterward he simply heard nothing. "The organization quickly started taking it for granted that automated deployment would just work," he said.
Stephen FelisanVP of engineering and operations, Edmunds Inc.
According to Felisan, the QA organization -- and Edmunds.com in general -- had to go through some difficult changes to make continuous delivery feasible. "A lot of folks don't like change," Felisan said, "and that's not just within the QA team; that's across the board." Although change is often hard, people do tend to accept it once they see the value in it.
Find a more collaborative strategy
The development team once depended on product owners to define requirements, from capability to availability. Developers, project managers and operations now meet with product folks at the beginning of a new development project to come up with preliminary estimates for what the project will require.
"Business folks are frequently just guessing when we ask them about technical details, like how much availability they'll actually need," Zadgaonkar said. Because they lack technical experience, it can be difficult for them tell if their business services will need five nines, or nine nines or only two.
Under Edmunds.com's current continuous software delivery model, the developers and business stakeholders collaborate to write service-level agreements (SLAs) based on design-thinking assessments of business needs and technical capabilities. The SLAs serve as both living requirements and living code documentation. "That information goes into the source code and becomes the responsibility of the people that actually manage it," Felisan said.
He said it makes sense to take those technical aspects out of the purview of the business folks and give it to the development team. Developers know how fragile their applications are, they know how far they can push their applications, and they know how to fix their applications. Sometimes the part that needs fixing is the SLA.
When disconnects arise between what the business is asking for and what development is delivering, the two have to sit down together and cooperatively decide on the right way to get the project back on track. This is where project managers shine. Effective project managers are the collaborative glue that holds teams together and keeps everyone focused on reaching shared goals.
Keeping it all together
The software developers at Edmunds.com had great success with incorporating SLAs into the source code, which prompted them to also incorporate text content and media control of video and pictures from their content management system into the source code. They further expanded their source code to include all the configurations from their infrastructure. Most recently, they've added processes for wikis and other outside sources so they can also be packaged into the source code.
Keeping everything in the source code expands the benefits of continuous software delivery and makes applications at Edmunds.com easier to maintain. The developers there depend on source code management tools from Perforce. "Perforce is foundational," Zadgaonkar said. "We view everything as software, and Perforce keeps all our software in one place." Zadgaonkar was also impressed with the versioning capabilities Perforce offers, which make forensic code analysis much easier. Alternatives to Perforce include Microsoft Team Foundation Server, IBM Rational Team Concert, Apache Subversion and others.
A little history and flavor
Like most enterprise development shops, things have changed a lot at Edmunds.com over the past decade. Prior to 2005, Edmunds.com was taking a Waterfall approach to software development. Then, it started to go Agile and in 2006 decided on an iterative Scrum approach. It spent four years growing as an Agile organization before looking into continuous software development. The real push for continuous delivery started late in 2011 and hit a real height of change in 2012, when the company adopted design thinking.
Design thinking is an approach to innovation championed by Stanford University and embraced by firms such as Ideo. In many ways, design thinking is very similar to Agile development, but it spreads beyond the development of software specifically. Felisan described design thinking as a collaborative process between various roles that keeps the whole team focused on the end goal, rather than their individual roles.
Ancestry.com on its top lessons learned in switching to continuous delivery