Home / IT & Computer Science / Cloud Computing / Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline / Progressive Exposure
Progressive Exposure
Progressive Exposure is the process of slowly deploying to select sections rather than universally, a means of testing
Progressive exposure is one of the important practises in DevOps. The idea of progressive exposure is that, unlike in the past when a new deployment would instantly become available to everyone, we want to minimise the blast radius. We want to allow the new deployment to go live, but to go live in a contained environment, where only a few people have access in production. And then as we validate that new deployment, we have more, and more, and more people exposed. There are a few techniques for doing this. One is called bluegreen deployment. Bluegreen deployment means that I have my green deployment that’s running.
I introduce a blue deployment, and I gradually use the load balancer to bleed traffic to the blue deployment and then gradually retire the green deployment based on the telemetry I observe on the new blue deployment. That’s one way of doing it. Another way of doing it is to use a canary. A canary is a stage in the release deployment that lets you see what’s happening in production for a small group, and you use that as the quote “canary in the coal mine” to determine whether everything else should succeed. Now, the way we do deployment on Visual Studio Team Services is that we currently have 10 data centres. We group these into four rings.
The first ring, ring zero, we treat as our own canary. Let me show you what that looks like. I’m looking at a home screen on our own instance of Visual Studio Team Services that’s showing me down here the production update. As you can see, there’s an update going through right now that’s blue. That means in progress. There’s a previous update, 296, that went through all four rings. If I look up here, by the way, I can see the status of the CI builds, the continuous integration builds that are all running green recently, the status of signing, and so forth. But let’s drill into this production update 296 and see what its status was as it went through to production.
So it shows me that this succeeded across all four rings starting 22 hours ago to 16 hours ago for this one. It shows me the duration in each of them. It shows me what build it came, from which branch, created by whom, and shows me here the four work items that made it into this. This small batching of a deployment makes it really, really, really easy to see what’s where, so you can audit exactly what happened. You can determine if particular work is done. You have this record available forever. Now, let’s come back and take a broader look at how you see multiple release definitions across multiple deployments.
So let’s, for example, take this one, which happened 57 minutes ago on a definition called product configuration change. If I click into this, I can see exactly what steps happen in the build. I can see exactly what happened from ring to ring as this went out. And if I want to understand, again, what the work items were, I see here are the particular two that motivated this actual deployment instance for this particular release. And I can see we get, in this particular case, a movement across all 10 data centres in about seven minutes. That’s an example of the way we do progressive exposure. We start with ring zero very heavily instrumented. Ring zero is where we work.
Ring zero is our canary. It tells us how this is working for us. And then as we are happy, each release will go from ring zero to one to two to three. All of this lets me see from the canary to the other production environments what the succession is, and how healthy each of these releases is, and what exactly went into them. That’s how we do it for Visual Studio Team Services, and that’s how we use team services to manage our own releases.
Progressive exposure is one of the important practices in DevOps. In a nutshell, progressive exposure is the process of slowly deploying to select sections as a means of testing, rather than universally.
The idea of progressive exposure is that, unlike in the past, when a new deployment would instantly become available to everyone, we want to minimise the blast radius. We want to allow the new deployment to go live, but to go live in a contained environment, where only a few people have access in production, and then as we validate that new deployment, we have more and more and more people exposed.
Next, we will move on to our final topic which is continuous learning.
Join the discussion
What are some methods or metrics we could use to determine our pools for progressive exposure? Can you suggest some ways in which popular applications currently employ this tactic?Use the discussion section below and let us know your thoughts. Try to respond to at least one other post and once you’re happy with your contribution, click the Mark as complete button to check the step off, then you can move to the next step.
This article is from the online course:
Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline
Created by
This article is from the free online
Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline
Reach your personal and professional goals
Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.
Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.
