ProductManager @ SpringRole.
Jan 18, 2018. This piece was originally published here
Doing product and dev on cutting edge technologies has its own set of growing pains that we at SpringRole are welcoming with our open arms. In the process of developing our first publicly available feature and having a definitive timeline for the rest of the platform has lead us to brain storm about what process we want to follow when we release features.
Since smart contract codes are immutable and things in the blockchain are permanent in nature — we want to make sure that we spend enough time with each feature (or set of features) before we release it out into our main platform.
Another advantage of giving time to use a feature for a while is that it lets us test it against different levels of user proficiency and see how each of these personas think about the new changes that are there in the platform. Building a blockchain powered platform or application is still in its infancy and so this type of process really gives us an edge to make sure maintain the same rigorous quality that we are used to on the internet.
Lastly, in the blockchain ecosystem, it is difficult to simulate the network conditions that you get in the main-net on your test network. To get the same type of network congestion, block confirmations and gas price is not possible until you actually deploy to the main net and so every step along the way, we try and make sure that we move closer to simulating the mainnet.
Dev — TestRPC
After going through the usual process of product and design cycles, the development team gets going and finishes the feature. While developing the features, the developers run their own testRPC and database on their local machine and make sure that the feature is complete. The devs also do some basic unit testing to make sure that the requirements are met as per what is needed from a product perspective.
Staging — Ropsten
Once dev signs off, the changes are deployed to the staging server — we are using the Ropsten network to simulate the main-net of Ethereum. It is here that QA does their testing and we get some of the users to test out the new feature. Since Ropsten is closer in its behaviour to the main-net than test RPC, it is more realistic to try out all the acceptance testing at this level and only then proceed further. We also use this stage to see how select few users are (of different personas) are interacting with our new feature and this is a great place to see if some of the assumptions we have were not correct.
Beta — SRPMT
Once we are sure that the bugs are ironed out of our features and we are confident, we push our changes on the main net. But there is a difference; we release it to the main website with the use of only SRPMT (SpringRole Pre-mint Tokens) — the pre-mint tokens token that we share with the early enthusiasts of the platform. The SRPMT stage can be thought out as the beta stage of the platform and this is where we can get the reaction and initial feedback from the a smaller set of our users. The important thing to note is that we need this stage as this is the first time we are exposing our feature to the network conditions of the main-net(like block timing, gas cost etc.).
Release– SRT
If there are no hiccups and we are happy with the usage of the feature at the SRPMT level, we roll out the feature onto our normal SRT platform and continue monitoring the usage of the new feature.
We hope you like the way we have thought about systematically releasing our features and rolling them out in a controlled way. Do let us know if you have any best practices that you would want to share.
Comments