[2.7.1 hotfix] Release Management Checklist

Document Description –

This document is intended to assist release managers in tracking the progress of required work items for a given release. Lead developers can use this checklist to understand how they might assist the release manager in achieving a release of the FIO protocol.

Please refer to the field descriptions below the checklist for more information on each item.

Process Description --

Each item that is to be addressed in the checklist should have a story associate with it under the release epic in jira. also there should be a release section of the wiki which contains all of the artifacts generated for a given release, and under this wiki should also be contained all the details of the release planning and execution for future reference of the community.

Checklist Field Descriptions –

Security –

Background – The security of the FIO protocol against DDOS and man in the middle attacks is one of the primary security objectives of the prorftol. The FIO protocol also concerns itself with the many ways that users might attempt to game the provided interfaces in order to gain FIO or to impede the experience of other users.

Objective – The objective of the Security section is to guide the lead developer of each project within a release to perform any of the necessary security testing for a given project. If changes are simple in nature this section may be excluded.

Recommended tactics – Core team members, and other FIO community members may be enlisted to perform security reviews of the changes being proposed by a project. 3rd party security audits are also welcomed on all projects delivering into the FIO protocol. Please contact the release manager if you desire recommendations for 3rd party reviewers. When time and resources permit, there may also be consideration of placing the changes into either a private test instance of the FIO protocol (private test network), or placing the changes onto test net for an extended period of vetting by the community.

Deliverables – Findings for security audit, bounties, and vulnerability tests are sensitive materials and may be published to the public after careful consideration of the consequences of publishing this material. Once vulnerabilities have been adequately addressed all findings and remediations should be posted to the wiki for the project in question. provide a set of links to completed items, or provide a point of contact for your project if items are in work.

Code Audit – A security focused audit of contract modifications should be strongly considered for any new actions, or any modifications to actions that involve changes in authorizations, or error logic. Code audits can be performed by core team members, or they can be performed by third parties specializing in EOSIO security issues.

Vulnerability Testing – The project may benefit from security focused stress testing. This testing may be performed by core team members, or by contracted parties hired for the project. The testing might take an EOSIO specific focus, with the addition of penetration, fuzz, gaming the system, and other vulnerability testing is strongly advised.

Bug Bounty – Your project may benefit from placing a bounty on the contract modifications. Your project should consider offering a reward if any community member is able to discover security flaws, or vulnerabilities in new features. These bounties may be long lived, and they may require the use of private test instances of the fio test net to provide hackers ample opportunity to “break the chain”.

SDK Release –

Background – Changes to Kotlin, javascript, and Golang SDKs may be necessary for each release of the FIO protocol. SDK changes should go through a QA process. The release manager must integrate the SDK changes required for a release, then perform acceptance tests on these changes.

Objective – The objective is to provide integrators with the new features and functions which they will integrate. The release manager ensures that the necessary SDK changes have been rolled up, and that unit testing is successful on the resulting SDK release

Deliverables – The release manager will post testing results on the wiki for each SDK release to provide an audit trail demonstrating the acceptance testing performed on an SDK release.

Kotlin Tests – The release manager will run the unit tests on the release image of the Kotlin SDK and will post results to the wiki.

Typescript Tests – The release manager will run the unit tests on the release image of the typescript SDK and will post results on the wiki

Devnet testing

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

 https://developers.fioprotocol.io/docs/developers/devnet

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.

NOTE – other descriptions may be added if this is seen as helpful for the document