Release Management in the Era of Progressive Delivery

 And then how the use of feature flags can impact progressive delivery, and finally walk through top considerations for enterprises who are looking to adopt progressive delivery as a practice.

 So let’s start with feature flags. What are they?

 A feature flag gives you the ability to turn features or subsections of your application on and off remotely without having to actually redeploy, of your software to your environment.

 So put simply a feature flag is an if statement in your code.

 So if your feature flag is enabled, then that code is exposed to the users that you’ve identified.

 Feature flags are not a new technology or concept. It’s been something that’s been used by developers more on an individual level for a long time, but it’s been formalized in usage and management across organizations in the last five to seven

 years, really pioneered by some of the software development leaders like Netflix, Uber, and Facebook.

 And now this usage and standardization into the CI\CD toolchain is growing more

 and more across different companies.

 So now let’s talk about continuous delivery.

 This is something folks are, you know, more well familiar with, and it is a software

 development discipline, where you can build software so that it can be released into production at any time, and you’re doing continuous delivery, when your software is deployable throughout your lifecycle.

 Teams are prioritizing software being deployable over features, you know, working on new features.

 Anybody can get automated feedback on the production readiness of their system and you can perform push button deployments to any environment, so a lot of it is about automation and then increasingly, you have in production-like environments where code is being pushed in order to test your code pre production.

 So CI\CD practices are the foundation for progressive delivery, but just with continuous delivery, even when you’re doing it well, there are, you know, things to think about how can you improve? Are you comfortable moving from continuous delivery to continuous deployment where every check in can be pushed automatically into your production environment?

 You don’t have manual stops along the way.

 Are you comfortable deploying on a Friday?

 What would that mean for your team in terms of their weekend?

 And then do you test in production?

 This is something we’ll talk about more, is focusing… the focus of testing has been shifting left, but also shifting right into your production environments where you’re testing with real users.

 So let’s now talk a bit about progressive delivery, which is the process of pushing changes in a product iteratively, first to a smaller audience and then increasingly to larger groups of your users.

 So that you can maintain control over the users that have the feature being exposed to them as well as over quality.

 So you’re incrementally rolling your features to specifically selected cohorts, and it limits the blast radius that is impacted when you deploy a new feature

 and once you’ve tested in the smaller group, this selected set of users then you can

 have the confidence to start rolling it out to larger and larger groups until you’ve rolled out your feature to all of your users.

 So this is deploying progressively where you have the feature flags that are there to control how the feature is rolled out.

 And in this way, the release is now decoupled from the deployment of your bits.

 So you may deploy into production but only when you actually enable the features that are new in your new version.

 Are you really releasing your new version?

 You… with this, you are now testing features more in production with your users and you have more confidence in your release, because you have control and agility to respond quickly when there are issues.

 So you can release with confidence and maybe even on a Friday. 

 So let’s move into how feature flags and continuous delivery help you to reach progressive delivery.

 So where can continuous delivery as we know it, today, traditionally, fall short?

 Organizations can be doing continuous delivery really well.

 But there are still limitations to this approach, you might be increasing your velocity and shipping new capabilities more often to your users but this also introduces risk with this shortening cycle.

 Everything that you’re delivering to production, to your users needs to be user ready.

 So if there are issues that come up post deployment, the entire version needs to be rolled back or forward.

 So you need to have a lot of diligence pre production, so you feel confident

 in that, otherwise it can, you know, trigger a whole rollback of your version.

 The majority of the testing in CD, though, is done pre production, where you may

 be missing some of the real world factors in your production environment, it’s very difficult to, you know, have a pre production environment with all of the factors that

 might be in your production environment.

 And more importantly, you’re not also able to test and respond to feedback from real users.

 So this can introduce surprises that you’re not ready for when you deploy to production. And then again, you have to respond with full rollbacks.

 With traditional CD, it’s very difficult to have control over that blast radius, or

 who is seeing your new capabilities in your new version.

 You don’t have focused control over the users who it’s exposed to and you also don’t have the ability to roll out features to specific customers and then rolling out and rolling back gradually becomes much more complex.

 So let’s take a step back and look at how progressive delivery might work in

 a traditional release with Canary releases.

 So you can deliver progressively to environments using Canary deployments and this does limit exposure, and you can test in

 production when new code is deployed.

 The control in this case is in the infrastructure networking layer.

 So this is how you’re controlling the users that are getting access to your new version, we select in the diagram, you can see that we’re selecting a small percentage of users that are routed to the servers where version two has been deployed.

 Over time you roll out the version two to more and more servers and route more users to version two until all of your users are on version two.

 This approach does allow testing features with small groups of users in your production environments, which is great, you’re able to get that testing done.

 But there are a lot of challenges.

 The ops team has to stay involved in the whole process and that can be complex to control.

 There are, you know, limited mes methods for targeting which users to test a new feature on, you don’t have the control and all of the inputs of the types of users who you’re exposing this to with, you know, the control we have in the networking layer.

 The feedback loop becomes harder as most deployments of a new version may contain many changes, right?

 It’s not just a single feature that’s being deployed and exposed through this, but a whole

 version of your software. So you may get feedback on a specific feature, but you have to still respond at the full version level. So rollback is at that granularity where the entire version must be rolled back when there are issues or negative feedback on a given feature.

 So now let’s see how progressive delivery for users with feature flags can work.

 And in this case, the canary deployments with feature flags.

 The control lives in the application layer and that allows you to limit exposure of which

 users see a new change, whether it’s internal testers, beta users or a percentage based rollout.

 You have a lot of control over the cohorts of users who are starting to get to see new features.

 And then you can progressively increase that blast radius and help you move forward through that rollout with confidence with each new incremental step.

 So in this case, with the diagram, you can see that with feature flags,

 the new version is deployed into your environment.

 So version two is deployed in that middle box but the features themselves are only exposed to a small subset of users to start with.

 So here’s where the product team after the ops team has done the deployment just once, now the product team can take over and progressively

 start to turn on new features for users, and use a highly selective criteria that’s all within their control.

 Then over time, as the feature gets positive feedback, the feature can progressively

 be turned on for all users over time.

 So this is great. This means that organizations now are changing their

 focus from a full product release mindset to a feature focus.

 And features are no longer bound by the release as a whole, which really changes the game and we’ll get to see that a little bit more in our next example, as well.

 A few things that you do need to be aware of is,

 if you don’t know whether a feature flag will be turned on or off in production, you need to look at testing both states.

 You don’t always have to test all configurations but you have to think about what are the configurations of feature flags you want to test before you get into production.

 Another thing you have to think about is the process and culture changes that come along with this as new team members are going to have different responsibilities, rather than ops owning, you know, deployment and post deployment, you’re going to bring back the development and product teams into this post deployment rollout of features.

 So let’s take this a step further and break down what or release versus feature granularity and control really means in a whole release.

 So we’ll walk through this release, where we have four new features that are being introduced and what are the differences with these two approaches.

 So in the top row, we have our traditional CD process, where we have this release

 where all of the features are included and released together, features one through four.

 And most companies are operating with this model today where the orchestration is that the release version level where the entire release can get delayed and halted if there are issues with any one feature that’s being delivered.

 So in this case, we have four stages and in the testing stage, you see that after commit

 and build are completed, we find that feature three has more bugs than we can handle and we now have to delete the entire release in order to fix those bugs.

 So once those bugs are fixed,

 then you can start again and get into your deployment and release phase.

 In that phase, all four features are released to all of our users in our production environment and after the release is complete, we find out that feature four is not working as users expected and we need to fix it.

 And so rather than being able to just look at feature four, now we have to roll back the entire release to remediate the issue.

 So we’re rolling back the version and we wait for feature four to be fixed before a new version goes to this whole process and is redeployed into production.

 So users don’t get to use any of the new features until all of them are ready, and in a good state and there is rollback of versions and delays and release included in this process.

 So now let’s look at the bottom row where we’re having a release with feature granularity.

 So, again, we have four features that go through commit and build.

 And again, in the testing phase, we still see the same issue with feature three.

 And instead of having unanticipated delays in the whole release, we are able to just

 use a feature flag, turn off feature three, and continue into our deployment.

 So now in our code deploy phase, feature three is turned off, the other three features are enabled and we start to progressively deliver and roll out the other three features to users with only a small subset of users seeing those features to start.

 We again find out that feature four is not accepted well, but it’s only exposed

 to a small set of users who saw the feature before we’re able to respond and just turn off that feature in production.

 Again, we’re not rolling back the whole release.

 It’s a simple toggle on that feature and features one and two are still in production

 and can be continued to be rolled out to the rest of users, while feature three

 and feature four are being developed and you know, will be deployed at a later time.

 So what you’re able to do here is add…

 using feature flags with progressive delivery, you have more flexibility and agility in your release to respond to issues at a feature level with that level of granularity.

 In your rollout and rollback of features, so you’re able to respond to your users without causing delays and rollbacks that can introduce risk into your whole process.

 So feature flags can create a much improved release velocity, because they’re breaking up the dependencies of a release being orchestrated.

 Rather than being orchestrated all at once, you’re looking at a collection of features that you’re able to control.

 So this means that a group of features doesn’t hold up the release just because one is buggy.

 You are able to maintain your release consistency, and velocity because nothing is causing a rollback or things…

 bugs that need to be fixed.

 You’re also able to limit exposure of incomplete or buggy features, you can turn them, you know, narrow it down to its only internal

 developers who are able to see that feature and continue to work on that feature as well.

 So going in a little bit more of this comparison of traditional CD versus CD with feature flags.

 Traditionally, you’re focused on the tactical delivery of bits, but as you get

 with feature flags, you can focus on delivering features and get to that next level of maturity within the organization.

 Rather than looking at environments and the state of environments, what versions are there,

 you’re focusing on your customers and what features that they are able to use in your product.

 Your testing is shifting, right where you’re testing in production with your real users.

 You are able to test with users with focused granularity on what

 are the characteristics of those users.

 Independent features can now be rolled out or back without impacting users, because you’re not having any downtime with a rollback or upgrade of versions.

 And then deploying code to production is, now you don’t have a dependency between the business needs and the development and needs because you can deploy and then

 as your business dictates roll out features when you want to.

 So now that we’ve talked about progressive delivery, and gone through some examples, I want to walk through some of the top considerations to get your enterprise working with progressive delivery.

 So the question that you want to ask yourself is what would be the easiest way to test and learn in production on really users, and you want to be able to easily control which users get to see new features, what user attributes, easily be able to respond

 to things and rollback changes when needed.

 So you think, you know, you could do this on a one off maybe with feature flagging, but how do you get to this place and turn it into a practice where you’re able to test on users

 in a repeatable and automated way.

 So let’s talk about how we can get there.

 The fundamentals, you will need continuous integration.

 So you want to be practicing CI at some maturity level where your developers should merge their changes as often as possible into the main branch and you have CI processes that are automated that are triggered.

 Continuous delivery, you again need to have some maturity in your CD processes with automation that is in place.

 So when you are able to get your code into production, it’s not a manual fire drill, there is a pipeline that is orchestrating or pushing your code to production.

 There may be manual stops along the way, but you have a process behind it.

 And again, it is continuous delivery, we… there’s a misconception

 that you need to have continuous deployment to get to progressive delivery

 but when you’re able to introduce feature flagging with continuous delivery, you can achieve progressive delivery as a practice.

 So that’s the third bullet, you need some level of feature flag capabilities that allow

 you to control the rollout of features, with user attributes.

 And then all of this together CI\CD, and feature flags come together to become this integrated backbone that drives progressive delivery.

 So how do you do this? What do you need?

 Number one is common visibility of feature flags, you want your feature flags,

 and should be an input to your release, where you can see the payload of features that are part of your release that’s being delivered?

 You want awareness into what features are gating your environments

 and visibility for a given environment In your release?

 What feature flags are present? What is the current state have all of those feature flags you get visibility across the pipeline?

 And then what is the release criteria?

 What are the gates? What do you need to meet in order for your release to be complete, but you see on the right is a high level view,

 one of the visuals that is helpful is looking across your value stream for your release and seeing where are my features, what is the state, and how many of my features have been rolled out to all of my users.

 The next is common governance and control, you need to be able to control your feature flags as part of your CD pipeline.

 So you need to be able to change values of individual features automatically through

 the pipeline in each stage, update who the features are targeting, and then control feature flags with access controls and change permissions on top of it.

 So you should be able to control who can update feature flags from your CD pipeline, and also have feature flags be gates to you know, check the feature flag status and have that as a gate before you progress in your CD pipeline as well.

 All of that activity related to your feature flags should be part of your audit trail for your pipeline run, so you can go back and look at exactly what happened in your deployment, as well as how your features were rolled out across your users.

 And then the next step of this is creating some smart automation on top of your CD pipeline with feature flags.

 So you want to be able to define feature release templates that can be used and reused across features and pipelines, where you can decide whether it’s a percentage based rollout or a ring based rollout where you’re starting small and growing from internal employees to beta to GA users.

 So define your templates and then use them across your pipelines and then as you should have in your CD pipelines, orchestrating your tools and collecting the responses of your APM tools or your user management data or other tests that are being run and correlate that with feature flags, so that you can define roll out and rollback policies based on the results.

 So if your user testing resulted with, you know, you can put gates in place that look at the results of your user testing, where if you you know, missed it by 5%, you don’t go on to the next stage of rolling out your features.

 So you can put the checks in place, then decide whether to continue to roll out of your feature or flip off the feature altogether in your pipeline.

 And then finally, you know, as with any change with DevOps and your practices, there is an organizational process and culture shift involved and this should not be taken lightly.

 There are changes that you have to think about across your org and people need to

 change their thinking and mindset as well.

 Where you need to get comfortable with the fact that you’ll be you may be releasing incomplete code into production and have trust that the feature flags are controlling what is actually being exposed.

 The production application version may not be the single source of truth anymore.

 Right? You have to look at the state of your flags in production to know what

 is actually there and usable by your users.

 And then you need to introduce new processes, your testing and production you need The process behind that, what is the feedback or revision process that you’re putting in place for testing in production, who in the org is now releasing features, this ownership is changing, as I mentioned before, so you want to understand that and start changing this ownership of release beyond your deployment.

 And then feature flags should be managed as you start introducing feature flags over releases to many features, you need to make sure that you have a way of managing them.

 Otherwise, you’re going to create technical debt in your code.

 So this is a journey to get to this practice of progressive delivery, you want to make sure you have your fundamentals of CI\CD and feature flags.

 There should be integration across this.

 And then with that integration, you will get common visibility, common governance, smart automation, and ultimately achieve enterprise progressive delivery with the process and culture shift part of that entire process. So thank you so much for your time today. And, you know, well, I welcome any questions. Thank you.

 So let’s move into how feature flags and continuous delivery help you to reach progressive delivery.

 So where can continuous delivery as we know it, today, traditionally, fall short?

 Organizations can be doing continuous delivery really well.

 But there are still limitations to this approach, you might be increasing your velocity and shipping new capabilities more often to your users but this also introduces risk with this shortening cycle.

 Everything that you’re delivering to production, to your users needs to be user ready.

 So if there are issues that come up post deployment, the entire version needs to be rolled back or forward.

 So you need to have a lot of diligence pre production, so you feel confident in that, otherwise it can, you know, trigger a whole rollback of your version.

 The majority of the testing in CD, though, is done pre production, where you may be missing some of the real world factors in your production environment, it’s very difficult to, you know, have a pre production environment with all of the factors that might be in your production environment.

 And more importantly, you’re not also able to test and respond to feedback from real users.

 So this can introduce surprises that you’re not ready for when you deploy to production. And then again, you have to respond with full rollbacks.

 With traditional CD, it’s very difficult to have control over that blast radius, or who is seeing your new capabilities in your new version.

 You don’t have focused control over the users who it’s exposed to and you also don’t have the ability to roll out features to specific customers and then rolling out and rolling back gradually becomes much more complex.

 So let’s take a step back and look at how progressive delivery might work in a traditional release with Canary releases.

 So you can deliver progressively to environments using Canary deployments and this does limit exposure, and you can test in production when new code is deployed.

 The control in this case is in the infrastructure networking layer.

 So this is how you’re controlling the users that are getting access to your new version, we select in the diagram, you can see that we’re selecting a small percentage of users that are routed to the servers where version two has been deployed.

 Over time you roll out the version two to more and more servers and route more users to version two until all of your users are on version two.

 This approach does allow testing features with small groups of users in your production environments, which is great, you’re able to get that testing done.

 But there are a lot of challenges.

 The ops team has to stay involved in the whole process and that can be complex to control.

 There are, you know, limited mes methods for targeting which users to test a new feature on, you don’t have the control and all of the inputs of the types of users who you’re exposing this to with, you know, the control we have in the networking layer.

 The feedback loop becomes harder as most deployments of a new version may contain many changes, right?

 It’s not just a single feature that’s being deployed and exposed through this, but a whole

 version of your software. So you may get feedback on a specific feature, but you have to still respond at the full version level. So rollback is at that granularity where the entire version must be rolled back when there are issues or negative feedback on a given feature.

 So now let’s see how progressive delivery for users with feature flags can work.

 And in this case, the canary deployments with feature flags.

 The control lives in the application layer and that allows you to limit exposure of which

 users see a new change, whether it’s internal testers, beta users or a percentage based rollout.

 You have a lot of control over the cohorts of users who are starting to get to see new features.

 And then you can progressively increase that blast radius and help you move forward through that rollout with confidence with each new incremental step.

 So in this case, with the diagram, you can see that with feature flags, the new version is deployed into your environment.

 So version two is deployed in that middle box but the features themselves are only exposed to a small subset of users to start with.

 So here’s where the product team after the ops team has done the deployment just once, now the product team can take over and progressively start to turn on new features for users, and use a highly selective criteria that’s all within their control.

 Then over time, as the feature gets positive feedback, the feature can progressively be turned on for all users over time.

 So this is great. This means that organizations now are changing their focus from a full product release mindset to a feature focus.

 And features are no longer bound by the release as a whole, which really changes the game and we’ll get to see that a little bit more in our next example, as well.

 A few things that you do need to be aware of is, if you don’t know whether a feature flag will be turned on or off in production, you need to look at testing both states.

 You don’t always have to test all configurations but you have to think about what are the configurations of feature flags you want to test before you get into production.

 Another thing you have to think about is the process and culture changes that come along with this as new team members are going to have different responsibilities, rather than ops owning, you know, deployment and post deployment, you’re going to bring back the development and product teams into this post deployment rollout of features.

 So let’s take this a step further and break down what or release versus feature granularity and control really means in a whole release.

 So we’ll walk through this release, where we have four new features that are being introduced and what are the differences with these two approaches.

 So in the top row, we have our traditional CD process, where we have this release where all of the features are included and released together, features one through four.

 And most companies are operating with this model today where the orchestration is that the release version level where the entire release can get delayed and halted if there are issues with any one feature that’s being delivered.

 So in this case, we have four stages and in the testing stage, you see that after commit

 and build are completed, we find that feature three has more bugs than we can handle and we now have to delete the entire release in order to fix those bugs.

 So once those bugs are fixed, then you can start again and get into your deployment and release phase.

 In that phase, all four features are released to all of our users in our production environment and after the release is complete, we find out that feature four is not working as users expected and we need to fix it.

 And so rather than being able to just look at feature four, now we have to roll back the entire release to remediate the issue.

 So we’re rolling back the version and we wait for feature four to be fixed before a new version goes to this whole process and is redeployed into production.

 So users don’t get to use any of the new features until all of them are ready, and in a good state and there is rollback of versions and delays and release included in this process.

 So now let’s look at the bottom row where we’re having a release with feature granularity.

 So, again, we have four features that go through commit and build.

 And again, in the testing phase, we still see the same issue with feature three.

 And instead of having unanticipated delays in the whole release, we are able to just use a feature flag, turn off feature three, and continue into our deployment.

 So now in our code deploy phase, feature three is turned off, the other three features are enabled and we start to progressively deliver and roll out the other three features to users with only a small subset of users seeing those features to start.

 We again find out that feature four is not accepted well, but it’s only exposed to a small set of users who saw the feature before we’re able to respond and just turn off that feature in production.

 Again, we’re not rolling back the whole release.

 It’s a simple toggle on that feature and features one and two are still in production and can be continued to be rolled out to the rest of users, while feature three and feature four are being developed and you know, will be deployed at a later time.

 So what you’re able to do here is add… using feature flags with progressive delivery, you have more flexibility and agility in your release to respond to issues at a feature level with that level of granularity.

 In your rollout and rollback of features, so you’re able to respond to your users without causing delays and rollbacks that can introduce risk into your whole process.

 So feature flags can create a much improved release velocity, because they’re breaking up the dependencies of a release being orchestrated.

 Rather than being orchestrated all at once, you’re looking at a collection of features that you’re able to control.

 So this means that a group of features doesn’t hold up the release just because one is buggy.

 You are able to maintain your release consistency, and velocity because nothing is causing a rollback or things… bugs that need to be fixed.

 You’re also able to limit exposure of incomplete or buggy features, you can turn them, you know, narrow it down to its only internal developers who are able to see that feature and continue to work on that feature as well.

 So going in a little bit more of this comparison of traditional CD versus CD with feature flags.

 Traditionally, you’re focused on the tactical delivery of bits, but as you get with feature flags, you can focus on delivering features and get to that next level of maturity within the organization.

 Rather than looking at environments and the state of environments, what versions are there, you’re focusing on your customers and what features that they are able to use in your product.

 Your testing is shifting, right where you’re testing in production with your real users.

 You are able to test with users with focused granularity on what are the characteristics of those users.

 Independent features can now be rolled out or back without impacting users, because you’re not having any downtime with a rollback or upgrade of versions.

 And then deploying code to production is, now you don’t have a dependency between the business needs and the development and needs because you can deploy and then as your business dictates roll out features when you want to.

 So now that we’ve talked about progressive delivery, and gone through some examples, I want to walk through some of the top considerations to get your enterprise working with progressive delivery.

 So the question that you want to ask yourself is what would be the easiest way to test and learn in production on really users, and you want to be able to easily control which users get to see new features, what user attributes, easily be able to respond to things and rollback changes when needed.

 So you think, you know, you could do this on a one off maybe with feature flagging, but how do you get to this place and turn it into a practice where you’re able to test on users

 in a repeatable and automated way.

 So let’s talk about how we can get there.

 The fundamentals, you will need continuous integration.

 So you want to be practicing CI at some maturity level where your developers should merge their changes as often as possible into the main branch and you have CI processes that are automated that are triggered.

 Continuous delivery, you again need to have some maturity in your CD processes with automation that is in place.

 So when you are able to get your code into production, it’s not a manual fire drill, there is a pipeline that is orchestrating or pushing your code to production.

 There may be manual stops along the way, but you have a process behind it.

 And again, it is continuous delivery, we… there’s a misconception that you need to have continuous deployment to get to progressive delivery but when you’re able to introduce feature flagging with continuous delivery, you can achieve progressive delivery as a practice.

 So that’s the third bullet, you need some level of feature flag capabilities that allow

 you to control the rollout of features, with user attributes.

 And then all of this together CI\CD, and feature flags come together to become this integrated backbone that drives progressive delivery.

 So how do you do this? What do you need?

 Number one is common visibility of feature flags, you want your feature flags, and should be an input to your release, where you can see the payload of features that are part of your release that’s being delivered?

 You want awareness into what features are gating your environments

 and visibility for a given environment In your release?

 What feature flags are present? What is the current state have all of those feature flags you get visibility across the pipeline?

 And then what is the release criteria?

 What are the gates? What do you need to meet in order for your release to be complete, but you see on the right is a high level view, one of the visuals that is helpful is looking across your value stream for your release and seeing where are my features, what is the state, and how many of my features have been rolled out to all of my users.

 The next is common governance and control, you need to be able to control your feature flags as part of your CD pipeline.

 So you need to be able to change values of individual features automatically through the pipeline in each stage, update who the features are targeting, and then control feature flags with access controls and change permissions on top of it.

 So you should be able to control who can update feature flags from your CD pipeline, and also have feature flags be gates to you know, check the feature flag status and have that as a gate before you progress in your CD pipeline as well.

 All of that activity related to your feature flags should be part of your audit trail for your pipeline run, so you can go back and look at exactly what happened in your deployment, as well as how your features were rolled out across your users.

 And then the next step of this is creating some smart automation on top of your CD pipeline with feature flags.

 So you want to be able to define feature release templates that can be used and reused across features and pipelines, where you can decide whether it’s a percentage based rollout or a ring based rollout where you’re starting small and growing from internal employees to beta to GA users.

 So define your templates and then use them across your pipelines and then as you should have in your CD pipelines, orchestrating your tools and collecting the responses of your APM tools or your user management data or other tests that are being run and correlate that with feature flags, so that you can define roll out and rollback policies based on the results.

 So if your user testing resulted with, you know, you can put gates in place that look at the results of your user testing, where if you you know, missed it by 5%, you don’t go on to the next stage of rolling out your features.

 So you can put the checks in place, then decide whether to continue to roll out of your feature or flip off the feature altogether in your pipeline.

 And then finally, you know, as with any change with DevOps and your practices, there is an organizational process and culture shift involved and this should not be taken lightly.

 There are changes that you have to think about across your org and people need to

 change their thinking and mindset as well.

 Where you need to get comfortable with the fact that you’ll be you may be releasing incomplete code into production and have trust that the feature flags are controlling what is actually being exposed.

 The production application version may not be the single source of truth anymore.

 Right? You have to look at the state of your flags in production to know what

 is actually there and usable by your users.

 And then you need to introduce new processes, your testing and production you need The process behind that, what is the feedback or revision process that you’re putting in place for testing in production, who in the org is now releasing features, this ownership is changing, as I mentioned before, so you want to understand that and start changing this ownership of release beyond your deployment.

 And then feature flags should be managed as you start introducing feature flags over releases to many features, you need to make sure that you have a way of managing them.

 Otherwise, you’re going to create technical debt in your code.

 So this is a journey to get to this practice of progressive delivery, you want to make sure you have your fundamentals of CI\CD and feature flags.

 There should be integration across this.

 And then with that integration, you will get common visibility, common governance, smart automation, and ultimately achieve enterprise progressive delivery with the process and culture shift part of that entire process.

 So thank you so much for your time today.

 And, you know, I welcome any questions. Thank you.