GovTool environments vs networks

[Ryun1]

What ?

• GovTool is only configured for SanchoNet currently
• In the near future there will be other networks which support governance, we want to deploy instances of govtool to these networks
• If we are deploying GovTool across multiple networks, what sort of environments should we consider?

Proposal 1st step (add preview)

• We keep using Sancho as primary network
• A separate staging is used for Preview, where a final manual check can be done, before deploying to Preview production

Proposal Future (add preview and mainnet)

• Once code is fully working on Preview production, then it can be moved to mainnet environments
• I feel like this is a minimum viable setup, bypassing PreProd network

[kickloop]

@Ryun1 As discussed via call, we should aim for standard environments:

• dev.gov.tools
• qa.gov.tools
• preprod.gov.tools
• gov.tools (prod)

As for the network, each instance of our dApp should be able to connect to all. dApp is network agnostic and the network should be a matter of config - a simple env. var passed to the dApp OR which ever network is connected via wallet.

Then we should definitely handle the wallet or network incompatibility in the dApp... If dApp is connecting to a network which is not gov-ready or if incompatible wallet is used - we need to have a meaningful info/notification for a user.

Further more, our DEV and QA should never connect to Mainnet or the PROD should never connect to Preprod... At this time, Sancho is, for all intents and purposes our Mainnet and we should treat it as such. Our "beta" is only a construct, and we don't need to have a domain prefix "beta" for it... We might as well simply run our BETA on gov.tool and have a notification on a screen informing users that we are in beta... Eventually when we are not in beta anymore, nothing changes - except the underlaying network in the background!

In other case... if we have something like beta.gov.tools and then sancho.dev.gov.tools and about 14 more {env}.{network}.{domain} combinations... we will have to manage 3-4 times more environments but also pay 3-4 times more for the infra (thousands of EUR per month) for basically no benefits... Arguably, even if a domain is beta.dev.sancho.gov.tool it only means something to US... to regular Joe out-there... it does not mean a thing :) But for regular Joe, when he visit gov.tools and then have a modal overlay notification "Hey. We are in beta. You are connected to Sancho network"... OR "Hey. We are in beta. Please use compatible wallet (and then the link to more details)...

cc @l-br1 @bosko-m

[Ryun1]

I find two issues with your approach;

Confusion for users (and ourselves)

Having a known instance of GovTool (gov.tools) switch between networks, is just confusing for users and us.
It is standard practice with Cardano infrastructure to namespace domains via networks, people are very used to this (prevew.cardanoscan / preprod.cardanoscan)
Popups in GovTool explaining which network it is on, is not an ideal fix for this IMO.

I can already seeing myself replying to multiple messages a day, asking why their wallet doesnt work on GovTool anymore.

Added complexity for testing across networks

Different networks have different purposes and will have different features deployed at different times.
This means that we want / need to have different instances of GovTool on different networks at different time.
For example; SanchoNet will have full governance, whereas Preview will be in bootstrapping mode - we will want to test GovTool against both modes of governance.
Having a few instances of GovTool means we will have to continue to switch which network each is connected to, spinning up and pulling down instances often.
This just generally adds a lot of complexity in management and coordination.

As for the network, each instance of our dApp should be able to connect to all. dApp is network agnostic and the network should be a matter of config - a simple env. var passed to the dApp OR which ever network is connected via wallet.

The codebase is network agnostic (can be deployed to any network), but each instance when deployed can only connect to one network at a time.
So per instance/domain we have to choose a network, there is no easy way for GovTool to switch between.

which ever network is connected via wallet.

due to a limitation of CIP-30's design, GovTool (or any Cardano dApp) cannot easily differentiate between which test network the wallet is connected to.
so we cannot reject wallets connected to the wrong testnet, we can only advice, this is dangerous as the user will only find out theyre on the wrong network at transaction submit time

[Ryun1]

For testnets;
{service}.{pillar}.{environment}.{network}.gov.tools

For SanchoNet;
{environment}.sanchogov.tools

For mainnet:
{environment}.gov.tools

Sancho

• dev.sanchogov.tools (Dev env on Sancho)
• test.sanchogov.tools (QA env on Sancho)
• staging.sanchogov.tools (Staging/preprod env on Sancho)
• sanchogov.tools (Public production env on Sancho)

Preview

• staging.preview.gov.tools (Staging/preprod env on Preview network)
• be.staging.preview.gov.tools

Mainnet

• staging.gov.tools (Staging/preprod env on mainnet)

[Ryun1]

see latest proposal below

[Ryun1]

@kickloop and myself have worked to create a refined minimal proposal.

differences, to my first proposal;

• reduced number of environments, less overhead in time and cost
• piggy backing the natural hierarchy of the networks
• this is a minimal proposal, open to adding additional environments as the needs arise

Notes

• we can route sancho.gov.tools to sanchogov.tools

[bosko-m]

I think that this is a great and easy to digest proposal. Makes complete sense. Again, I suppose no PreProd, right @Ryun1 ?

[Ryun1]

No Preprod!!!

[Ryun1]

see latest proposal below

[Ryun1]

GovTool Proposed Networks / Environments

For the coming weeks, then can be iterated upon

Notes

• We are happy to run load testing on the existing preview it can die!
• For sancho, preview and mainnet all deployments will come from the main branch
  • With deployments being tracked via tags
• In the near future versioning will be done via CI based on commit messages, using conventional commits
  • on PRs tags can be built and attached

Summary Table

Environment	Network	Branch	User facing domain
dev	sancho	develop	N/A
test	sancho	test	N/A
staging	sancho	staging	N/A
sancho	sancho	main	sanchogov.tools
preview	preview	main	preview.gov.tools
mainnet	mainnet	main	gov.tools

[Ryun1]

Domain expression

{be-service}.{govtool pillar | tool}.{environment}.{network}.{gov.tools | sanchogov.tools}

Component	Definition	Examples
{be-service}	Backend service, only used for non-user facing domains	metadata for govtool, be for pdf
{govtool pillar or tool}	GovTool pillar OR CC Portal OR nothing for the existing govtool monolith	proposal for pdf, constitution for cc-portal
{environment}	The purpose of the environment, not used for user facing environments	dev, test, staging
{network}	The network that the instance is connected to, not used for sanchonet and not used for mainnet	preview
{gov.tools or sanchogov.tools}	The base domain, sanchogov.tools is only used for Byron hosted envs, gov.tools is for everything else	gov.tools or sanchogov.tools

Example, for GovTool+PDF on preview user facing env:

• preview.gov.tools (GovTool+PDF frontend - user accessible)
• be.preview.gov.tools (GovTool BE)
• metadata.preview.gov.tools (GovTool BE metadata service)
• be.proposal.preview.gov.tools (PDF BE)

[l-br1]

this was sorted