At enterprise translation platform Smartling, developers strive for continuous deployment, rather than a six-month waterfall, or even two-week agile cycle. But why is this better? And how do they actually make it work? In the second part of a two-part interview with The Enterprisers Project, CTO Andrey Akselrod provides some answers.
The Enterprisers Project (TEP): Why is your continuous deployment model more powerful than the typical two-week agile cycle?
Askelrod: We see the typical two-week cycle as being, well, too slow. We think of the deployment process as series of OODA loops. OODA loops were developed by military strategist and USAF Colonel John Boyd who applied the concept to the combat operations process on a strategic level; they're now used in commercial and learning processes as well. The loops are defined as the following steps: Observe, Orient, Decide, and Act. Each act is a fix or change that can then be immediately deployed, so if your OODA loop is faster than a competitor's, you tend to win. It's the ability to more quickly figure out what's going on around you, see how users are using the software, then analyze that information and act upon it. We can react to and fix most individual issues within a day.
In fact, we average 10 production deployments (10 OODA loops) per day. When you're only able to deploy once every two weeks, you only receive feedback to observe and act upon once every 14 days. Whereas with a continuous deployment model that allows you to deploy on average ten times per day for the ten working days of that same two weeks, you can average 100 deployments in the same period of time. With continuous deployment, we can deploy 100 times faster than a two-week cycle.
TEP: How does it work coordinating new releases if you have several different teams working to solve problems?
Akselrod: When more than one team needs to work on a project, it doesn't cause conflicts; there's always one individual project lead who owns it, even when multiple teams are involved or developers need to be borrowed from other teams for the project. There's always a chain of command in place, so there's someone looking out for each level of the project, making sure everyone has what they need.
TEP: What advice would you give CIOs or CTOs who want to try continuous deployment?
Akselrod: As far as advice, it's pretty simple: Do it or die. Pretty soon, if not already, you'll have to have it, or your competition is going to eat you for lunch.
That said, it's important to make the change gradually rather than all at once. Start with one component — a simple, push-button deployment. Then, gradually build out automated tasks into this process.
You'll also need to lose your QA department. Developers should be automating, and you shouldn't have code going back and forth between developers and QA — that slows everything down. QA should be a part of the culture, and all developers should be able to handle this, but QA as a department won't work with a continuous development environment.
Further, make sure you get support from all levels of the company when you decide to implement continuous deployment; it can't start from the bottom up because the transition needs to be coordinated from the top decision makers in the company. It's an intensive change.
TEP: Are there situations where it never works? Pitfalls to avoid?
Akselrod: Are there situations when continuous deployment isn't appropriate? Yes, but they're rare. It's a matter of stakes. I wouldn't suggest continuous deployment for NASA or the software that runs medical equipment actively keeping people alive. With most software deployments, a small bug that can be squashed in a day or so won't be a huge detriment, but in cases like the above, where the software has to work 100 percent properly the first and every time, or it could be a matter of life and death, continuous deployment may not be appropriate.
But fortunately, most development teams don't have to worry about people losing their lives if there's a single fix needed in the code, so continuous deployment is generally recommended.
