All right so we're here with Tao and Jackie Michel, the senior product manager over release management release is comprised of two groups: release management and progressive delivery. I am over release management. And/Or eco lewinsky is over progressive delivery. When we look at the separation of what each of those cover release management is all about. Getting teams to effectively do to deploy really when and where in a traceable, secure manner, and this means that I have four main categories.

This is release orchestration, which is the ability to plan and deploy code. Some feature functionality for that would be our releases. Page environments pages is a second category. This is our static site generator product. We have a bunch of templates that allow you to use get lab pages with any static site generator. It's really popular issue for people who are using get lab release. Governance is the third category. This is where you use release evidence to track all the things that are contained within any given deployment or release. This could be assets packages.

It's a snapshot of your of your code. Release governance will expand into policy potentially interlacing, with compliance a little bit more and then the last category and release management is secrets management. This is inclusive of CI CD variables and secrets that are in a pipeline, but also SSH keys. Any tokens that you may use as a part of your get life experience. It's really the only category that doesn't neatly fit within this deployment idea, because it's a continuous kind of object, that's used throughout gitlab.

Progressive delivery, on the other hand, is all about the control and monitoring of deployments, and this is seen in four different I think five different categories right now, the first one is continuous delivery, which is being able to deploy as often as you you would like to and deliver to your customers. A part of that is being able to create a dynamic environment for reviewing your changes with review apps. This is related to and tangential to, the testing verification at work that james heim book is doing then there's the incremental rollout future functionality.

This is kind of the bread and butter of progressive delivery. This is how we would promote things like advanced deployments, blue green canary deployments, leveraging partial deployments to different environments, really it's how we allow and enable customers to continuously deliver or deploy and then lastly, feature fad feature flags, which is the the ability to toggle changes on and off, for a production environment.

So, for example, you'd add a feature flag to a feature that you wouldn't want to show up in production, so your customers don't experience it and then more most recently, we added a feature called merge strains, and this is the ability to have a a train or a collection of merge requests, get merged into master rather than merging each individual change independently.

So does that kind of help describe the delineation between release management, progressive delivery? Yes,.

So when we look at incremental rollout, this is about deploying new production code. So that's really your continuous deployment framework, whereas continuous delivery is about building a zero touch. Software delivery model, okay,.