Continuous delivery mode

Use cases

You can configure a development process for an application to manage its delivery lifecycle through changes. This approach is typically used for build and release workflows that involve progressive promotion across multiple environments, providing strict control over the end-to-end continuous delivery process, from development and testing to production.

Configure the application development process

• Prerequisites: Follow the guidance on the application overview page to set up the application's code repository, deployment orchestration, and environment plan.

• Navigate to Application > Application Settings > Development Process and click New Development Process. Enter a name for the development process, select a template, and click OK to create it. AppStack provides a standard development process template as an example, which includes development, testing, and production stages. You can also create custom development process templates in Global Settings. When you create a development process for an application, it is initialized from the selected template and can be further customized for specific scenarios.

  • Add a stage: Click the + card to add a new stage to the development process. For example, if your application requires a staging stage for final validation before release, you can create a new Staging Stage.

  • Edit a stage: Click the More Actions menu on an existing stage card to modify its name or label. For example, if your enterprise uses the name UAT Stage for the testing stage, you can rename it accordingly.

  • Delete a stage: Click the More Actions menu on an existing stage card to delete it. For example, if your application requires only development and production stages, you can delete the testing stage.

• You can create multiple development processes for each application for different release scenarios, such as a standard process for daily development and an emergency release process for hotfixes.

  In the New Development Process dialog box, enter Standard Development Process as the name, select the Java Kubernetes Application Standard Development Process Template (which includes a development stage (build→deployment), a testing stage (build→deployment), and a production stage (build→manual review→deployment)), and then click OK.

  On the development process configuration page, you can configure the change integration method for each stage (for example, choose to merge feature branches offline and specify a branch to run) and set admission rules (for example, require the previous stage to have completed successfully).

Edit the pipeline for a stage

• Each stage in a development process is associated with a pipeline that executes specific tasks. Click a stage card to edit its pipeline. A typical pipeline includes the following components:

  • Pipeline Source: Automatically populated with the current application's code source and default branch. This field cannot be modified.

  • Build: Used to build application artifacts. You can select a build task based on the application's programming language (such as Java or Python) and deployment type (such as Kubernetes deployment or host deployment). For a Java application with a Kubernetes deployment, select the Java image build task.

  • Deployment: Used to deploy to an AppStack application environment.

    • Environment: In the task step, select the target application environment for the deployment. For more information, see Environment Management.

    • Artifact: Configure the artifact to be deployed to this environment. Typically, you select the output from the previous build stage.

    • Custom Parameters: Set parameters for this deployment as needed. These parameters are determined by the application's orchestration configuration.

• You can also add other tasks, such as tests and manual reviews, as needed. After configuring the pipeline, click Save. When the development process reaches this stage, the associated pipeline runs.

