near / devx

This is the home of NEAR collective developer experience plans and roadmap.

11 stars 0 forks source link

Migration Testing Docs #165

Open stefanopepe opened 4 years ago

stefanopepe commented 4 years ago

As a Validator I need DB Migration Tests Tools, such that I can verify the integrity of my application after a node update

Validators run their own infrastructure and tooling (even custom binaries), which includes the creation of custom databases for transactions, smart contracts state, and network stats. An important issue is to verify the integrity of their platform when they deploy a new release of the node (specifically, what is returned by the RPC).

Acceptance Criteria:

[ ] A documentation page similar to this one explaining how we do our tests before deploying a new release of the node on our infrastructure (e.g. wallet and block explorer)
[ ] Links from this document to Nomicon, to help validators build their own verification tools

What is Out of Scope:

building and maintaining tools for validators
changing any internal process

stefanopepe commented 4 years ago

Updated today cc @potatodepaulo Needs Estimation and card owner

amgando commented 4 years ago

can you say more about what is being documented? like, how does anyone actually validate a node?

a fast way to capture this might be to ask a core dev to record themselves while validating a node and talking out loud about the process and their choices.

loom.com is useful for sharing recordings easily.

stefanopepe commented 4 years ago

When we fork/update a node using a new release, we change nearcore binary. What we need to document is how we check if the information in the ~/.near/betanet/data is giving the exact same RPC results regardless of the nearcore release.

The problem is that professional node operators use our RPC to manage exchanges, staking platforms, and other services that might break after such an update. They need to know how to verify themselves, and promptly intervene on their database if something changed.

I like the idea of using tools like loom to give context and explain how we (as NEAR team) check that a new release of nearcore is not breaking our wallet/explorer/shell and other middleware.