Using your pipeline to enforce corporate rules

~ kmugrage ~ Leave a comment

I just took part in a discussion about Continuous Delivery fundamentals at a conference. During the conversation different questions came up about security and compliance, with reactions varied from “well of course you have to do that” to anecdotes about shadow IT where corporate polices are ignored.

It wouldn’t have been appropriate for me to point this out in the conversation, but this is one area where the differences between a CI tool and a CD tool really stand out.

I talked about the ability to run things like security pipelines in parallel with other pipelines in a blog from a couple years ago ( https://www.gocd.org/2016/02/08/not-done-unless-its-done-security ) but I may not have pointed out of one the most powerful options…

The folks responsible for designing and maintaining the security and compliance checks don’t have to be on the product team.

This diagram represents a single pipeline fanning out into two pipelines and then back into one. It’s important to note that these are not just parallel jobs, but entirely different pipelines.

It’s possible in GoCD to have the security / compliance pipeline be under the care of a dedicated team. As much as I’m a fan of cross functional teams, it’s not always reasonable to have all the knowledge you need on a product team. It’s also possible that you would want the work verified by another team for other reasons.

It’s this possibility of parallel pipelines that came to my mind first when I read the new “trust teams but verify” theme for the latest ThoughtWorks Radar. I think it’s a great way to make sure you’re following all the corporate rules (which are there for a good reason) without slowing down your development.

More information:

Is it time to give up on what DevOps isn’t?

~ kmugrage ~ Leave a comment

We recently completed DevOpsDays Seattle. The feedback for the event was overwhelmingly positive in most areas. The exception was some feedback that there weren’t enough technical sessions. This is fairly common with DevOpsDays events, because DevOps isn’t about technology.

Fast forward to this morning… I volunteer to do some mentoring. I was on a Slack channel about DevOps, when someone starting asking Tomcat configuration questions. Again, a technology question. Because in this person’s mind DevOps is what system administrators do.

The problem; most people think DevOps is about technology.

DevOps is about culture. It’s about getting the people developing and operating the software to work together. This shows itself more in organizational structure that any specific technology. I even went so far as to write my own definition of DevOps which I share before doing a talk or workshop so people know what I mean when I say it.

When I was growing up and made a point which may have been correct but didn’t actually help anything, my father would say “That and $5 will get you a six pack”. 

My job is to teach people about Continuous Delivery (which is technical) and DevOps (which isn’t). If people are coming to DevOps events that I’m helping organize and not getting the information they need, am I failing at that job?

Words change meanings over time. Every year the folks who create dictionaries add “new” words which have to make English professors shiver. Maybe DevOps doesn’t mean what it was supposed to mean anymore.

I’m not quite ready to wave the white flag.

All of this said, I’ll still try to teach people what DevOps truly means, because without the culture change the rest of it is doomed to failure. But maybe it’s ok to let a little more technology in the door to meet people where they are.