Deployment - knowlesy/AZ400 GitHub Wiki

Microservice architecture is undoubtedly not a prerequisite for Continuous Delivery, but smaller software components help implement a fully automated pipeline.

Testing in production sounds a bit scary, but that shouldn't be the case.

When we talked about separating our functional and technical releases, we already saw that it's possible to deploy features without exposing them to all users.

When we take this concept of feature toggling and use it with our deployment patterns, we can test our software in production.

For example:

• Blue-green deployments.
• Canary releases.
• Dark launching.
• A/B testing.
• Progressive exposure or ring-based deployment.
• Feature toggles.

Blue-green deployment is a technique that reduces risk and downtime by running two identical environments. These environments are called blue and green.

Feature Flags

Feature Flags allow you to change how our system works without making significant changes to the code. Only a small configuration change is required. In many cases, it will also only be for a few users.

The other type of Feature Flag is a Release Flag. Now, imagine that after you complete the work on the interest calculation code, you're nervous about publishing a new code out to all users at once.

You have a group of users who are better at dealing with new code and issues if they arise, and these people are often called Canaries.

The name is based on the old use of the Canaries in coal mines.

Feature toggles are also known as feature flippers, feature flags, feature switches, conditional features, and so on.

Besides the power they give you on the business side, they also provide an advantage on the development side.

Feature toggles are a great alternative to branching as well. Branching is what we do in our version control system.

A feature toggle is just code. And to be more specific, conditional code. It adds complexity to the code and increases the technical debt.

The idea of a toggle is that it's short-lived and only stays in the software when it's necessary to release it to the customers.

As soon as you introduce a feature flag, you've added to your overall technical debt.

Canary releasing

Canary releasing can work many ways, but essentially you only release a new version or functionality to a small set of customers to start. You then monitor your system and the customers' responses to see if anything...weird...happens. The odd name for this deployment comes from coal miners lowering canaries into the shafts to detect noxious gases so they can see if it's safe before they descend themselves.

Canary releases can be implemented using a combination of feature toggles, traffic routing, and deployment slots.

Dark launching is in many ways like canary releases.

The idea is that rather than launch a new feature for all users, you instead release it to a small set of users.

Usually, these users aren't aware they're being used as test users for the new feature, and often you don't even highlight the new feature to them, as such the term "Dark" launching.

SpaceX builds and launches rockets to launch satellites. SpaceX also uses dark launching.

When they have a new version of a sensor, they install it alongside the old one.

All data is measured and gathered both by the old and the new sensor.

Afterward, they compare the outcomes of both sensors.

Only when the new one has the same or improved results the old sensor is replaced.

A/B testing

A/B testing (also known as split testing or bucket testing) compares two versions of a web page or app against each other to determine which one does better.

With A/B testing , implementation is similar to the process of canary releasing. You have a baseline feature, the "A" feature, and then you deploy or release a "B" feature. You then use monitoring or instrumentation to observe the results of the feature release. Hopefully, this will reveal whether or not you achieved what you wanted.

CI-CD with deployment rings Progressive exposure deployment, also called ring-based deployment, Impact (also called blast radius) is evaluated through observation, testing, analysis of telemetry, and user feedback.

In DevOps, rings are typically modeled as stages. By using post-deployment release gates that check a ring for health, you can define an automatic propagation to the next ring after everything is stable.

When a ring isn't healthy, you can halt the deployment to the following rings to reduce the impact.

Gates

https://learn.microsoft.com/en-us/azure/devops/pipelines/release/approvals/gates?view=azure-devops

• Incident management: Ensure certain criteria are met before proceeding with deployment. For example, ensure deployment occurs only if no priority zero bugs exist.
• Seek approvals: Notify external users such as legal departments, auditors, or IT managers about a deployment by integrating with other services such as Microsoft Teams or Slack and wait for their approvals.
• Quality validation: Query pipeline metrics such as pass rate or code coverage and deploy only if they are within a predefined threshold.
• Security scan: Perform security checks such as artifacts scanning, code signing, and policy checking. A deployment gate might initiate the scan and wait for it to complete, or just check for completion.
• User experience relative to baseline: Using product telemetry, ensure the user experience hasn't regressed from the baseline state. The user experience metrics before the deployment could be used as baseline.
• Change management: Wait for change management procedures in a system such as ServiceNow to complete before proceeding with deployment.
• Infrastructure health: Execute monitoring and validate the infrastructure against compliance rules after deployment, or wait for healthy resource utilization and a positive security report.