Copy of [Release n.n] Release Management Checklist

Background – In order for a release of the FIO protocol to be rolled out on test net and main net, the release manager must first assemble the set of commands that will upgrade the current main net version to become the new release. The commands may include adding actions to FIOs list of allowed contract actions, adding/modifying the fees associated with FIO actions, creating new FIO system accounts and contracts, and updating all of the required FIO contracts with the changes for the new release. The release manager must assemble a complete list of the required commands, and execute them on a private test network, then perform validations of the resulting release. The commands, and test results must be posted on the wiki for this release.

Objective – The objective of dev net testing is to assemble the list of commands required to upgrade FIO for this release, and to complete acceptance testing of a local private FIO network upgraded using these commands.

Tactics – on dev net, build the release version of the FIO Core code and the FIO contracts, copy these off to the side. Then build the dev net using the Main net versions of the contracts and core, and spin up the dev net. Perform all of the necessary clio commands to upgrade the contracts. once this is completed run a regression test to ensure all chain operations function as expected. if there are significant changes to the FIO Core code which result in special logic and timing regarding the core and contracts rollout (this is called a forking change), then special test plans must be made and executed in accordance with the needs of the releases unique needs. If no forking logic is being released then acceptance and QA tests and some performance tests will be performed and published onto the wiki

Deliverables – The release manager will post on the wiki the commands for this release, and they will also post on the wiki the test results for the tests performed.

Contract rollout commands – The release commands for each project included in the release should be a part of the rollout plan for each project included in the release, assemble the commands for the release into one list of commands, and fill any missing gaps by cooperating with the necessary leads if commands have not yet been provided. the following actions are commonly required --

Add action – add an action to the permitted list of actions in the FIO protocol

Add Fee – add a new fee for a new action in the FIO protocol.

Add new system account – When new contracts are added to FIO an owning account must be created.

Set system account authorizations – set permissions and authorizations on new system accounts

Set privileged.

update authorizations

Set Contract – set a new contract on the FIO protocol, or update an existing contract.

Set ABI – set a new ABI on the FIO protocol, or update an existing ABI.

Example:  https://fioprotocol.atlassian.net/wiki/spaces/FD/pages/471040008/New+contract+deployment

See also

 FIO Protocol Developer Hub

Contract testing – After contracts have been upgraded, acceptance testing must be completed, and findings must be published to the wiki.

Fork testing – If there are changes to the protocol which require backwards compatibility considerations then forking tests must be performed, these test require code changes to be made before the fork testing to ensure that the forking logic works equivalently in the dev net environment. Results and findings must be published to the wiki upon completion.

Performance testing – Some projects have dev net level performance test considerations, when a release includes the need for performance testing then tests must be run and findings published to the wiki for the release.

QA testing – QA regression tests should be completed on each release before dev net testing, but full regression on dev net only increases our confidence in a release. findings should be published to the wiki.