Configuring an Environment Release Policy
Creating a Policy
You can add atomic extensions and edit release policies based on the preset RollingUpgrade, GrayscaleUpgrade, or EmptyYamlTemplate templates.
- Access the environment list page.
- Click an environment name.
- On the displayed page, click the Release Policy tab.
- Click next to Custom Policies, on the displayed dialog box, select a policy template and click OK.
- Orchestrate extensions based on the selected template.
Table 1 Policy parameters Parameter
Description
Policy
Policy name. Enter only letters, digits, underscores (_), and hyphens (-) with a maximum of 128 characters.
Description
Enter a description with no more than 200 characters.
Orchestrating an extension
Set orchestration parameters by referring to Configuring Atomic Extensions.
- Click to add an extension.
- Click to clone an extension.
- Click to delete an extension.
- Click Save after the configuration.
- Find the created policy on the left and click to apply it. The applied policy will be marked as Default.
Configuring Atomic Extensions
CodeArts Release provides the following five extensions (Rolling upgrade, Start workload, Divert traffic, Remove old version, and Manual check) for rolling upgrade and grayscale upgrade:
- Rolling upgrade
Rolling upgrade supports image upgrade and YAML deployment.
- Image upgrade: Replace the container image in the workload.
Table 2 Parameter description Parameter
Description
Namespace
Namespace to which the service to be upgraded belongs.
Workload
Workload in the namespace.
Container
Container to be upgraded in the workload.
- YAML deployment: Use the YAML file to deploy or upgrade the workload.
Table 3 Parameter description Parameter
Description
Repo Type
Repository type. Only Repo is supported.
Repository
Code repository of the current project.
Branch
Branch of a code repository.
YAML Path of Workload
YAML path of the workload to be upgraded. Enter a relative path of the YAML file.
- The current directory is the root directory of the code branch.
- Only one YAML file is supported.
- You can use ${variable name} in a YAML path to reference an environment variable, and {{variable name}} in a YAML file to reference an environment variable.
- Image upgrade: Replace the container image in the workload.
- Start workload
Start workload supports image upgrade and YAML deployment.
- Image upgrade: Upgrade a workload by replacing the container image with a new one, ensuring it has the same configurations as the currently running packages without changing anything else.
Table 4 Parameter description Parameter
Description
Namespace
Namespace to which the service to be upgraded belongs.
Service
The service to be upgraded, which is associated with only one workload.
Grayscale Version
Disabled: The system automatically generates a grayscale version number. Enabled: You can configure a grayscale version number as needed.
Grayscale Version Number
The grayscale version number is used to distinguish the official version from the grayscale version. You can use ${ENV} to reference environment variables. For example, ${TIMESTAMP} indicates that the system timestamp variable is referenced as the gray version number.
Enter only letters, digits, and underscores (_) with a maximum of 62 characters.
- YAML deployment: Use the YAML file to deploy or upgrade the workload.
Table 5 Parameter description Parameter
Description
Namespace
Namespace to which the service to be upgraded belongs.
Service
The service to be upgraded, which is associated with only one workload.
Repo Type
Repository type. Only Repo is supported.
Repository
Code repository of the current project.
Branch
Branch of a code repository.
YAML Path of Workload
Relative path of the YAML file.
- The current directory is the root directory of the code branch.
- Only one YAML file is supported.
- You can use ${variable name} in a YAML path to reference an environment variable, and {{variable name}} in a YAML file to reference an environment variable.
- Image upgrade: Upgrade a workload by replacing the container image with a new one, ensuring it has the same configurations as the currently running packages without changing anything else.
- Divert traffic
Traffic diversion includes:
- Service blue-green release: All traffic will be switched to the new workload (gray load).
- ASM grayscale release: Use ASM (Application Services Mesh) VirtualService and DestinationRule configurations to control access traffic, perform grayscale diversion based on traffic proportion and request headers. ASM must be installed in the cluster.
- Remove old version
This extension automatically removes the old workload associated with the service. No configurations are required.
- Manual check
With this extension, you can approve or reject the deployment policy when the pipeline pauses at a checkpoint, allowing the pipeline to either continue running or to stop.
Table 6 Parameter description Parameter
Description
Timeout Processing
- Check failed and release flow terminated: Pipeline will pause at the checkpoint. If the policy is not approved within the specified period, the pipeline will stop.
- Check result ignored and release flow continues: Pipeline will pause at the checkpoint. If the policy is not approved within the specified period, the pipeline will continue to run.
Check Duration
Time window for checking, which ranges from one minute to 12 hours.
Description
Description of the manual check. Enter no more than 200 characters.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot