Implementing Continuous Delivery
The course is part of these learning paths
This course deals with how to implement continuous delivery with the Azure DevOps solution. In particular, we will be exploring how to design different release strategies and some factors you need to consider while setting up release pipelines. This will include looking at release triggers, release gates, and other areas associated with releasing code, including working with different environments. We will also take a look at deployment patterns and how they can be implemented in your release strategy and release pipelines. During this course, we will be using hands-on examples to help work through these concepts and configurations.
If you have any feedback for us about this course, please contact Cloud Academy at firstname.lastname@example.org.
- Design a release strategy
- Set up a release management workflow using Azure DevOps
- Implement an appropriate deployment pattern
- DevOps engineers
- People preparing for Microsoft’s AZ-400 exam
- General knowledge of Azure
- Experience with Git version control, including pushing changes into repositories
- You do not need to know any specific development language
A deployment pattern refers to the process which you move an application, or piece of code, into production. Traditional methods used to involve large changes, less often. In the past two decades, the speed of IT has given rise to a business that needs to be more agile and respond fast to customer needs. This means they need to be able to handle changes and push out changes in infrastructure and applications faster. Organizations are learning to incorporate change on a regular basis—monthly, weekly, daily or even hourly—into their business. In this last section, we're going to review some modern deployment patterns.
We have all likely heard of environment names such as dev, test, dev/test, QA, pre-prod, and production. Depending on the size of your budget, you can see more or less of these environments. A common problem with these in the past has been keeping these environments consistent. Often, they are used for many different purposes, testing different technologies and applications all in one place. This can lead to configuration drift, making it harder to guarantee that testing in one environment is a true representation of what will happen moving into the next environment.
As application development has changed, the way we deploy and test applications has also changed: being able to utilize platforms as service, or PaaS, also the advent of containers, even through to infrastructure as code. All these types of things can be versioned and related to artifacts and stored and released using agile-related deployment patterns. Let's have a look at some of these modern patterns.
Blue-green deployment is a technique that can reduce downtime and risk by running two identical production environments called Blue and Green. At any one time, only one environment is live, with the live environment serving all the production traffic. Often, a router is used to redirect the traffic. Code is released to the Blue environment and traffic is redirected from Green to Blue. This can allow you to ensure the new environment is truly running before flipping the switch to redirect the traffic without interrupting the user's experience. It also has the advantage that if you need to roll back the change you can redirect the traffic back to the last known good deployment very easily.
A canary release means that most users will continue to use the known good application (in this case, v1). A small number of users are given access, or are redirected, to a new version of the application (in this case, v1.1). There are various ways you can filter these users to the canary release, through the user login IDs, a cookie, source IP address. The method itself will be dependent on the type of application and how you are filtering these users through. The impact of the change is small and if there are any issues, changes can be reversed or corrected quickly with minimal impact to the larger user base.
The next pattern has a couple of different names: feature toggles, feature flag or feature switch. It is the concept of adding a flag to a feature so that it can be enabled, or disabled, to a specific user or group of users, in the backend or frontend of the application. This allows a feature to be tested even before it is completed and ready for release. Feature toggles are used to hide, enable, or disable the feature. If we consider Azure itself, you may have seen video or demonstrations of Azure private preview features. Microsoft often invites people, or companies, into these preview groups before a feature goes GA. This allows them to test and work to refine that feature with a customer before it goes live.
Progressive exposure deployment is where new software is exposed to a subset of users that gets extended gradually over time. A conceptual illustration here shows the inner circle called canaries, followed by early adopters, and finally, the users sphere representing the remaining user base. This is often referred to as the impact, or blast radius, where the release is evaluated and observed before exposing them to more users. One of the terms that is often used in DevOps and Agile processes is, "Fail early and fail fast." What this means is the sooner we know there is an issue, the sooner we can correct it. However, with some of these programs, they are so large that testing every aspect of a system is virtually impossible.
An example of this is Windows as a service. Windows has millions and millions of lines of code. Microsoft relies on their user base and customers to implement and test these new features against existing systems to make sure they continue to function as expected. We can see how the impact on the user base is affected over time. An advantage of this method is that users know they are in an early adoption program and they are often looking for, or expecting to see, issues.
A/B testing, also known as split testing or bucket testing, is a method of comparing two versions of a webpage, or app, against each other to determine which one performs better. A/B testing is mostly an experiment where two or more variants of a page are shown to users at random, and statistical analysis is used to determine which variant performs better for the given conversion goal. Imagine a shopping network testing a new checkout page to encourage users to complete their purchase. You can analyze the percentage of users that used version A of the website and purchased their items in the shopping cart, versus version B.
Dark launching is the process of releasing production-ready features and released to a subset of users gradually, in order to get the user feedback, or test the application or infrastructure performance. Features are wrapped in a way where they can be toggled which is used to control who gets the new features and when. Dark launching is a popular method to test new features gradually, by releasing them to small groups of users over time. This way, they can see how users respond to the changes and make adjustments before continuing. They're called dark launches because these changes typically aren't publicly announced. These changes are released gradually to 1%, 5% 20%, and so on. If there are any issues with these new features, the existing systems are still in place and it's easy to roll back the change to fix the problem.
Matthew Quickenden is a motivated Infrastructure Consultant with over 20 years of industry experience supporting Microsoft systems and other Microsoft products and solutions. He works as a technical delivery lead managing resources, understanding and translating customer requirements and expectations into architecture, and building technical solutions. In recent years, Matthew has been focused on helping businesses consume and utilize cloud technologies with a focus on leveraging automation to rapidly deploy and manage cloud resources at scale.