Search…
Vamp Concepts
Using Vamp Cloud
Release Agent
Integrations
Step 3: Choose a Release Policy
A release policy is a set of rules that defines how a version of a service should be validated when it is added to an application.
The next step is to set the release policies for your service.
What is a Vamp Release Policy?
When a new version of your service is deployed for an application, a release policy is applied to determine whether the new version should replace the current, live version of the service.
The policy conditions are evaluated every 30 seconds by the Vamp Release Agent running in the application namespace on your Kubernetes cluster. The Release Agent uses data from Kubernetes and your chosen Ingress controller, plus any custom metrics that are part of the release policy.
Each release policy includes at least one step. At the start of each step, a percentage of users are exposed to the new version, and the Release Agent monitors the performance of that new version. If the policy conditions are not met, the new version is rolled back with minimal impact on your users' experience.
Rollbacks
If the new version of a service does not meet all the conditions described by the release policy, Vamp immediately switches all users back to the current, live version.
A rollback takes 30-60 seconds.
Blue/Green Release
A blue/green release mimics a traditional approach to releasing monolithic applications that uses two identical environments called blue and green. The current, live version is blue. The new version is green.
A blue/green release policy includes only one step that targets all your users. At the start of the step, all users are switched from the live blue version to the new green version.
The Release Agent monitors the performance of the new version. If everything goes well, the policy completes with the green version becoming the live version.
If the new version does not meet all the conditions described in the release policy, the Release Agent immediately rolls back by switching all users to the blue version.
Canary Release
A canary release takes its name from the old mining practice of using canary birds to test for poisonous gasses underground. A canary release uses a subset of users to identify any issues before a new version is rolled out to all users.
A canary release policy typically includes three or more steps that progressively target larger subsets of users. A step can target a percentage of your users, or it can target a specific user segment.
The Release Agent monitors the performance of the new version. If everything goes well, the policy completes with all users receiving the new version.
If the new version does not meet all the conditions specified in the release policy, the Release Agent immediately rolls back by switching all users to the current, live version.
Default Policy
You are prompted to choose the default policy for each of your services.
A good default release policy balances the need to quickly validate emergency releases with the need to validate new features over a longer period, using a wider range of metrics.
When you choose a policy from the list, the summary shows you which metrics that policy uses to validate a release, and the policy's duration.
Vamp Health
Every policy includes the Vamp Health SLO (service level objective), which protects your users' overall experience. The minimum Vamp Health level is 70%.
Metrics
This is a list of all the other SLOs the Vamp Release Agent monitors, in addition to Vamp Health. A typical policy monitors at least four SLOs, plus Vamp Health.
All policies must include SLOs for Vamp Health and for Kubernetes Pod restarts.
Duration
Every policy has a maximum duration. If the policy uses only fixed duration steps, a successful release will always take the full duration to complete.
If one or more of the steps in the policy is based on receiving a minimum number of requests, a successful release may be completed more quickly than the maximum duration.
A failed release ends as soon as any of the policy conditions are not met.
Advanced
The default policy is used when there is no specific policy set for major, minor or patch releases. If you select the Advanced option, you can set specific policies for major, minor and patch releases.
Major Release
A major release is a feature release that introduces one or more breaking changes, for example, deprecating an API endpoint.
For major releases, you usually want to use a longer running policy that validates a mix of technical and business metrics.
Vamp uses the major release policy if the new version is at least one major version higher than the version that is currently live. For example, a change of semantic version from
1.2.3 to 2.0.1 is a major release.Minor Release
A minor release is a feature release that introduces new functionality without changing any of the existing functionality, for example, adding a API endpoint.
For minor releases, you usually want to use a shorter running policy that validates a mix of technical and business metrics.
Vamp uses the minor release policy if the new version is at least one minor version higher than the version that is currently live. For example, a change of semantic version from
1.2.3to 1.3.4 is a minor release.Patch Release
A patch release can be a planned maintenance release to fix bugs, or an update to the versions of software libraries. A patch release can also be an emergency release to quickly address critical security or performance issues. A patch release should not add or remove functionality.
For patch releases, you usually want to use a quick running policy that validates mostly technical metrics.
Vamp uses the patch release policy if the new version is at least one patch version higher than the version that is currently live. For example, a change of semantic version from
1.2.3 to 1.2.4 is a patch release.Attaching the Policy to the Service
Click the Next button to attach the policy or policies to your service, then move to the next step.
You will see a message indicating that the policy has been attached to the service.
Last modified 3mo ago