Scott Nasello

So before I start, John Smart just asked me, "Is your talk funny?" And I said, "No."

I have 19 slides on vegetables, but we'll go ahead and start.

Our delivery teams at Columbia have always been pretty autonomous. When we designed our pipelines, we wanted to honor that autonomy, create the experience of full ownership, as well as give them the opportunity to customize for their own needs.

In the ideal case -- I don't think my slides are moving. There we go. In the ideal case, the teams are stewards of that responsibility and freedom, and they actually do the right thing. But the reality is sometimes those teams will optimize for their own incentives, or maybe even for their own delivery, and that certainly isn't the enterprise best ideal.

We've been heavily inspired and influenced by Topo Pal and Capital One. If you haven't checked out the Software Clean Room, it is amazing. It has a lot of focus and rigor on attestations, artifacts, and really limiting access to production, which I think is pretty awesome. But we've taken that point of view, and we've actually engineered it into our pipelines so that we're enforcing those foundational gates. That way we get to better outcomes, less variation, and ultimately more reliability in our pipelines. As an aside, it helps us to troubleshoot those pipelines because they have a lot of commonality in them.

Pipeline templates and containerized pipeline services have been a huge unlock for us. It helps us to drive a lot of repeatability. The fact is, we have hundreds of function apps that are all using a centrally managed, version-controlled template, which gives us a lot of repeatability.

The fact is, we're trying to make doing the right things easier than anything else. That really starts with better defaults, whether it's encryption, whether it's application settings, service bus integrations, et cetera. We want to get to this point, which is kind of nirvana, but we want to get to automatic compliance or continuous compliance that John Rez was talking about yesterday.

I think we missed a slide. I'll keep going.

We want to reward teams for doing the right things. Fundamentally, you have these teams in your environments, the teams that can make high-confidence changes at speed without impacting other teams. We want to reward that and be a lot more on the carrot side than on the stick side, but with guardrails.

Our InfoSec and change management teams have been wonderful partners on this journey, and they've been experimenting, developing, and testing new ways to have lighter-weight governance into the pipeline. I'm going to share four examples.

Because everything is templated, our InfoSec team can all of a sudden now own services that matter to them, things like credential scanning, and that gives them a lot of autonomy and drive to actually own those processes.

Another example are code scans for vulnerability or bugs. This not only has the effect of giving feedback to those teams that need to improve their practices, but it really elevates the InfoSec team to be first-class citizens within the pipeline, within the value stream, and they actually have a control plane to drive the things that are important to their objectives.

Chaos Squirrel, our developer tools team wrote this to drive better governance within our cloud environments. We can run it in either a what-if mode or in a destructive mode, and it's driving a lot of great things. I have stickers, by the way. They're good.

I was lucky enough to work on a team in the spring about fixing change management and fixing the CAB specifically. We came up with a lot of ideas. It's free, the document, so you should download it. We talked about having a change service that could run in a pipeline.

In our example, we've optimized that change service for standard change. That really means that teams are pre-authorized to run at their own speed because they've demonstrated the rigor, and that's really continuous deployment at the best case. It can run in either a build or release context. As an example, our platform engineering team, they typically use a lot of pull requests and merge requests for self-service, and those run on builds, and we want to capture that into our change management system.

Within the CMDB, you'll see CIs either at the team, repo, or a pipeline, and they all have different reasons for being there. But the key thing is if you apply the SRE error budgets, you can apply it to this domain, and this is really change error budgets. Teams that actually start to degrade, you can degrade their pre-authorization.

So if you have a pre-authorized change that goes automatically within the pipeline, you get your corresponding record in your change management system. Life is good. On the other hand, if your change surface area is rather large, or if your team is developing, that would be categorized as a normal change. We're going to block that deployment to production, and we're going to invite you to have a conversation with people that care about the outcome.

After your approval, whether it's a BCAB or a virtual CAB, maybe a show of hands or ad hoc CAB, and you secure your approval, you can re-trigger that pipeline to go through.

Regardless of whether we're talking about standard change or normal change, we're linking the artifact that was actually produced in the pipeline to the change record. So you're getting the attestation, you're getting the audit trail, if you will, that make auditors and stakeholders happy.

I think pipelines are a team sport, and this is an opportunity to bring your governance folks into the conversation to help them to drive behaviors and start to own some of those artifacts. So thank you for having me.