can anybody help me to understand what questions I should address before choosing the approach for keeping the runtime configuration for Devnet/Testnet/Mainnet environments in a substrate-based Solochain?
From what I learned so far, there are 2 main approaches for organizing the runtime in substrate-based repo:
- Having a separate runtime build for each environment like it is done in the
paritytech/polkadot
repo. - Having a single runtime build for all environments and provide it a specific
chain_spec.json
file like it is done in thesubstrate-developer-hub/substrate-node-template
repo.
The above approaches can be even mixed, based on what I see in the polkadot node repo.
As far as I understand, the approach with separate runtime builds looks reasonable when your Devnet/Testnet/Mainnet environments have a different composition of pallets. For example, it's good when a team is working on a new custom pallet that is available in Devnet, but it's not ready for the Testnet and Mainnet yet. But isn't this approach leads to a lack of consistency between different node executables? Can't it result to production Mainnet errors, that could not be detected preliminary at Devnet/Testnet because of differences between node executables?
I think, that having a single binary for Devnet/Testnet/Mainnet environments is a more reliable approach, and there is a guarantee that the node executable is well-tested before deploying it to Mainnet. But I see that the official polkadot node repo utilizes the approach with separate builds for its Polkadot/Kusama/Rococo/Westend networks, and I want to understand is this approach reasonable for a substrate-based Solochain and wouldn't it be overhead?