You can use the alias of an SCF function to implement the grayscale release scheme for the function, which has the following advantages:
The following is the scheme diagram:
It refers to an SCF function you create.
An SCF function version contains the code and function configuration information and is specified by a specific version number. You can generate a specific version and version number through release. Code and configuration only on the latest version can be modified, but all versions can be called. For more information on the SCF function version, please see Version Management Overview.
It refers to the version whose code and configuration can be modified. After a function is created, it will have the latest version by default. When the function is published, it will be published on the latest version with the specific version number.
An alias can have a custom name starting with a letter. It is a reference that can be configured to point to one or two versions. If it points to two versions, the traffic percentages can be set for them. All aliases can be called.
It is a special alias. If a call request does not point to any version or another alias, the default alias will be used to point to the latest version by default. The version pointed to can be modified.
1. Create an alias:
Create aliases release
and prepub
in SCF function B, which temporarily point to the $LATEST
version.
2. Create an API gateway:
Create API service A in API Gateway, configure the API to point to the release
alias of function B, and publish it to the release
stage of the API service. For more information on how to create and publish an API, please see API Creation and API Release.
3. Modify API configuration:
a. Point the API to the prepub
alias of function B and publish it into the prepub
stage of the API service.
b. Point the API to the default traffic of function B and publish it into the dev
stage of the API service.
At this point, the test, pre-release, and release environments have been separated, but they all point to the $LATEST
version. API Gateway configuration is completed, and there will be no need to modify and publish the API Gateway configuration again.
1. Publish versions:
In SCF, continuously develop and publish versions 1, 2, 3, and 4 in sequence. Suppose version 1 is in the release environment, version 2 is tested in the pre-release environment, and versions 3 and 4 are tested in the test environment.
2. Develop the latest version that needs to be tested:
By configuring the $DEFAULT
alias to point it to the $LATEST
version, you can perform continuous development based on this version. After development is completed, the version can be published.
3. Test in the pre-release environment:
When version 3 can enter the pre-release environment, if the prepub
alias of function B is configured to point to version 3, version 3 can be tested and trialed in the pre-release environment.
4. Implement grayscale release by user in the pre-release environment:
If version 4 can enter the pre-release environment, calls of user Bob need to be routed to version 4 of function B, calls of other users need to be routed to version 3, and the prepub
alias of function B needs to be configured for routing by rule with the content invoke.headers.User exact Bob
. For more information on routing by rule, please see Routing by Rule.
5. Enter the release environment from the pre-release environment and implement grayscale release:
If version 2 has been trialed in the pre-release environment and can be launched, gradually switch the traffic configuration of the release
alias of function B from version 1 to 2 and continuously observe the function status during the grayscale release. For more information on how to configure alias traffic, please see SCF Traffic Routing Configuration.
6. Continuously monitor during release:
View the grayscale release process through monitoring information and logs and check whether the traffic of version 2/1 increases/decreases normally, errors of each version during the release, and overall errors.
Suppose a failure occurs when version 2 is launched. In this case, you need to roll back to the previous version by modifying the release
alias of function B to point all of its traffic to version 1.
Create aliases release
and prepub
in SCF function B, which temporarily point to the $LATEST
version.
1. Publish versions:
In SCF, continuously develop and publish versions 1, 2, 3, and 4 in sequence. Suppose version 1 is in the release environment, version 2 is tested in the pre-release environment, and versions 3 and 4 are tested in the test environment.
2. Develop the latest version that needs to be tested:
By configuring the $DEFAULT
alias to point it to the $LATEST
version, you can perform continuous development based on this version. After development is completed, the version can be published.
3. Test in the pre-release environment:
When version 3 can enter the pre-release environment, if the prepub
alias of function B is configured to point to version 3, version 3 can be tested and trialed in the pre-release environment.
4. Route by rule in the pre-release environment:
If version 4 can enter the pre-release environment, you can configure routing by rule for function B. Customize the key
and value
passed in to point them to version 4. When calling the invoke
API, retain the key-value pair in the RoutingKey
input parameter in json
format. If RoutingKey
has any key-value pair matching the rule, version 4 will be routed to. For more information on routing by rule, please see Routing by Rule and Running Function Through API.
5. Enter the release environment from the pre-release environment and implement grayscale release:
If version 2 has been trialed in the pre-release environment and can be launched, gradually switch the traffic configuration of the release
alias of function B from version 1 to 2 and continuously observe the function status during the grayscale release. For more information on how to configure alias traffic, please see SCF Traffic Routing Configuration.
6. Continuously monitor during release:
View the grayscale release process through monitoring information and logs and check whether the traffic of version 2/1 increases/decreases normally, errors of each version during the release, and overall errors.
Suppose a failure occurs when version 2 is launched. In this case, you need to roll back to the previous version by modifying the release
alias of function B to point all of its traffic to version 1.
When using Serverless Cloud Framework, you can use stages to distinguish between the test, pre-release, and release environments. When implementing grayscale release in the release environment, you can use the following commands for gradual switch. For detailed directions, please see Using tencent-express Component to Deploy Express Website.
scf deploy --inputs.traffic=0.1 # Deploy and switch 10% traffic to the `$latest` version
scf deploy --inputs.traffic=1.0 # Deploy and switch 100% traffic to the `$latest` version
scf deploy --inputs.traffic=1.0 # Deploy and switch 100% traffic to the `$latest` version
Was this page helpful?