Owen Gotimer
Hello everyone. My name is Owen Gotimer. I’m the community manager at TechWell. I’m joined today by Tom Stiehm the CTO at Coveros. Tom, thanks for joining me today.
Tom Stiehm
Thanks for having me.
Owen Gotimer
Tom, we’re gonna chat about some DevOps and DevSecOps anti-patterns. Do you want to give a basic explanation about the anti-pattern of continuous build?
Tom Stiehm
So what we did in the early days of agile is a lot of the agile engineering practices where if we do something and it’s good, doing it more often would be better. So in the late 80s-early 90s, people started experimenting with things like daily builds or weekly builds, and so the idea came around that we should do continuous builds. But we should marry that with some kind of automated test suite that would show that the software still works, so that’s continuous integration. So the idea of continuous integration now is that every time someone checks in, you do a fresh build, you run a suite of usually unit tests that verify that the code still works, as the programmers intended it to work, and then you run some kind of code quality static analysis. So that’s continuous integration. Continuous build, the anti-pattern is that all you do is build the software on check in. You don’t verify that it works by running a suite of tests and you don’t run static analysis or if you run static analysis you don’t make changes because of the results of that. So what you see happening with a lot of organizations as they move toward agile or they even just try to adopt continuous integration, they make the mistake of just doing essentially a third of it, where they’ll build. Now often, because you’re not doing things that help you increase your code quality, those builds fail a lot. Since they’re just checking to see if it builds, they often ignore the failures, and then the origin of those failures get muddled with a series of check-ins that just increase the amount of failure you have in a build. So what you really want to do is make sure that you have a suite of tests you can run—a lot of times, that’s a unit test suite—and then add some kind of code quality static analysis, like using SonarQube, after you’ve you’ve passed your your unit tests, and then reacting to those SonarQube results, cleaning up the messy code you have, reducing the amount of redundancy you have, reducing the amount of code smells or other technical debt that SonarQube shows you.
Owen Gotimer
The reaction piece is so big to even in other aspects like security scans. It’s great to have security scans, but if you’re not reacting to what those results say and do something about it, your security is never going to get better.
Tom Stiehm
Yeah, so agile and DevOps in the end are about a lot of it is about feedback cycles. So the thing that continuous integration gives you is your first code health feedback cycle. So if you’re if you’re not paying attention to what that feedback cycle is saying, you’re missing a lot of information that’s going to help your product work better. And so I think you’re right, you do have to pay attention to those feedback cycles and then use the information you get from them.
