GitLab Compliance Group - Meetings, 14 Apr 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Compliance pipeline walkthrough

Description

Sam Kerr discusses compliance pipelines and how they fit with our product principle of 'always allow for deploying to production.'

A

Hi, I'm sam kerr, I'm a principal product manager here at git lab and in this video. I want to spend a few minutes talking about our upcoming compliance pipelines capabilities, because I know it's been development for a long time. It might mean a lot of different things to different people and wanted to clarify what we'll be releasing, as well as how it fits in line with some of our product principles such as always allow deploying to production so to kick things off.

A

I'd like to share my screen and walk through what we will be releasing in the upcoming release.

A

And so what I'm sharing here is a compliance project that we have on get lab staging, and I want to highlight a couple things here, so we have two projects: one sam's app, which would be where development would be occurring and the other being sam's compliance, which is where compliance team would be specifying compliance related policies and requirements inside the individual groups.

A

We will have this notion of compliance frameworks and I've gone ahead and created one called sam's framework for this video, and if we look at it, it's going to have a pointer to a new gitlab ci yaml file. That's going to live inside of that compliance project that I mentioned.

A

So if we go back and look at it, this is where we would envision individual compliance teams having their single source of truth for what needs to be run for a compliance-related job. This is where they might log artifacts ensure some sort of scan or extra step of logging is done, and then it's going to be, including the developer pipeline that has been defined for the project that has that same compliance framework label.

A

That's relevant so remember that we made sam's compliance apply to all projects with the sams framework label, so let's go ahead and look at sam's app and we'll see that it does indeed have that compliance label.

A

If we look at the getlab cieml file in this project, we'll notice that it only has a single job called a job which is building the app, it also has a job which is attempting to override a compliance job, and so, if we go look at the pipeline, what we will see is that the compliance required test job from the compliance pipeline has been included.

A

We'll also see that the developers attempt to override the compliance job was not successful. It was not overwritten, and so this is great. We're really excited for what users are going to be able to do with this, but the concern definitely is valid that hey what if something happens upstream in that compliance project? What do I do?

A

What does the rest of the team do to ensure that we can deploy to production because time can be of the essence and really when we were working on this capability, we tried to work with this concept of safety valves in mind to make it so that it's not a you can be compliant or you can always deploy to production, but rather you can be doing both and that there are going to be those safety valves that, when the compliance system is having an issue for whatever reason, there's always going to be a way to be able to deploy to production if needed, and so we have a couple different ways that we're going to be approaching this uh for group owners.

A

Remember where we looked at the compliance framework, they could simply go in. They could edit the framework itself to not include the pipeline that was causing problems. The compliance team could obviously go fix the issue in the compliance pipeline. That was giving problems, but really the question is: how do we give local control to the development teams that are going to be most impacted by an error upstream and a compliance project? How do we make sure they are empowered to be able to deploy production and really the safety valve?

A

We're really excited about is pretty simple. Remember how they apply this framework label to say: hey. We will use this compliance pipeline if the project owner needs to push for production, for some reason, they'll be able to go ahead and remove that compliance pipeline from the project, and that's going to be on this screen. You can see in the drop down here. I would just go ahead and select.

A

None in this case save my changes and because that compliance framework label has been removed. That would allow the developer to do what needed to be done. That would create an event that would be some sort of variance that the compliance team would need to understand why it was made.

A

What happened, what changed but would give the development team the flexibility to an emergency push code to production in line with our product value, and so I'm hoping that, after going through what we're going to be releasing in the next iteration with git lab and compliance pipelines, this helps make it a bit more clear on how we're going to be enabling compliance teams with the single source of truth places to define what needs to be done in their jobs, while also still adhering to that product principle of always allowed deploy production again.

A

I'm sam kerr would love to hear your feedback or have a follow-up discussion thanks. So much have a good.

A