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.