CloudBase Multi-Environment Management Practice
Background
Cloud Development provides environment replication capabilities, facilitating developers to conduct project development across multiple environments.
Environment Resource Replication Practice (A -> B)
Function Resources
Copy Cloud Function code from the corresponding function in environment A. Note that the hard-coded environment ID A in the code needs to be manually changed to B.
If a function uses the Node SDK and operates within the current environment, the recommended approach is as follows:
const cloudbase = require("@cloudbase/node-sdk")
const app = cloudbase.init({
env: cloudbase.SYMBOL_CURRENT_ENV // Automatically selects the current environment
})Function property configurations such as memory, timeout duration, environment variables, timed triggers, vpc, public network access configurations, cloud access configurations & authentication for the function, and CLS log configurations are all copied, requiring no developer intervention.
Function layers will not be copied; they must be manually created in B.
Database Resources
- During database replication, only empty collections with the same names are created in the new environment. Table data must be manually exported and imported by the user in the console (export from the A environment database and import to the B environment database).
- Database security rules and index settings are copied, requiring no developer action.
Cloud Storage Resources
Cloud storage configurations such as permission settings and cache configurations are all copied, requiring no user action.
Specific file resources require manual export and import by the user (export file resources from environment A and import to environment B).
Recommended Practices
Install the cloudbase cli tool and log in
npm i -g @cloudbase/cli
tcb loginDownload all files from environment A to local.
# Download all files
tcb storage download / localPath --dir -e AUpload local files to the B environment
tcb storage upload localPath -e B
Multi-Environment Project Development Practices
1. Development Environment and Production Environment Differentiation
Based on the environment replication capability, you can quickly set up both a development (dev) and a production (prod) environment, eliminating the need for repetitive operations such as creating tables and functions repeatedly.
https://developers.weixin.qq.com/miniprogram/dev/wxcloud/basis/concepts/environment.html
Operational Practices
When using the SDK in Cloud Functions, adopt a dynamic environment approach (similar to function resource replication) to avoid hardcoding the environment ID.
Mini Program Side Example
const cloud = require('wx-server-sdk')
cloud.init({
env: cloud.DYNAMIC_CURRENT_ENV
})Tencent Cloud Side Example
const cloudbase = require("@cloudbase/node-sdk")
const app = cloudbase.init({
env: cloudbase.SYMBOL_CURRENT_ENV // Automatically selects the current environment
})In development and production environments, the client only needs to specify the corresponding environment ID respectively.
wx.cloud.init({
// Please enter the environment ID here. You can view the environment ID in the cloud console.
env: config.ENV // dev or prod
})
To go a step further, to eliminate the risks of manual operations, the environment ID can be configured through engineering practices, such as setting the dev environment ID in development mode and the prod environment ID in production mode. Specific implementation details are not elaborated here.
2. Project Collaborative Development
In the same environment, multi-person collaborative development is prone to dirty data issues. Each developer can replicate their own development environment based on the project's initial environment, ensuring that debugging and development in each environment do not interfere with each other.