After an application is created, you can view its environment information. This topic describes how to manage the environment of an application in Serverless Application Center of the Function Compute console, including how to create, view, and delete an environment and isolate services in different environments.
Background
The environment feature provides infrastructure management capabilities. With environments, you can:
Deploy services in environments of isolated infrastructure to achieve high availability or low latency for production services. For example, you can isolate services in different regions and virtual private clouds (VPCs).
Associate different pipeline rules with different environments to implement accurate and safe control over production processes. For example, you can specify that the commit action of a development branch triggers continuous integration (CI) in the test environment, and the merge action of the main branch triggers a release in the production environment.
Usage notes
By default, no domain name is assigned to an environment. An environment can host Alibaba Cloud resources, such as the Log Service, VPC, and Apsara File Storage NAS (NAS) resources. The resources are isolated in different environments. If you want to use different domain names for different environments, you must specify the customDomains field in the
s.yamlof the repository.Permissions to access corresponding Alibaba Cloud services are required when an environment hosts specific resources. You can attach policies that contain the required permissions on specific Alibaba Cloud services to the
AliyunFCServerlessDevsRolerole.A service can be deployed in different environments. You can decide whether to use the configurations provided by the environment.
View the information about an environment
Log on to the Function Compute console. In the left-side navigation pane, click Applications. On the Applications page that appears, find the desired application and click the 
icon on the left side of the application to view the environments of the application.
Click the name of an environment to view the information about the environment. The information includes basic information, code source configurations, deployment history, and resources. You can also develop the code that is associated with the environment on the cloud and configure pipelines.
Environment rollback
Risks may occur if you roll back an environment. If an error occurs, you can roll back an environment to a specified point in time. The rollback can be performed only on the business code of the application. Upstream and downstream business cannot be rolled back. For example, if the current application uses a database and the database cannot be connected due to an error, this issue may fail to be resolved by rolling back the business code of the application.
To roll back an environment, go to the Environment Details tab of the application details page, click Roll Back in the Deployment History section.
An environment rollback redeploys the business logic and configurations based on the snapshots of historical deployments. "Business logic and configurations" refer to the code and resource configurations, such as the s.yaml file, in a specified commit action in a code repository.
Resource management
Serverless Application Center allows you to view resource binding information. However, you cannot manage resources in Serverless Application Center.
You can use the resource binding information to manage resources on the management pages of the resources. However, this method is not recommended. We recommend that you use s.yaml, the resource description file in the code repository, to manage resources. If you perform operations on resources on the resource management page but you do not modify the s.yaml file of the code repository, the resources may be overwritten. For example, the s.yaml file of a code repository in a branch of an environment specifies that the memory size of a function is 1,024 MB. A developer directly changes the memory size of the function to 2,048 MB on the resource management page but does not modify the s.yaml file in the code repository. After the pipeline deployment of the environment is triggered, the memory size of the function changes from 2,048 MB back to 1,024 MB.
Cloud-based development
Serverless Application Center provides cloud-based development capabilities. On the Cloud Development tab of the application details page, click Initialize Repository to initialize code.
After the initialization, you can view the code in WebIDE and perform basic development and debugging operations. After you perform an operation, you can use a terminal or Git plug-in to push the code to a code repository. You can also click Save Code to Repository in the upper-left corner to add, commit, and push the code.
Pipeline management
For more information, see Manage pipelines.
Create an environment
The application center provides multi-environment capabilities. You can click Create Environment on an application details page to create an environment. 
The following table describes the parameters that you must configure to create an environment.
Parameter | Description |
Environment Name | The name of the environment. The environment name helps you distinguish different environments. An environment type can correspond to multiple environment names. |
Environment Type | The type of the environment. The environment type helps you categorize and filter environments. The following types are supported: test environment, staging environment, and production environment. |
Basic information about the environment | The basic information, such as the description, region, and role name of the environment. The configurations, such as the region, logging, networking, and storage settings, on the Create Environment page take precedence over the configurations in the |
Pipeline configurations | By default, each environment corresponds to a pipeline in Serverless Application Center. You can configure pipelines for different environments. |
The multi-environment capabilities provided by Serverless Application Center are more linked to the code branches of code repositories. The recommended best practice is that one environment corresponds to one pipeline, and one pipeline corresponds to one branch. For example, you can create the dev branch for the test development, the test branch for the test environment, and the main/master branch for the production environment in the code repository. This way, you can commit code to different branches to trigger pipelines. This ensures that the environment can be updated as expected. You can use the pull request (PR) and merge request (MR) features provided by code repositories to implement the flow of code environments from development branches to the test branches and the trunk branches.
In actual business scenarios, multiple applications may be deployed with the same code for different users. In this case, multiple pipelines can be triggered through one code branch. As a result, multiple environments simultaneously take effect after the code is updated.
Delete an environment
Log on to the Function Compute console. In the left-side navigation pane, click Applications. On the Applications page, find the application that you want to delete and click Delete in the Actions column.
You may need to delete resources when you delete an environment. You must determine the names and types of resources that you want to delete before you delete an environment. Deselect the check boxes to the left of the resources that you do not want to delete.
Use environments to isolate services
Serverless Application Center uses GitOps to implement the best practices of DevOps. Git repositories are used to manage the infrastructure of applications and continuous integration and continuous delivery (CI/CD) processes. Git repositories are the only sources of application status. You must use a YAML file that meets specifications to implement environment-based service isolation. For more information about YAML specifications, see YAML specifications.
In many cases, development and O&M responsibilities are divided in an enterprise. The two types of roles have a clear division of responsibilities. In most cases, O&M personnel manage the infrastructure of an enterprise and authorize developers to use the infrastructure. If all infrastructure is maintained in a Git repository, O&M personnel must submit code to change the infrastructure, which is against the habit of most O&M engineers. Therefore, the following deployment methods are available in Serverless Application Center.
Method 1:
Maintain different YAML files for different environments. Configure pipelines in the environments and use the specified YAML files for deployment.
YAML inheritance is supported in Serverless Devs to reduce repeated YAML configurations. For more information, see YAML inheritance.
Method 2:
Use the same YAML file for different environments. Configure variables in pipelines to reference the variables in YAML to implement isolation. Sample code:
vars: region: ${env(region)} service: name: demo-service-${env(prefix)} internetAccess: true logConfig: project: ${env(LOG_PROJECT)} logstore: fc-console-function-pre vpcConfig: securityGroupId: ${env(SG_ID)} vswitchIds: - ${env(VSWITCH_ID)} vpcId: ${env(VPC_ID)}Method 3:
Use the same YAML file for different environments and use the resource information of the environments to configure the specified service. The following sample code provides an example.
service: logConfig: project: ${environment.outputs.slsProject} logstore: ${environment.outputs.slsLogStore} vpcConfig: vpcId: ${environment.outputs.vpcId} securityGroupId: ${environment.outputs.securityGroupId} vswitchIds: - ${environment.outputs.vswitchId} nasConfig: userId: 10003 groupId: 10003 mountPoints: - serverAddr: ${environment.outputs.nasMountTargetId} nasDir: /fc-deploy-service fcDir: /mnt/auto
Different deployment methods are suitable for different scenarios:
Method 1:
Applies to scenarios in which R&D and O&M personnel belong to the same team and all personnel have the permissions on the YAML file. This method is efficient.
Method 2:
Applies to scenarios in which infrastructure changes are infrequent and the number of environments is small. The O&M personnel plan the resources in advance and configure the resources in environment variables of pipelines. You need to only declare and reference the environment variables in the YAML file. This method completely separates responsibilities of R&D and O&M personnel. However, this method is difficult to expand when a large amount of infrastructure is used.
Method 3:
Applies to the development of modern serverless applications. For example, during a CI process, different environments can be triggered to pull up cloud resources and environment resources can be deleted after the test. Environments can be used to activate services with a few clicks. Responsibilities of R&D and O&M personnel can be divided in production environments. The access permissions on production resources can be granted to R&D personnel on demand.