Efficient development comes from a team's ability to build solutions incrementally in a reliable way. Daily, you need to integrate the work of your team members just to keep building, which can take up a lot of time, especially if you’re building a multichain product.
The good news is you can set up a CD pipeline to do it for your entire team, saving you significant time along the way. Think of CD workflows as railways your team uses to effortlessly exchange work increments as they get committed to a repository.
For example, a CD pipeline can deploy and stage smart contracts on a shared development infrastructure for the rest of your team to integrate. To simplify the entire CD setup, use a simple GitHub Action to provision a Tenderly Virtual TestNet for any number of EVM chains you’re building on and deploy contracts through Hardhat and Foundry integrations.
Let's see what makes an effective CD pipeline and how easy the setup is.
Why stage contracts on a shared development infrastructure
During dapp development, the most active smart contract users are other builders. Since smart contracts are the origin of most functionalities, UI builders, backend developers, and data indexing teams are on the receiving end of all possible code changes.
Besides catching up with smart contract updates, other teams need to implement the changes locally and run deployment scripts on their local machines. If everything works as expected, they can do their work––finally.
So, in a regular setup, Web3 teams deal with a lot of dependencies that cause inefficiencies during development:

Luckily, a properly set-up CD workflow can eliminate these inefficiencies by deploying smart contracts on a collaborative development infrastructure such as Virtual TestNets. By deploying smart contracts on a shared Virtual TestNet, all team members can integrate them and continue with their testing process, achieving fast, incremental progress. Additionally, teams can use Virtual TestNets to fork multiple networks and set up a multichain development infrastructure.
Let’s examine what makes a useful CD pipeline that can improve your team’s development velocity.
5 Requirements for an efficient CD workflow
A well-built continuous deployment setup eliminates the “work I need to do before I can do my work." Here are the most important requirements for an efficient CD workflow:
- Effortless infrastructure provisioning: The Virtual TestNets GitHub Action lets you set up and manage your staging infrastructure with a few lines of yaml, even for multichain deployments. For more control, you can use the Virtual TestNets REST API to create, delete, or interact with your Virtual TestNets.
- Integration with existing protocols: When building contracts that integrate with real-world, third-party protocols, Web3 teams often need to deploy and test them on a network’s mainnet, and even do this multiple times if they’re building a multichain product. Instead of testing in production where you deal with network congestion and long execution times, use Virtual TestNets that sync with production chains. With full access to the latest mainnet data, you can test integrations with real contracts as you build.
- Separation of data for different dapp layers: Keeping test data clean is crucial. Otherwise, UI, backend, and data teams need to spend significant time getting to the information that matters to them. To avoid this, each team can fork the Virtual TestNet with the staged contracts and create a separate playground to avoid data pollution, while keeping access to the latest staged contracts.
- Easy asset creation: Your CD process should have access to sufficient amounts of test tokens, without you spending any time providing them. What’s more, an efficient CD pipeline should set up the initial assets for your smart contracts and EOA for further testing. The unlimited faucet on Virtual TestNets lets you and your CD workflow get arbitrary amounts of assets––both native and ERC-20 balances.
- Fast deployment times and effortless verification: Virtual TestNets consider every transaction instantly confirmed. So, the complete deployment of a single smart contract on several network replicas is no longer than a couple of seconds or even less. Plus, you can verify your contracts instantly and privately with almost zero configuration on your end.
Infrastructure as code: how to set up a CD pipeline on Virtual TestNets
Tenderly Virtual TestNets are a managed, collaborative Web3 development infrastructure. Fully adjustable to development workflows, Virtual TestNets can meet all the preconditions for an effective CD pipeline while improving your team collaboration.
To facilitate your CD setup on Virtual TestNets, you can use the open-source GitHub Action template to provision a fresh Virtual TestNet on every build. Plus, with a single call, you can provision a Virtual TestNet for any number of chains you’re building on. Then, you can use the multichain Virtual TestNets to deploy contracts for the rest of the team to build on top of them.
In just a few simple steps, you can set up a new GitHub workflow that:
- provisions a fresh Virtual TestNet for Ethereum Mainnet and Base in a matter of seconds in the
Setup Virtual TestNet
step - tests smart contracts to ensure expected behavior
- funds deployer account in step
Fund Deployer Account on Mainnet and Base
- deploys smart contracts to both networks
- commits the deployment information for the rest of your team to use with
push_on_complete
flag
Here’s an example workflow file:
name: Foundry multi-chain CD pipeline
on: [push, pull_request]
jobs:
deploy:
runs-on: ubuntu-latest
defaults:
run:
working-directory: ./examples/foundry
permissions:
contents: write
steps:
- uses: actions/checkout@v4
with:
submodules: recursive
- name: Setup Virtual TestNet
uses: tenderly/vnet-github-action@v1.0.15
with:
mode: CD
access_key: ${{ secrets.TENDERLY_ACCESS_KEY }}
project_name: ${{ vars.TENDERLY_PROJECT_NAME }}
account_name: ${{ vars.TENDERLY_ACCOUNT_NAME }}
testnet_name: "Staging"
network_id: |
1
8453
chain_id_prefix: 7357
public_explorer: true
verification_visibility: 'src'
push_on_complete: true
- name: Install Foundry
uses: foundry-rs/foundry-toolchain@v1
- name: Deploy Contracts Mainnet
run: |
forge build --sizes
forge script script/Counter.s.sol \
--private-key ${{ secrets.DEPLOYER_PRIVATE_KEY }} \
--rpc-url ${{ env.TENDERLY_PUBLIC_RPC_URL_1 }} \
--verifier-url ${{ env.TENDERLY_FOUNDRY_VERIFICATION_URL_1 }} \
--etherscan-api-key $TENDERLY_ACCESS_KEY \
--slow --verify --json > $BUILD_OUTPUT_FILE_1
- name: Deploy Contracts Base
working-directory: ./examples/foundry
run: |
forge script script/Counter.s.sol \
--private-key ${{ secrets.DEPLOYER_PRIVATE_KEY }} \
--rpc-url ${{ env.TENDERLY_PUBLIC_RPC_URL_8453 }} \
--verifier-url ${{ env.TENDERLY_FOUNDRY_VERIFICATION_URL_8453 }} \
--etherscan-api-key $TENDERLY_ACCESS_KEY \
--slow --verify --json > $BUILD_OUTPUT_FILE_8453
Set up multichain CD on Virtual TestNets to eliminate dependencies
Setting up continuous deployment can improve your team's efficiency in distributing work increments among team members. After testing your contracts and other components in the continuous integration step, the CD process can stage them for the rest of the team.
This way, your team can keep test data clean while accessing up-to-date mainnet state. Plus, provisioning development infra for several networks with a few lines of yaml eliminates the unnecessary overhead of infrastructure management.
Set up an automated, repeatable process with Virtual TestNets to build more efficiently with your team.