• Alibaba Cloud DevOps example: The Java Kubernetes Application Standard Development Process Template includes a development stage, a testing stage, and a production stage. The development and testing stages each build and deploy the application image, while the production stage includes a manual review before deployment.

  The pipeline template is automatically divided into three stages: Pipeline Source (automatically injected with the application's code repository), Build (application image build), and Deployment (AppStack deployment). In the configuration panel for the deployment stage, select the target application (for example, yunxiao-demo) and environment (for example, dev), configure the artifact (image repository address), select the Automatically create deployment order checkbox, and set any necessary custom parameters (such as memory resource limits).

Configure the change integration method

• The change integration method defines how a change's feature branches are integrated into the release branch when a stage is run. The following three methods are supported:

  • Select any branch: When you select this option, you can choose any branch to run when executing this stage's pipeline. Feature branches must be manually merged into the target release branch offline. AppStack automatically calculates the changes involved in the run based on the target release branch's commit and updates the change metadata.

  • Manually select changes: When you select this option, you must manually select which changes to integrate when running this stage's pipeline. AppStack automatically merges the selected change branches into a system-generated release branch for the run and updates the metadata of the selected changes.

  • Run a fixed branch: When you select this option, the pipeline for this stage can only be run from a fixed branch. Feature branches must be manually merged into this fixed branch offline. AppStack automatically calculates the changes involved in the run based on the fixed branch's commit and updates the change metadata.

• Alibaba Cloud DevOps example: In the Java Kubernetes Application Standard Development Process Template, the development stage is set to Select any branch because development environments typically require flexibility to deploy any branch for self-testing. The testing stage is set to Manually select changes because testing environments need stability for integration testing and can be restricted to deploying only specific feature branches. The production stage is set to Run a fixed branch because production environments require strict control and must only be deployed from a specific release branch.

Configure admission rules

• Admission rules are the criteria that a change must meet to enter a stage. They are designed to block changes that do not meet release standards, ensuring a gradual promotion of business changes across environments to ensure secure production releases.

  • Select the stage you want to configure and enable the Admission Rules switch.

  • Click Add Admission Rule to add a new rule. You can set a rule to check if another stage completed successfully. Note: Avoid creating circular dependencies in your rules.

  • After configuring the admission rules, click Save. When the pipeline runs, it first checks whether all changes involved in the run meet the admission conditions.

• Alibaba Cloud DevOps example: In the Java Kubernetes Application Standard Development Process Template, the development stage has no admission rules. The testing stage requires the development stage to have completed successfully. The production stage requires both the development and testing stages to have completed successfully.

Create a change for development

After configuring the development process, you can create changes to implement business requirements. Typically, one business requirement or task corresponds to one change, which simplifies management and traceability.

Run the development process to release changes

Navigate to Application > Development Process. Run the pipeline for each stage to deploy the application, verifying it in each environment before releasing to production. Switch to a specific stage, click Run to execute the stage's pipeline, configure the parameters in the Run Configuration dialog box, and then start the run.

Run a stage pipeline

• Using the Alibaba Cloud DevOps example Java Kubernetes Application Standard Development Process, the pipeline run configurations for each stage are as follows:

  • Development Stage: Select any branch; no admission rules.

  • Testing Stage: Manually select changes; requires the development stage to have completed successfully.

  • Production Stage: Run a fixed branch; requires both the development and testing stages to have completed successfully.

  In the Run Configuration dialog box for the testing stage, the Added Integrated Changes section displays a table of changes to be integrated, including their names, branches, owners, and integration status. You can add changes by using the Add integrated change link or remove them by using the Delete button. After confirming, click Run.

  In the Run Configuration dialog box for the production stage, the run branch is fixed to an integration branch (such as master). The Admission Conditions section shows that both the development and testing stages must have completed successfully. If the conditions are met, click Run to trigger the production deployment.

View pipeline run details

• Using the Alibaba Cloud DevOps example Java Kubernetes Application Standard Development Process, the pipeline run details for each stage are as follows:

  • Development stage: Select any branch.

    • Change Manager: AppStack automatically adds a Change Manager step before the stage pipeline. This step handles change calculation and branch merging. When the change integration method is set to select any branch, the system automatically calculates the involved changes based on the code branch's commit.

    • The subsequent build and deployment steps are executed in order. You can view the build and deployment logs and click Deployment order details to check the deployment progress.

• Testing stage: Manually select changes; requires the development stage to have completed successfully.

  • Change Manager: Merges the selected feature branches for integration into a system-generated release branch.

  • Integrated change details: Displays the release branch and a list of changes, including their name, branch, status, commit ID, and owner.

  • Admission Rule Gate: Checks if the admission conditions for this stage are met. If not, it displays failure details, showing the expected and actual values of the change metadata.

  • The subsequent build and deployment steps are then executed.

• Production stage: Run a fixed branch; admission requires both the development and testing stages to have completed successfully.

Trace requirements with change sets

A change set coordinates the release of multiple related applications and changes, letting you track progress for an entire business requirement.

Create a change set

1. Navigate to Release Management > Change Sets and click New Change Set.

2. Enter a Change Set Name, add the changes to be coordinated by using Link changes, and specify an Owner.

3. Click OK to create the change set and return to the list.

Change set list

• Navigate to the Release Management > Change Sets list. By default, it shows change sets that are assigned to you and in progress. You can switch filters to view all change sets.

  • The list displays the change set name, creation time, owner, linked changes, and status.

  • Click a change set to go to its details page.

Change set details

• Navigate to the Release Management > Change Sets list, find the target change set, and click it to open the details page.

  • Basic Information: Displays the change set name, owner, creation time, last modifier, and last modification time.

  • Change List: Displays the changes linked to this change set, grouped by application. It shows the run metadata for each change in the development process, letting you track the status of each change.

  • Link more changes if they need to be released together.

  • Remove changes that do not meet the release standards.

  • Add members to the change set to collaborate on the release.

  • Close the change set when all associated changes have been released.