News Stay informed about the latest enterprise technology news and product updates.

Continuous software development revs up innovation at

Car prices are constantly changing, and changes right along with them, thanks to their effective continuous software delivery process., 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 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.

The organization quickly started taking it for granted that automated deployment would just work.
Stephen FelisanVP of engineering and operations, Edmunds Inc.

According to Felisan, the QA organization -- and 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'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 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 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 over the past decade. Prior to 2005, 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.

Next Steps on its top lessons learned in switching to continuous delivery

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

How close is your organization to implementing continuous software development processes?
Many teams may already be practicing Continuous delivery if they use a source control system where everyone is on master and trunk.  If those same commits are being pushed to testers almost the moment they are available to deploy, that comes pretty close already to being there.  There's more to it though, you need to be able to feature flag and hide parts of applications that aren't ready, and know when to remove such hooks and flags  once they've proven stable.
We actually have a couple of small continuous delivery pipelines up and running for smaller projects. These are primarily projects that develop small prices of stand-alone functionality to assist in distributing content to our partners. One of the obstacles that we’ve encountered was with incorporating our change management process into the pipeline. We were able to handle this by making use of existing APIs exposed by ServiceNow so that the process could automatically update change tickets based on the outcome of the tests executed. So far, it works well.
Thanks for the feedback! @Veretax, I heard some really interesting stuff at OReilly's Software Architecture Conference yesterday afternoon about feature flagging. It seams like a really good technique for any team, but especially for teams working with continuous delivery. @Mcorum, that sounds like an exemplary use case. Would you be interested in getting in touch offline to discuss the details?
For any readers who are interested in investing in continuous delivery, what questions do you have? What is your interest in continuous deployment? What are your worries?
I think that continuous delivery is an opportunity for strong teams who already have a culture of accountability and ownership. What's your perspective on the argument that in CD environments, cracks in the pipeline, problems in delivery, and weaker skill sets can become much more evident to the entire business? Is it a good way to build a culture of accountability or should that be a frightening thing for development managers that don't have complete confidence in all parts of their org?
Good questions, My gut reaction is that CD systems do point out cracks in the pipeline/weaker skillsets and that makes it a good way to build a culture of accountability – IF it's coupled with training and support for developers (including testing and ops). I think dev managers would be right to be nervous about moving into CD without complete confidence in the team, but should use that as motivation to solidify necessary skillsets. A part of a manager's job in that situation would probably be to get the team excited about growing into continuous delivery more than worried about how hard it is to grow. That's just my own gut reaction, though, I'll ask around with my experts and see what they have to say. Thanks for the feedback!
@jcoyle: Continuous delivery should be a little frightening. This scenario has most companies delivering many times a day, some companies are claiming to deliver 100s of times a day.

This means there is more of a reliance on monitoring tools to discover problems where testing would have found them in a more traditional environment. 
I think those that are concerned about bugs that testing doesn't have to find in Discrete Delivery (notice I didn't say continuous, we surely aren't deploying every second.) The reality is a lot of those same issues wouldn't be found in more formalized testing approaches because of the way in which many approach the craft.  

Consider that with Continuous deploy, and the right architectures in place, that many of those deployments will be small. (think Calculus small), and that means you can reduce the risk with each successive commit.  It means you can focus more on what really is a risk and spend lest time wasting over things that are not likely changed at all.  There's a lot to gain there.