Configuring an Environment Release Policy

Creating a Policy

You can add atomic extensions and edit release policies based on the preset RollingUpgrade or GrayscaleUpgrade templates.

Log in to CodeArts.
Click a project name to access the project.
Choose CICD > Release to 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.
Enter the basic information and orchestrate extensions. For details, see Atomic Extensions.
Click Save after the configuration.
Find the created policy on the left and click to apply it. The applied policy will be marked as In-use.

Atomic Extensions

CodeArts Release provides the following five extensions 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 1** Parameter description
Parameter	Description
Namespace	Namespace to which the service to be upgraded belongs.
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.
Container	Container to be upgraded in the workload.

YAML deployment: Use the YAML file to deploy or upgrade the workload.

**Table 2** Parameter description
Parameter	Description
Repo Type	Type of the code repository.
Repository	The code repository configured in the microservice.
Branch	The branch configured in the microservice.
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.

Start workload

Start workload supports image upgrade and YAML deployment.

Image creation: Replace the container image in the workload, create a workload with the same online configuration, and update only the build product (image package).

**Table 3** Parameter description
Parameter	Description
Namespace	Namespace to which the service to be upgraded belongs.
Service	Service to be upgraded.
Grayscale Version	Enable the parameter.
Grayscale Version Number	The version number will be used as the traffic diversion identifier. Enter ${TIMESTAMP} to reference the system environment variable.

YAML deployment: Use the YAML file to deploy or upgrade the workload.

**Table 4** Parameter description
Parameter	Description
Namespace	Namespace to which the service to be upgraded belongs.
Service	The service in a cluster namespace. Only one workload must be associated with the service.
Repo Type	Type of the code repository.
Repository	The code repository configured in the microservice.
Branch	The branch configured in the microservice.
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.

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 takes down the old workload associated with the service. No configurations are required.

Manual check

You can approve or reject the deployment policy through manual check. If the policy is approved, the pipeline will continue to run. If the policy is rejected, the pipeline will stop.

**Table 5** Parameter description
Parameter	Description
Timeout Processing	Check failed and release flow terminated: Pipeline will pause before manual check. If the policy is not approved within the specified period, the pipeline will stop. Check result ignored and release flow continues: Pipeline will pause before manual check. If the policy is not approved within the specified period, the pipeline will continue to run.
Check Duration	The waiting time for check. The value ranges from 1 minute to 59 minutes and 59 seconds.
Description	(Optional) Enter a description.