A few months ago I asked the same thing. During that time, the Superblocks team was working on an online IDE to onboard people into the blockchain programming paradigm. Yet after some good honest feedback and reflection, we found the need to shift our strategy in order to become a sustainable company long term.
To do this right, we decided to embark on a research journey in which we interviewed dozens of people across the industry, from professional developers working for high profile blockchain companies to amateur developers with no previous experience developing decentralized applications. We read all the secondary research material we could find on the internet. We mapped out everything in a shared board for the team to visualize the overall ecosystem of tools and services in Web 3.0. Finally, we examined the traditional Web 2.0 services and where they succeeded/lacked to meet the needs of blockchain developers.
There is a thin and convoluted line between web 2.0 and web 3.0. Many services don’t need to be reinvented, but some certainly do, including continuous integration and continuous deployment (CI/CD).
We will share all our research findings in subsequent posts, so hit the Follow button to stay tuned!
Recently we posted in Reddit seeking collaborations and feedback from the community. Within a couple of hours, an ethdev community member asked:
Not sure how much this gives over Jenkins or Travis CI. Also usually deployments are incredibly rare, maybe once a quarter if even that often for the smart contracts. I’m not certain what monitoring the health of a smart contract even means in this context. It sounds like a copy and paste or what a normal CI would be, without understanding the needs of Blockchain devs
The comment has valid concerns. It also got me writing this blog post as it deserves a better explanation than what can be found in a short FAQ.
Should we use traditional CI/CD services for smart contracts?
During our research, we analyzed the core CI services on the market(Jenkins, TravisCI, CircleCI, Azure Pipelines, CodeFresh, Gitlab, AppCenter). They are all great services (in fact I have used happily some of them for years) which meet certain demands for a blockchain developer like building and testing your contracts (the CI part).
But that’s pretty much it.
As the Reddit comment points out, we might need to rename the CD part in our tag line to “Release Management”. Contracts are something you barely, if ever, will update. When developing smart contracts, embrace the waterfall. This is quite contrary to your normal tech stack where the norm has shifted to extreme agile development in recent years.
Yet, by no means will these traditional services coupe with everything a blockchain developer needs. They need more features than CI to suffice for smart contracts.
Ask yourself, how are you releasing your contracts securely? If you don’t have an on-premise setup for TravisCI/CircleCI/etc, you shouldn’t be putting your private keys in their service as environmental variables to be made available to their runners. So then, how can you perform a release of a contract in a shared environment without actually exposing your private keys in their service?
That’s where the magic will happen and subtle differences start to emerge.
What “CI/CD” actually means for smart contracts
First of all, you should never have to trust a 3rd party with your keys, not even your CI/CD service. Then there should be features which can minimize the risk of deploying a faulty implementation to a public network; automatic security checks, deployment safeguards (like test coverage, security issues, and auditor approval). These should be strictly enforced and routinely followed in a formalized process.
At Superblocks, we are working on a solution in which you will be able to promote a build to be deployed to either a private or public network (Testnet or Mainnet) without your keys being exposed. A secure tunnel is created in which you will locally sign the contract/transactions directly in your computer (Metamask, Trezos, etc) and we will simply proxy it to the runner.
Once you have deployments performed securely, this is where things start to shine. It is also where the term “CI/CD” starts to subjectively become too narrow of a definition.
You should be able to trace a contract (or a change to a contract), from a commit all the way directly to the blockchain (and their analytics) within one system. Once you have built/tested/deployed your contracts you should have the capabilities to:
- Directly interact with your contracts using the secure tunnel to your keys.
- Monitor the contract to see transactions, state, and events.
- Configure notifications for errors and anomalies such as failed transactions or balance changes.
- Set up custom metrics adapted to the specifications of your contract.
I’d suggest we take it even further. There is an array of other features that can help streamline the entire process and is the core reason why we chose to create our own role-based-access control system in the Superblocks platform. For example, how are auditors involved? What about regulators (relevant in multi regulatory scenarios in which operations are performed in different jurisdictions)? How about community backers, contributors, or users behind a project?
In reality, there is no CD part for smart contracts
As such, we see ourselves leaning more towards holistic services like AppCenter, Bitrise (which are specific platforms for mobile developers) or CodeFresh (DevOps for Kubernetes) but for blockchain instead. In our service, we are working on features adapted specifically for the smart contracts life cycle and needs.
Of course, we are always open to more suggestions and features you guys would like to have, so please feel free to either reach out directly to me or any of my colleagues or post in our Community Forum. We very much appreciate all input, it helps us build more useful things.
Thanks for reading!
P.S: I will soon release a blog post called MVP and Microservices, is it really worth it? in which I will share our journey, experience, and some tips when building an MVP using a Microservices architecture for our system. Stay tuned!