deployment | NZRT NETWORK

Welcome to the NZRT Wiki Podcast. Today we’re looking at Contract Deployment.

Specifically, we’re going to walk through how you compile, deploy, and verify a smart contract on the Base network using a tool called Hardhat. Whether you’re targeting the testnet or pushing to mainnet, this guide covers the full sequence from pre-flight checks all the way through to post-deployment confirmation.

Let’s start before you even touch a deploy command, because there are five things you need to have sorted first.

One, your contract needs to be compiled and come back clean — no warnings. Two, your tests need to be passing. You run those with the Hardhat test command. Three, you need a dot-env file populated with three specific values: your private key, your Alchemy Base Sepolia URL, and your Basescan API key. Four, your deployer wallet needs to actually have test ETH on Base Sepolia — no funds, no deployment. And five, your Hardhat config file needs to include both Base Sepolia and Base Mainnet as networks. Get all five of those sorted before you go any further.

Now let’s talk about the deployment script. There’s a JavaScript file in the scripts folder called deploy dot js, and here’s what it does in plain terms. It starts by grabbing the first signer from your Hardhat environment — that’s your deployer wallet. It logs the wallet address and the current ETH balance to the console, so you can confirm you’re deploying from the right account with enough funds. Then it sets an initial supply of one million tokens, uses Hardhat’s contract factory to pull in a contract called ITSLToken, and deploys it with that initial supply. Once the deployment transaction is confirmed on-chain, it prints the deployed contract address to your console. There’s also basic error handling at the end — if anything goes wrong, it logs the error and exits with a failure code so you know the deployment didn’t succeed.

Once that script is in place, actually running a deployment is a single command. For testnet, you run Hardhat with the deploy script pointed at the base-sepolia network. That will execute everything in the script we just described and land your contract on Base Sepolia. For mainnet, the command is identical except you swap base-sepolia for base-mainnet. The wiki notes to use mainnet with caution — you’ll need a funded deployer wallet, and there’s no undoing a mainnet transaction.

After deployment, you’ll want to verify your contract on Basescan. Verification means the source code is publicly visible and readable on the block explorer, which is important for trust and auditability. You do this with a Hardhat verify command, passing in the network, the contract address you just deployed to, and the initial supply as arguments. So for example, you’d supply the contract address — a long hexadecimal string — and then the number one million as a quoted value. Hardhat handles the rest, submitting your source to Basescan and linking it to the deployed bytecode.

Once verification is done, there are four post-deployment steps to work through. First, go to the Basescan explorer — for testnet that’s sepolia dot basescan dot org, and for mainnet it’s basescan dot org — and confirm your contract actually shows up. Second, click into the Contract tab on that page and check that it shows verified source. If the verification step worked correctly, you should see your readable Solidity code right there in the browser. Third, if you’re on mainnet, transfer ownership of the contract to a Gnosis Safe. That’s a multi-signature wallet setup that protects against single points of failure — so no one person can unilaterally make changes to the contract after it’s live. And fourth, record the contract address in the Wiki under the Blockchain section, so the rest of the team knows where to find it.

That’s the full flow. Pre-deployment checklist, deploy script, run the deploy command for whichever network you’re targeting, verify on Basescan, then confirm, check the source tab, hand off ownership if you’re on mainnet, and document the address.

If you want to go deeper on any of the pieces here, the related topics in the wiki are Hardhat, Contract Verification, and Gnosis Safe Multisig — all worth reading alongside this guide.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

Welcome to the NZRT Wiki Podcast. Today we’re looking at 🚀 Deployment Pipelines.

If you’ve ever wondered how code travels from a developer’s laptop to a live server without breaking everything, deployment pipelines are the answer. At NZRT, these pipelines automate the process of releasing code to staging and production environments. And depending on which system you’re working with, the approach is a little different.

Let’s start with some key concepts you’ll want to understand.

First, there’s the staging environment. Think of this as a rehearsal space — it mirrors your production server so you can test changes before real users ever see them. The production environment is the live server actually serving customers. A deployment script is an automated script that pulls the latest code and restarts any services that need it. Health checks verify that a deployment actually worked — essentially asking “did everything go okay?” Rollback is your safety net: if something breaks, you revert to the previous working version.

You might also hear about blue-green deployment, where you run two identical production environments and switch traffic between them when you’re ready. Or canary deployment, where you gradually roll out a change to just a percentage of your traffic before going all in. Zero-downtime deployment means handling things like database migrations and cache updates without ever interrupting the live service.

Now let’s look at how NZRT actually deploys its two main systems.

For Dolibarr custom, the process is continuous and triggered daily. A developer creates a feature branch, runs tests, then opens a pull request to the main branch. That pull request needs at least one code review approval before it can be merged. When it’s merged — using a squash merge to keep the history clean — GitHub Actions kicks in automatically. It runs a linter to check code quality, executes tests, performs a security scan, and then deploys directly to the Dolibarr custom environment. Health checks and smoke tests confirm everything is working, and a Slack notification goes out to the team.

The standard Dolibarr deployment follows a similar flow but adds an important safety mechanism: feature flags. A developer creates a short-lived branch, ideally lasting less than three days. Any new feature is wrapped behind a feature flag that starts switched off. After tests pass and the pull request is merged, GitHub Actions runs linting, unit tests, and integration tests, then automatically deploys to production — but the feature flag stays off. The code is live but dormant.

After deployment, the team monitors error logs and performance. When they’re confident everything looks good, they enable the feature flag and monitor again for regressions. If something goes wrong, they can disable the feature flag immediately — that’s the fastest fix — or revert the commit and redeploy.

Now let’s talk about what the actual deployment script does behind the scenes. The script takes two inputs: the environment you’re targeting, either production or staging, and the version number you want to deploy. Based on those inputs, it determines which server to connect to.

It then carries out six steps over a secure connection to the target server. First, it creates a timestamped database backup, so you always have a restore point before anything changes. Second, it checks out the specified version of the code and pulls the latest files. Third, it installs PHP dependencies, skipping anything only needed for development. Fourth, it runs any database migrations that have been queued. Fifth, it flushes the cache so the server isn’t serving stale data. And sixth, it runs a health check by requesting a specific page on the server — if that request fails, the script stops immediately and reports the failure.

If you ever need to roll back, the process is straightforward. You can list all tagged releases to find the version you want to return to, then run the deploy script again pointing at that earlier version tag. If things are really urgent, you can connect directly to the server and revert the most recent commit on the spot.

That covers the full deployment pipeline picture at NZRT — from branching strategies and feature flags all the way through to the step-by-step mechanics of what happens on the server during every release.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.

I.T in Charity