July 21, 2017

Build It and They Will Come

There’s so much talk about DevSecOps I’m hesitating to write this and add to the noise. Most of what I read is about Continuous Integration (CI) and Continuous Delivery (CD) and that’s great. But many of us are dealing with a lot of legacy code and configurations, along with 3rd party vendors and products that don’t easily fit that mode. And yeah, we still have a lot of that silo mentality around that makes it hard to “un-separate the duties,” so to speak.

The best acronym to represent DevSecOps is CALMS. It’s been said many times that DevSecOps is first and foremost a culture. And that is as true as it gets. Without a commitment to that culture change, there is little chance of success. So how does true culture change happen? One way is by showing little points of success and sharing the joy. Once we satisfy the WIIFM question, most of the cultural barriers can drop.

Agile and DevSecOps rely on breaking work into the small, deliverable pieces, the MVP. So let’s make sure we’re practicing what we preach. Small chunks that deliver value.

So what could be a little point of success for DevSecOps ? Well, the “A” in CALMS stands for automation, and that’s the place to look first. While automation ultimately needs to be across the entire systems life-cycle (including system provisioning, configuration, build, testing, monitoring, etc.), where I’ve seen the most bang for the buck is in deployment automation. Getting that new code change from development, through the test regions and into production without things breaking. How do we make that happen consistently and error-free? Practice, practice, practice.

So, let’s focus on automating the deployment from the Development source repository to Integration region. Even if the automated tests aren't quite there yet. Even if the build breaks often. Even if the build is done (gasp) manually. Did the actual deployment work? Great. Now run that same deployment automation into UAT. Did it work? No? Ah, forgot to change that configuration to use the corresponding region’s service account! Now, run that same automation. Works! Now, run that same thing, this time with the target region STG. Getting there!

Now that might sound easy, but maybe your deployment is a complicated series of manual steps that’s a little more difficult to completely automate. OK, let’s look to the “L” in CALMS apply the Lean MVP principle and break DevSecOps down further. Maybe the deployment can still be manual for now (just hold your nose), but perhaps now we focus on deployment validation as our first success. Write some code that executes non-destructive tests against the database, for example. Perhaps it just validates that the service account works. Try to call an API/service. Validate that the file directories are writable. Look for a specific success or failure log entry. These are small pieces of code that can catch deployment errors very quickly without having to release it to users who will find those issues on their own.

Back to that culture challenge, now we have something we can show using the “M” for measurement. Look, our validation process passed! Time to “S” for share that success, perhaps in a dashboard that shows the build and deployment statuses. Even if you have to manually update that dashboard.

So we can get small wins along the way.

But, you say, “what about CD? This isn’t DevOps!” Perhaps you have to deal with Release Management because they only want monthly releases? That’s a different fight. Your focus is to make delivery to PROD a non-event. And since you’ve automated deployment across the non-production regions you know it’s just gonna work. 

Build that Easy Button. They will come.