DevOps proponent lays it on the line: stop the madness and start automating

Let's face it -- the pace of software releases is getting more frenzied. Two years ago, 35% of enterprises responding to a Cloud Native Computing Foundation survey were releasing software on a daily or weekly basis. In CNCF's most recent survey, this number surged to 65%. Those respondents with daily release cycles increased from 15% to 27% during this time.

In busy software development shops, it's great to have really smart, skilled people who are really good at developing elegant solutions for the business. But with releases going out the door on a daily, maybe even hourly basis, even the best of the best find it difficult to stay on top of this process, which often involves going back to make fixes. 

That's why it's urgent to put in place a well-honed and highly automated continuous integration/continuous delivery (CI/CD) strategy, according to Andrew Davis of Copado and author of Mastering Salesforce DevOps. At a compelling session at Dreamforce 19, he outlined the challenges enterprises now face, pointing out that effectively accelerating development lifecycles "requires thought coordination and good tools."  

While Davis' talk was directed at Salesforce teams, his insights resonate across the broader IT realm. Typically, he related, software deployments follow six phases that form the foundation of DevOps:

1. Understand what users need.
2. Build it.
3. Make sure it works.
4. Makes sure it works well with everything else.
5. Make sure you didn't break anything else. 
6. Deploy it to users.

The final three steps is where many development teams tend to stumble, Davis says. "The most blissful thing about writing code or doing a complex admin task and so forth is when you get everything in your head, and you can see how everything fits together, and the world disappears, and you know exactly how your org works, and anybody could ask for any change and you can fix things. Developers live for that blissful feeling -- to know everything and fix anything."

The catch is, a particular project ends, distractions distract, new projects begin, and time passes, Davis continues. "That disappears out of your working memory right? There may be a day, or a week, or a month delay before you know that you broke something. By the time three weeks has elapsed, you forgot that you even built that thing. And if you remember that you built it, you forget how you built it, you forget exactly why you built it. You can make another change of course, but then it might take you another three weeks until you can get that back to your users."  

Multiply this by hundreds or even thousands of change requests within a large organization, and it's easy to see how things can go awry. 

DevOps brings order and flow to this potential madness, and Davis boils it down to a three-step process: development, innovation delivery, and operations. "There's the development bit where you create new stuff, and the operations bit where you run stuff in production," Davis says. "Then in between there's this process, innovation delivery, which is delivering all that nice innovation to production." That's why a highly automated DevOps process is required, to take out and systemize the manual tinkering required for that middle phase between development and operations. 

Davis illustrated what an effective DevOps and CI/CD strategy should look like:

• Every developer and team in a company merges into a common trunk or code base at least daily.

• As soon as the code base is changed it runs automated tests.

• If the tests fail or things break, they are fixed within ten minutes.

The ability to automate the testing phase, to run fast tests, is key to CI/CD efforts, Davis says. "Developers need fast tests where they can get feedback while they still have all this awesomeness in their working memory." These tests need to be designed to give "close to real-time feedback for the developers, feedback in less than five minutes." More comprehensive unit testing can follow.  

The continuous delivery aspect also needs to address another problem that arises called "configuration drift," in which "environments get out of sync for a lot of reasons," Davis said. "Maybe people are making changes in production that don't make their way back to development and testing. Or you've changed development environments, but and there's just a bunch of junk in your dev sandbox that you've had since 2006, and not refreshed, and you know it doesn't quite match production."