Ignition contracts tracking approach

[marcelomorgado]

Hi, I've be using hardhat-deploy for a while and I'm exploring ignition to see if it would fits well in the project I'm working on.
One aspect I'm checking is regarding upgradable contracts. The hardhat-deploy tracks the contracts' implementations and automatically upgrade it and updates deployments/ artifact if the implementation contract changes. In other words I can keep my contracts and deployment scripts "sync-ed".
As I could see, the ignition approach is different, I would say that it enforces having sequential steps regarding this kind of scenario (i.e., Contract, ContractV2, ContractV3, etc) appending. In essence, every upgradable contract change must generates a new contract file and a new script (aka module) to be appended.
Am I right with my assumptions?
Thanks!

[kanej]

Hey @marcelomorgado, in broad strokes you are correct.
We separate out three concepts:

1. the Solidity source files
2. the Ignition module (which describes a deployment)
3. the deployment folder (identified by deployment-id) containing the state (e.g. abi information, deployment addresses)

An upgrade-able contract flow then likely means modelling the update a new named contract, and either a new module or extending an existing module (keeping the previous Module API calls in place but adding the upgrades at the end). Deploying the updated/new module under the same deployment id will then scan the deployment folder for the state of the previous run, and then resolve what additional on-chain transactions need to be sent.

So yes, the upgrade step has to be modeled explicitly.