CI/CD for smart contracts in Blockchain / Solidity - Step-by-Step Execution

Concept Flow - CI/CD for smart contracts

Write Smart Contract Code

↓

Commit Code to Repository

↓

Trigger CI Pipeline

↓

Run Automated Tests

↓

Build & Package

↓

Deploy to Testnet

↓

Run Integration Tests

↓

Deploy to Mainnet

↓

Monitor & Alert

This flow shows how smart contract code moves from writing to deployment using CI/CD pipelines with testing and error handling steps.

Execution Sample

Blockchain / Solidity

git commit -m "Add new contract"
git push origin main
# CI pipeline triggers
npm run test
npm run build
npm run deploy:testnet
npm run deploy:mainnet

This sequence commits smart contract code, triggers CI pipeline, runs tests, builds, deploys to testnet, then mainnet.

Execution Table

Step	Action	Command/Process	Result	Next Step
1	Commit code	git commit -m "Add new contract"	Code saved locally	Push code to remote
2	Push code	git push origin main	Code pushed to remote repo	CI pipeline triggered
3	CI triggered	CI pipeline starts	Pipeline running tests	Run automated tests
4	Run tests	npm run test	Tests passed	Build and package
5	Build	npm run build	Build successful	Deploy to testnet
6	Deploy testnet	npm run deploy:testnet	Contract deployed to testnet	Run integration tests
7	Integration tests	Automated integration tests	Integration tests passed	Deploy to mainnet
8	Deploy mainnet	npm run deploy:mainnet	Contract deployed to mainnet	Monitor deployment
9	Monitor	Monitoring tools active	No errors detected	End

💡 Pipeline ends after successful deployment and monitoring with no errors.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 6	Final
Code State	Local changes	Pushed to remote	Tested and passed	Deployed on testnet	Deployed on mainnet
Pipeline Status	Not started	Triggered	Tests passed	Integration tests passed	Completed successfully

Key Moments - 3 Insights

Why do we deploy first to a testnet before mainnet?

Deploying to testnet allows testing in a safe environment without risking real assets, as shown in execution_table steps 6 and 7 where deployment and integration tests happen before mainnet deployment.

What happens if tests fail during the CI pipeline?

If tests fail (not shown in this successful flow), the pipeline stops and reports errors, preventing faulty contracts from deploying, as indicated by the decision branches in the concept_flow.

Why is monitoring important after deployment?

Monitoring detects any runtime issues or attacks on the deployed contract, ensuring reliability and security, as shown in execution_table step 9.

Visual Quiz - 3 Questions

Look at the execution_table, what is the pipeline status after step 4?

A Tests passed

B Triggered

C Integration tests passed

D Completed successfully

💡 Hint

Check the 'Pipeline Status' variable in variable_tracker after step 4.

At which step does the smart contract get deployed to the testnet?

A Step 5

B Step 6

C Step 7

D Step 8

💡 Hint

Refer to the 'Action' column in execution_table for deployment steps.

If tests fail at step 4, what would happen next in the pipeline?

A Proceed to build and deploy

B Deploy directly to mainnet

C Stop pipeline and report errors

D Skip integration tests

💡 Hint

Look at the concept_flow decision branches after 'Run Automated Tests'.

Concept Snapshot

CI/CD for smart contracts:
- Commit and push code triggers CI pipeline
- Automated tests run first; failure stops pipeline
- Build and deploy to testnet after tests pass
- Run integration tests on testnet
- Deploy to mainnet if all tests pass
- Monitor deployed contracts continuously

Full Transcript

This visual execution shows the CI/CD process for smart contracts. First, developers write and commit code. Pushing code triggers the CI pipeline which runs automated tests. If tests pass, the contract is built and deployed to a testnet. Integration tests run on the testnet deployment. Passing integration tests lead to deployment on the mainnet. Finally, monitoring tools watch the live contract for issues. If any tests fail, the pipeline stops and reports errors to prevent faulty contracts from deploying.

Practice

1. What is the main purpose of using CI/CD pipelines for smart contracts?

easy

A. To manually write smart contract code faster

B. To avoid writing tests for smart contracts

C. To store smart contracts on a local machine only

D. To automate compiling, testing, and deploying smart contracts

Solution

1. Step 1: Understand CI/CD role in smart contracts

   CI/CD pipelines automate repetitive tasks like compiling, testing, and deploying smart contracts to reduce errors and save time.

2. Step 2: Compare options with CI/CD purpose

   Only To automate compiling, testing, and deploying smart contracts describes automation of compile, test, and deploy steps, which is the core of CI/CD.

3. Final Answer:

   To automate compiling, testing, and deploying smart contracts -> Option D

4. Quick Check:

   CI/CD automates smart contract lifecycle steps = B [OK]

Hint: CI/CD means automate build, test, deploy steps [OK]

