Skip to main content

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

  1. 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
    })
  2. 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.

  3. Function layers will not be copied; they must be manually created in B.

Database Resources

  1. 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).
  2. Database security rules and index settings are copied, requiring no developer action.

Cloud Storage Resources

  1. Cloud storage configurations such as permission settings and cache configurations are all copied, requiring no user action.

  2. 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 login
    • Download all files from environment A to local.

      # Download all files
      tcb storage download / localPath --dir -e A
    • Upload 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

  1. 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
    })
  2. 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.