In application release and product iteration, batch release is often used to control release risks.


Batch release is the process in which only certain instances of an application are upgraded based on batches. If an error occurs during batch release, you can terminate the upgrade process and roll back the instances. You can deploy the new version of the application to the instances again after the error is fixed.

When an application is released in batches in a Container Service Kubernetes cluster, the instances of the application are evenly distributed to each batch for deployment. If the instances cannot be evenly distributed, a small number of instances are allocated for the first batches, and a large number of instances are allocated for the remaining batches.


An application contains 10 instances. The deployed application version of each instance is V1. Now, the application in each instance needs to be upgraded to V2.

Assume that the new version of the application is released in all the instances in three batches. The following figure shows the release process based on the batch release policy.


  • When you use batch release for an application in a Container Service Kubernetes cluster, you need to create a Deployment.
  • However, do not use batch release if the application contains the following native features or configurations:
    • Horizontal Pod Autoscaler (HPA)
    • Rancher
    • Istio
    • Features and configurations that are dependent on Deployment.Metadata.Name or Deployment.Metadata.Uid


  1. Log on to the EDAS console.
  2. In the left-side navigation pane, choose Application Management > Applications.
  3. On the Applications page, select a region and Namespaces and then click the name of the target application.
  4. On the Application Details page, click Deploy Application in the upper-right corner.
  5. On the Deployment Mode Selection page, click Start Deployment in the Batch Release section.
  6. On the Batch Release page, upload the application deployment package of the new version.
    • WAR and JAR

      WAR and JAR packages differ only in the deployment method, but have the same parameters.

    • Images

      You only need to select a new image version and do not need to set other parameters.

  7. Set Release Strategy.

    Parameter description:

    • Release Batch: the number of batches for releasing the new version of the application in the remaining instances after the canary release is completed.
    • Batch Mode: the mode for releasing the new version of the application in the remaining instances. Valid values are Automatic and Manual.
      • Automatic: automatically release in batches according to Interval. Interval: the release interval for the remaining batches. Unit: minute.
      • Manual: manually triggers the release of the next batch.
    • Batch in Deployment Interval: the deployment interval (unit: second) between application instances if the number of application instances is greater than one in each batch.
  8. Optional:You can determine whether to configure Startup Command, Environment Variables, Persistent Storage, Local Storage, Application Life Cycle Management, and Log Collection Settings based on your requirements.
  9. After you set the parameters, click OK.

Verify the result

Go to the Application Details page to view the status of batch release. If all batches are successfully released, the batch release is successful.

On the Application Details page, view the instance deployment information. When the instance version is V2 and the status of all instances is Running, the release is successful.

Roll back an application

During a batch release, if at least one application instance is not upgraded to the new version, the release is considered in progress. When monitoring an upgrade, if you notice that any application instance in the first batch stops responding, you can go to the Change Details page and click Roll Back Immediately to roll back the released instance to the previous service package and configuration.

If an exception occurs during batch release, see How do I resolve problems in a change process? for troubleshooting.
  • Exceptions such as unavailable deployment package or health check failure may lead to failures of application upgrades. The current application changes are automatically terminated and the application is rolled back.
  • During the upgrade, the maximum timeout period for a single batch is 30 minutes. If the change process is suspended due to timeout, you must go to the Change Details page to manually terminate the release process and roll back the application.