Common Mistakes:

• Thinking CI/CD is for manual coding
• Confusing storage with deployment
• Skipping testing in CI/CD

2. Which of the following is the correct syntax to trigger a GitHub Actions workflow on every push to the main branch for smart contract CI/CD?

easy

A. on: push:
branches: [main]

B. trigger: push main

C. on_push: main_branch

D. when: push to main

Solution

1. Step 1: Identify correct GitHub Actions event syntax

   The correct syntax uses 'on:' followed by the event type and branches list, like 'on: push:\n branches: [main]'.

2. Step 2: Compare options to GitHub Actions docs

   Only on: push: branches: [main] matches the official YAML syntax for triggering workflows on push to main branch.

3. Final Answer:

   on: push: branches: [main] -> Option A

4. Quick Check:

   GitHub Actions uses 'on: push' with branches list = A [OK]

Hint: GitHub Actions uses 'on:' with event and branches [OK]

Common Mistakes:

• Using incorrect keywords like 'trigger' or 'when'
• Wrong indentation or missing colon
• Confusing event names

3. Given this GitHub Actions step in a smart contract pipeline:

 - name: Compile Contract
   run: solc --bin MyContract.sol -o build/

What will this command do?

medium

A. Run tests on MyContract.sol

B. Deploy MyContract.sol to blockchain network

C. Compile MyContract.sol and output binary files to build/ directory

D. Delete build/ directory

Solution

1. Step 1: Understand solc compile command

   The command 'solc --bin MyContract.sol -o build/' compiles the Solidity file and outputs binary files to the specified build directory.

2. Step 2: Match command purpose to options

   Only Compile MyContract.sol and output binary files to build/ directory correctly describes compiling and outputting binaries, while others describe unrelated actions.

3. Final Answer:

   Compile MyContract.sol and output binary files to build/ directory -> Option C

4. Quick Check:

   solc --bin compiles and outputs binaries = C [OK]

Hint: solc --bin compiles Solidity to binary output [OK]

Common Mistakes:

• Confusing compile with deploy
• Assuming tests run automatically
• Thinking it deletes files

4. You have this GitHub Actions step to deploy a smart contract:

 - name: Deploy Contract
   run: truffle migrate --network mainnet

But the deployment fails with an error about missing network configuration. What is the likely cause?

medium

A. The 'truffle migrate' command is misspelled

B. The 'mainnet' network is not defined in truffle-config.js

C. The GitHub Actions runner lacks internet access

D. The smart contract code has syntax errors

Solution

1. Step 1: Analyze error about missing network configuration

   The error indicates the deployment tool cannot find the 'mainnet' network settings in the configuration file.

2. Step 2: Identify cause of missing network config

   If 'mainnet' is not defined in truffle-config.js, deployment fails. Syntax errors or internet issues cause different errors, and the command spelling is correct.

3. Final Answer:

   The 'mainnet' network is not defined in truffle-config.js -> Option B

4. Quick Check:

   Missing network config causes deployment failure = D [OK]

Hint: Check truffle-config.js for network definitions first [OK]

Common Mistakes:

• Blaming code syntax for network config errors
• Ignoring configuration files
• Assuming internet issues without checking config

5. You want to ensure your smart contract CI/CD pipeline only deploys contracts after all tests pass and on the 'release' branch. Which GitHub Actions workflow snippet correctly enforces this?

hard

A. on:
push:
branches: [release]
jobs:
build:
steps:
- run: npm test
deploy:
needs: build
if: success()
steps:
- run: truffle migrate --network mainnet

B. on:
push:
branches: [main]
jobs:
deploy:
steps:
- run: truffle migrate --network mainnet

C. on:
pull_request:
branches: [release]
jobs:
test:
steps:
- run: npm test
deploy:
steps:
- run: truffle migrate --network mainnet

D. on:
push:
branches: [release]
jobs:
deploy:
steps:
- run: truffle migrate --network mainnet

Solution

1. Step 1: Identify branch trigger and job dependencies

   The pipeline triggers on push to 'release' branch. It runs tests first in 'build' job, then deploys only if tests succeed using 'needs: build' and 'if: success()'.

2. Step 2: Compare options for correct workflow logic

   on: push: branches: [release] jobs: build: steps: - run: npm test deploy: needs: build if: success() steps: - run: truffle migrate --network mainnet correctly sequences test then deploy with condition and branch filter. Others miss test step, branch, or job dependency.

3. Final Answer:

   on: push: branches: [release] jobs: build: steps: - run: npm test deploy: needs: build if: success() steps: - run: truffle migrate --network mainnet -> Option A

4. Quick Check:

   Test before deploy on release branch = A [OK]

Hint: Use job dependencies and branch filters in workflow [OK]

Common Mistakes:

• Deploying without testing first
• Triggering on wrong branch
• Missing job dependencies or conditions