What to do
Creating a CorDapp is enough work already, why worry about upgrades? Because if your app is successful, then over its long life it will have to adjust.
What could need changing or upgrading?
- Your Corda node. If backward compatibility is maintained by the R3 team, then node upgrades should be painless. Make sure, though. No one can be certain that there will never be a breaking change.
- Your CorDapp's self-knowledge. You may test it again for regression for a new Corda version, and then advertise this fact.
- The network parameters. As the network, on which your app runs evolves, your node and your app need to be compatible with them. Possibly adjusting your unit tests too.
- The flows. Eventually, you may want to review them, such as add or remove features. Unlike a state, and the contract that controls it, an in-flight flow is not a long-lived entity. Therefore as long as you have drained your node of old in-flight (checkpointed) flows, you can swap out the JARs. If you also change the interface you will need to explicitly make them backward compatible.
- The states and contracts. Perhaps you want to add a field, a command, or update the checks. Unlike flows, states are long lived and need to be verified in the future. For past states, as long as the JAR, referenced by hash in the transaction, is available somehow, the transactions that created them can be verified. But for your new states, can you just force a new JAR for a transaction that consumes your older state? If you signed your CorDapp, then yes, it is as easy as replacing your contracts CorDapp with its next version in the
- States schemas. If you implemented a schema to your state, you may have to make an effort.
- Your db. See these guides on db migration from a development and production perspectives. With the associated videos 1 and 2.
Unfortunately, to test your upgrade procedures, you will have to deploy a local test network, perhaps via
deployNodes, and perform the upgrade there.