Testing and Releasing Stable Ethereum Applications

Inspired by a similar post from SpringRole, who shared their process to deploy production code, I wanted to share the result of AirSwap’s own extensive internal discussion about how to create and deploy stable features for Ethereum-driven applications.

And now we do!

Blockchains are immutable and using them incurs costs, so testing is a challenge. On the Ethereum platform, there is a main chain called Mainnet and multiple test chains, each with their own features that can make development easier or harder. This is an amazing Stackoverflow write up on the differences.

At AirSwap, we use the Rinkeby network for testing new products and features. Rinkeby has its own “test” ether, so we suggest to our testers to use what is known as a faucet. Additionally, we have team and community members who will gladly send you test ether simply by joining our Telegram group and asking!

So why else does this test net matter?

When you are working with the main net or test net, you can have many different behaviors from the “black box” that is the network processing your state changes. Gas costs, timing, and even code execution and responses can be different. The goal of testing both with “paper money” — test ether in this case — and real ether is to ensure that your infrastructure and code respond the same way on each network.

This variable increases the complexity beyond a simple development/production or even development/staging/production environment set up that may be familiar to engineers. We have added a fourth environment in our own set up.

A breakdown by environment and Ethereum network

• Development: This is the first place that our code is deployed for internal testing. We build this every time someone merges into our development branch. Generally, this is built multiple times per day.
• User Acceptance Testing (UAT): This is the first place that our beta users get to see our new features. We believe in being as transparent as possible, but we don’t want our beta users to bear any costs associated with new code causing failures. Because of this, we release new features for beta preview in Rinkeby and in test ether.
• Staging: This is our internal testing environment for the broader team. QA final approval as well as business team approval happens here. This environment is not open to the public since it uses real money. This is the same code that UAT runs, but it happens on mainnet.
• Production: This is the final step in our code deployment and for the general public to use. It runs on mainnet.

Our build pipeline focuses on quickly moving stable features to UAT where we receive valuable feedback from our beta testers. When promoting code to staging or production, because those environments run on Mainnet with real ether, we confirm each code deploy before it happens.

So does this set up work for deploying stable code? In the last week, we have successfully executed more than 5 deploys per day of each of our services — sometimes up to 30 deploys per day total. From testing on Rinkeby then doing a quick check on mainnet, we are happy to share that we have not lost any real ether due to code issues — but more importantly none of our beta users have lost any ether due to code issues.

As we continue to release features and products, we will refine this process to provide the best possible experience to our users.

Look for more discussion from our engineering team as we continue to develop our platform!

About AirSwap

AirSwap enables peer-to-peer trading on the Ethereum blockchain. Built on a decentralized protocol, traders can add or remove liquidity through a suite of trustless products that are easy to use and free. Our mission is to empower the world with frictionless trade.

Blog | Twitter | Discord | Developers | Makers | Reddit | Facebook | Linkedin | Subscribe | Support | Request a Feature | FAQ | Trade Now