01 / 01
Deploy your project with CI
A common setup splits deployment into two stages: staging and production. You create each deployment with chr deployment create, following the CLI deployment guide. With one staging and one production deployment in place, the deployments section of your chromia.yml could look like this:
deployments: staging: url: "https://my.staging.dev:7740" brid: x"5926EE7B51B728853C8014AD9F208F1001FEE6395B49D14E70B43E4CD9D607C1" container: my_staging_container chains: my-chain: x"18C8F8497FCC86FF6A91CA7CEC46F944A9C39E3E657D79A83DA453219F30368E" production: url: "https://my.production:7740" brid: x"63A8F21DC932C8CE8E9C96DE3D2909DDDE692BBC008D5F50E6A3561CFA47A854" container: my_prod_container chains: my-chain: x"45893974893F4B030AF63DDF7F72564097903012802AB0B3DA6C126751DB90C3"Staging usually tolerates larger, breaking changes, so wiping the database on each deployment there can make sense. One way to do this is to define two entry points: main.rell and development.rell. The main module is the production entry point. The development module imports main and adds an operation that resets every table:
module;import main;operation reset() { // Delete all tables: // delete foo @* {}; // etc}Next, change the blockchains tag in chromia.yml so it picks the module from an environment variable:
blockchains: my-chain: module: ${MAIN_MODULE:-main}With that in place, you can define these pipeline jobs:
deploy-staging: stage: deploy rules: - if: $CI_COMMIT_BRANCH == "development" # development branch name variables: MAIN_MODULE: development POSTCHAIN_CLIENT_PUBKEY: ${CI_SECRET_PUBKEY} POSTCHAIN_CLIENT_PRIVKEY: ${CI_SECRET_PRIVKEY} script: - chr tx reset --network staging --blockchain my-chain - chr deployment update --network staging --blockchain my-chaindeploy-production: stage: deploy rules: - if: $CI_COMMIT_BRANCH == "main" # production branch name variables: MAIN_MODULE: main POSTCHAIN_CLIENT_PUBKEY: ${CI_SECRET_PUBKEY} POSTCHAIN_CLIENT_PRIVKEY: ${CI_SECRET_PRIVKEY} script: - chr deployment update --network production --blockchain my-chainEach job has a rule that ties it to a branch. A merge into the development branch resets and then updates the staging network, while a production deployment only performs the update. Store the deployment admin's private and public keys as GitLab secrets.
pipelines: branches: development: # development branch - step: name: Deploy to Staging script: - export MAIN_MODULE=development - chr tx reset --network staging --blockchain my-chain - chr deployment update --network testnet --blockchain my-chain main: # production branch - step: name: Deploy to Production script: - export MAIN_MODULE=main - chr deployment update --network production --blockchain my-chainHere, two pipeline steps run depending on which branch triggered the build. On the development branch, the step resets the network and then updates the deployment. On the main branch, the step updates the production network. Add the POSTCHAIN_CLIENT_PUBKEY and POSTCHAIN_CLIENT_PRIVKEY properties, holding the deployment user's key pair, in the Bitbucket Pipelines UI.