What are the best practices for keeping chain specifications for Devnet, Testnet, and Mainnet environments?

Question

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:

1. Having a separate runtime build for each environment like it is done in the paritytech/polkadot repo.
2. Having a single runtime build for all environments and provide it a specific chain_spec.json file like it is done in the substrate-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?

Answer 1

I would say the approach you can find in the polkadot repo works nicely. Though, you have to find what fits best for your needs.

About your concerns of having one binary that may present problems between dev/test/prod, I would just point to that what is actually different are the runtimes, not really the client itself (or at least, not at all times, maybe you need some host functions at some point - but this can very well be managed in a different branch with changes to the client until it can land in master or whatever you might be using ).

So, what I want to say is that you definitely can have different runtimes for dev/test/prod in the same node, and you will achieve that with a mix of different runtimes, and different chain specs configurations. Though, these different runtimes don't need to live in the same node repo. And at the moment of launching nodes these will be running with the proper spec based on whether they are meant to run in dev/test/prod network.

This read might be of interest to you: https://forum.polkadot.network/t/psa-parity-is-currently-working-on-merging-the-polkadot-stack-repositories-into-one-single-repository/2883