Serverless Application Center provides basic pipeline capabilities, which allow editable and flexible execution of processes and help you publish code to serverless applications. This topic describes how to configure a pipeline and view the execution history of a pipeline in the Function Compute console.
Background information
Templates are provided in pipelines. A pipeline template can be associated with one application and one environment. Serverless Application Center provides GitOps and capabilities of native environment management based on pipelines.
- The quick configuration mode allows you to quickly create a default pipeline
- The advanced configuration mode allows you to configure the details of a pipeline.

Configure a pipeline
- Overall configuration
Configure the YAML file of the environment and DingTalk chatbot.
- Process configuration
Configure the features of specific processes, such as the build and deployment commands in the build and deployment processes.
Overall configuration

- Specify YAML: Configure the YAML file. The core module of pipelines in Serverless Application Center uses Serverless Devs. Therefore, the YAML file that you specify is the
s.yaml
file of Serverless Devs. The-t/--template
parameter in Serverless Devs is used to specify the file. For example, if you set the value of this parameter todemo.yaml
,-t demo.yaml
is added after the default Serverless Devs commands in subsequent pipeline configurations. - DingTalk Chatbot Notification Settings: Configure the settings of DingTalk chatbot notifications. The settings include the webhook URL, signed key, notification rules, and custom message of the DingTalk chatbot. After the configuration is complete, you can configure fine-grained settings of the DingTalk chatbot for each process in specific processes.
Process configuration
You can configure the following processes for a pipeline:
- Code Source
Configure the code source of a current pipeline. The code source settings are used to configure the trigger conditions for code. For example, you can trigger the code by pushing the code to a specified branch, using Tag/Release events, or using pull request (PR) and merge request (MR)events.
Important If you need to modify a code repository, go to the application details page to modify the code repository. After you modify the code repository, all pipelines become invalid. Exercise caution when you perform this operation. - Config Comparison
Check whether the
s.yaml
file of a pipeline is consistent with the online configurations. This process can be used to detect unexpected configuration changes in advance. If you need to manually confirm the changes before the changes take effect, you can enable Manual Review in the next phase. - Manual Review
To ensure the secure release and stability of an application, you can enable manual review. In this case, the pipeline is blocked when it reaches this phase and waits for manual review to complete. Subsequent processes are performed only after the manual review is passed. Otherwise, the pipeline is terminated.
- Build and Deploy
Configure the build and deployment commands of applications.
- Custom Build Command: Specify the build command, such as
Comparison
, if you want to build the application before you deploy the application.Note If your build command is integrated into thes.yaml
file, you do not need to configure the build command again. - Path of Build Command: Specify the path to run the build command. You can specify only the relative directory of the code. For example, if the code is in the current folder, enter
./
. - Deploy Parameters: By default, all items are deployed. You can specify to only update functions, only update code, and only update configurations, and use the debugging mode. Parameters are added to
s deploy
to configure the settings based on the modes you select.
- Custom Build Command: Specify the build command, such as
- Canary Release
Configure the canary release feature, including the application versions, alias, and traffic ratio. This feature is based on the alias and canary release features of Function Compute. For more information, see Use versions and aliases to implement canary release. If you configure Canary Release, the pipeline automatically publishes a new version and points the specified alias to the new version to perform canary release based on the specified ratio.
If you have configured the canary release feature in the
s.yaml
file, you do not need to configure this feature here. Be default, the canary release configurations in thes.yaml
file are used. - Manual Review
Configure another manual review policy.
- Version Release
Release version and alias of applications. During the release process, the version and alias of the service in Function Compute are released, and the alias is pointed to the latest version. During this process, the new version is formally released. If canary release is configured in the preceding processes, the canary release is completed in this process and the alias is fully pointed to the new version and 100% of the traffic is routed to the new version.
If you have manually configured a release policy in the
s.yaml
file, you do not need to enable this feature. The system automatically uses the release policy configured in thes.yaml
file.
Configure a custom pipeline plan
By default, Alibaba Cloud Function Compute bears the costs that are generated during the pipeline execution. The default pipeline mode can meet the requirements in most scenarios. However, the default mode does not allow you to modify your pipeline details or trigger pipeline execution over VPC. If you want to customize pipeline settings, such as the builder and environment configurations, or trigger the pipeline by using GitLab in a VPC, you can configure a custom pipeline.
- On the details page of the specified environment, click Pipeline Management. In the Pipeline Details section, click Use Custom Pipeline Plan.
- In the Use Custom Pipeline Plan dialog box that appears, select Custom Pipeline Scheme, configure the parameters based on your business requirements, and then click OK.
You to create custom pipelines for your services. These pipelines can be directly used only by you unless you release the trigger rules and URL the public. You can configure higher-level pipeline features, including the timeout period of a pipeline and VPC-based triggering.
After a custom pipeline is triggered, you are charged for fees generated. For more information, see Billing overview.
View the execution history of a pipeline

You can click a specific execution version of a pipeline to view the information about the pipeline history. You can view the error messages of the pipeline and troubleshoot errors.