Web3 Meets DevOps: Deploying Contracts | by Donovan Brown | Jun, 2022

Web3 needs DevOps

Part-2 — Building a DevOps pipeline for the Ethereum blockchain

Ethereum logo
Photo by Shubham Dhage on Unsplash

In the previous post of this series, Web3 DevOps: Part 1 — Compiling and Testing, I set up the frontend and solidity contracts with truffle and covered compiling and testing.

In this post, I will deploy the smart contracts, and show you how to deploy them without requiring the frontend to be recompiled.

I created a new branch named “blog/part2” for this post.

git checkout -b blog/part2

As I mentioned in the previous post of this series, deploying smart contracts is where this process gets tricky. To understand why let’s examine what happens when a contract gets deployed to a network.

I used Ganache as a test network for local development and will use it in the Dev environment of my pipeline. To start Ganache locally, I entered this command:


Before I could deploy to Ganache, I had to update the truffle-config.js file by adding a development section under networks:

development section of truffle-config.js

With that section added, I ran the following command to deploy my contracts:

truffle migrate

When a contract is deployed to a network, an address is assigned. This address is required for the front end to communicate with the contracts on-chain. The address is written to the JSON file for the contract under the client/src/contracts folder created when the contracts are compiled. The JSON file has a networks section that is populated with the address for each network where the contract has been deployed.

Networks section of JSON file with contract address

Therefore, for the frontend to communicate with the contract, it must be built after every deployment. This means the frontend must be built in the Dev, QA, and Prod environments. Rebuilding code multiple times is a DevOps antipattern. The code should only be compiled once with the resulting artifact being deployed to each environment unmodified. Any values that need to be adjusted for each environment must be externalized from the code and injected at run time.

Reviewing the App.js file in the client/src folder, I can see the import of the JSON file on line 2. That information is used on line 20 to get the network details for the deployed contract, which includes the address.

Default code of frontend

I changed this code to read the address from an external source. I still loaded the JSON file because it also contains the Application Binary Interface (ABI) that does not change and is required to deploy the code.

I want the code to work as it did originally for local development, but also work if the address is unable to be found in the JSON file. If the code fails to find the address in the JSON file, it makes a call to an external service for the address. Because I decided to use Azure Static Web Apps to host my frontend, I used the built-in Azure Function support to host the service that returns the address of the contract.

First, I updated the code to call the service. Everything up to and including line 20 stayed the same. I added code before the creation of the contract instance to locate the address. On line 22, I stored the value returned from the JSON file. Then, on line 26, I tested the value to see if it was empty. If the address returned empty, a call would be made to the service, on line 28, passing the network Id to return the address of the contract for that network. Finally, on line 33, I constructed an instance of the contract using the ABI and the calculated address. The rest of the file remains the same as the original file.

Updated code

By externalizing the address, the frontend is only built once. The code does not change as it moves from Dev to QA and finally into Prod. During the first stage of my pipeline, I compiled the contracts and frontend, and published the resulting files as artifacts of my build. Those artifacts will be moved through the pipeline unmodified.

With the code in place, I can now write the service that is called on line 28, the Azure Function, which I will do in the next post of this series.

Editor: Chelsea Brown
Technical Review: Brian Benz

News Credit

%d bloggers like this: