Process to Deploy a New Chain

[anna-carroll]

Starting a discussion to document the E2E deploy process we'll use in production, so we can identify points that could be streamlined or automated.

Deploy process broadly goes:

1. Configure new chain
   a. Provision keys for new chain (if not already done)
   b. Load current configuration from published config to local file
   c. Modify local config to add a new network - with provisioned keys
   d. Add overrides for new network to local file
2. Deploy contracts
3. Perform governance actions
4. Publish new config
5. Deploy off-chain actors (in parallel?)
   a. Deploy Agents
   b. Deploy Monitoring Services
   c. Deploy Indexer
   d. Deploy GUI
   e. Deploy SDK

[anna-carroll]

Step 3 - Perform governance actions

There's lots of room for improvement here

Ideal state

• DeployContext pushes governance txs to CallBatch
  • deploy process adds governance actions as script runs
• at end of deploy script,
  • print out unbuilt batch in raw form
  • build batch to get final tx for multisig
  • automagically queue the built tx directly to the Governor Gnosis Safe
• Collect signatures from signers
  • there will always be latency / async process here, but we need to formalize this process and think of ways for signers to be ready when we are deploying and have confidence in what they are signing
• Execute tx on mainnet
• If applicable, execute tx on remote chains
  • there is necessary latency for x-chain message to land
  • we can use the script written to execute the governance actions on remote chains as soon as they land
  • we could consider automating remote execution by running some kind of job that polls for the actions to land, executes them automatically when they do, and notifies us when it's done -- but this is probably much #later

Current State

1. Deploy process will output gov actions to local file
2. These need to be turned into calldata for the GovernanceRouter (we need to fix up the code for doing so)
3. Tx needs to be queued to Governor multisig manually
4. Tx needs to be signed by all governance actors
5. Tx must be executed on mainnet from Gnosis safe UI when signatures are collected
6. In the case that tx needs to be executed on remote chains, we need to fix up the script for doing so

[anna-carroll]

Would like to have a better understanding around the process for Step 4 (publish new config) and Step 5 (deploy all the other stuff) cc @yourbuddyconner @ltchang2019 @kekonen @ErinHales @Imti @arnaud036

[Imti]

@anna-carroll Here are my quick thoughts. Everyone else, please chime in:

Step 4 - update config

@nomad-xyz/config
- update whatever we need to update in the config
- If there are no changes to the existing contracts, publish a patch update to the configuration npm package

If the config **_has a breaking change_**
- do the below steps change at all?
- We control when we update a package, so I’m guessing nothing changes. Wanted to call this out in case I’m missing something.

If the config **_does not have a breaking change_** 
- do the following steps

Step 5d - update sdk packages (can be done in parallel)

@nomad-xyz/sdk
- bump config package
- publish new version

@nomad-xyz/sdk-bridge
- bump config package
- bump sdk package (workspaces ftw, no action needed)
- publish new version

@nomad-xyz/sdk-govern
- bump config package
- bump sdk package (workspaces ftw, no action needed)
- publish new version

@kekonen The indexer relies on the above packages, can we safely update in parallel here as well?

Step 5e - update gui (must be done last)

gui is not a part of the monorepo workspace so the dependencies must be updated manually here and only when the above packages are published to npm

gui
- bump config package
- bump sdk package
- bump sdk-bridge package
- add any additional tokens needed
- Make release PR and merge to deploy to prod

[luketchang]

Step 5e (continued)

Agents: 
- bump configuration crate versions across all crates (`cargo update`)
- redeploy agents

Indexer:
- redeploy indexer under new commit hash, which would be the result of step 5d (no bumping versions since indexer is in the yarn monorepo)

[yourbuddyconner]

We should probably still pin versions in the indexer just to be safe, but luke's comment is accurate given the current state of things.

Something like workspace:0.1.0

[mh-1024]

@anna-carroll
What are the provision keys here?
Those should be updated into the config for the new chain?
Thanks.

[samisbakedham]

Starting a discussion to document the E2E deploy process we'll use in production, so we can identify points that could be streamlined or automated.

Deploy process broadly goes:

1. Configure new chain
   a. Provision keys for new chain (if not already done)
   b. Load current configuration from published config to local file
   c. Modify local config to add a new network - with provisioned keys
   d. Add overrides for new network to local file
2. Deploy contracts
3. Perform governance actions
4. Publish new config
5. Deploy off-chain actors (in parallel?)
   a. Deploy Agents
   b. Deploy Monitoring Services
   c. Deploy Indexer
   d. Deploy GUI
   e. Deploy SDK

Are you able to elaborate here: > a. Provision keys for new chain (if not already done)