[FIP-46] Milestone Checklist

Definition

Dev Epic or Story

• Create initial Epic or Story

https://fioprotocol.atlassian.net/browse/BD-4057

FIP Wiki

• Create FIP Wiki

https://fioprotocol.atlassian.net/wiki/spaces/FD/pages/546701320

Stories

• Create stories and subtasks

Subtasks/stories created for items in the Development Milestone Checklist

https://fioprotocol.atlassian.net/browse/BD-4260

Requirements and Scoping

Kickoff meeting

• Kickoff meeting

Kickoff meeting held with Product Manager to review requirements

Complete FIP (if applicable)

• FIP reviewed and moved to Accepted status

Master Release Schedule

• Update master release schedule with feature actions and endpoints

Design and Scoping

Complete functional / technical design

• Functional / Technical design

Complete technical design and save to wiki. Design draft should include a first draft of all elements outlined in the Development Spec.

Template:

Scoping

• Estimate stories

Each story should be unit of work that is deliverable in a 2 week sprint. An initial estimate should be included with every development story.

Design review

• Functional spec approved by architecture champions and team

Finalize FIP

• FIP-NN Finalize FIP

Update FIP with any changes resulting from design review

Development

Complete development

• Complete development

Complete all development for feature. This may include multiple stories and subtasks for larger features. Include link to PR in story.

Includes

• Create bug/feature branch off of develop or other target branch (e.g., feature/fip-16-lock-tokens, See: )

• Create draft PR for branch

RAM bumps for new actions

• Determine RAM allocation for new actions and set RAM bump accordingly. This informationshould be added to the FIP.

See: https://developers.fioprotocol.io/docs/developers/ram

Fees for new actions

• Estimate initial fees for all actions.

In cases where the action requires additional RAM, the fees should be correlated with the RAM estimates. This informationshould be added to the FIP

ABI validation

• ABI Validation

Validate json for any new ABIs or ABIs that have been updated

If deploying new contract, make sure ABI copy command is in fio.devtools contracts/build.sh

N/A

Update FIP (or development document)

• FIP-NN Dev - Update FIP and development spec

Update the FIP and development spec to make sure they are aligned with the latest code. This includes making sure the error messages are the same between the code and the FIP.

Code review

• Code review of PR from all core devs, release management, and QA

FIO does DAC-style code reviews wherein the following core team members are required to review all major PRs:

• Core developers - Full review

• Security - Full review. TBD on how this will be handled.

• QA and Release Management- Summary review to acknowledge understanding that the feature is in development

If a developer approves a PR, it is assumed that they have taken the time to do a thorough review. Just checking the box is inadequate and puts the chain at risk. If a bug or structural issue escapes, we will be taking joint responsibility for not finding it during our reviews. If a developer wants to dig deeper and has questions for the main developer, they should initiate a discussion with the developer.

Deployment guide

• Create deployment rollout guide. This is used by release management during testnet and mainnet deployments

Includes:

• New actions (addaction)

• New fees (createfee)

• List of contracts modified

Template:

Unit Testing

Action and getter unit testing

• Action and getter unit tests

Includes initial development of unit tests for handoff to QA:

• Create fio.test branch and draft PR for initial unit tests created on fio.test (e.g., feature/fip-16-lock-tokens)

• Development of initial action and getter unit tests

• Tests run cleanly

Performance testing

• Performance tests

Create first level performance testing results reviewed with architecture champions (can be performed on dev machine, try to uncover any obvious perf limits)

QA test guide

• QA test guide

Add testing info to this story for QA. This is a brainstorming list of items from the developer to make sure specific items are tested. Includes:

• Note any areas of existing code that are impacted by the new feature and should be tested as part of this feature testing

• Any use cases that need to be included

Handoff to QA

• Handoff to QA

Review code and unit tests with QA and Release Management.

SDKs

SDKs

• SDK updates

Create epic/stories to track SDK Release (if changes are needed for new features)

N/A

QA

Handoff to QA

• Handoff to QA

Review code and unit tests with Dev (and release management)

Create Test Cases

• Create test cases

List out all the test cases in a subtask attached to the QA story

Meeting - Test plan review

• Test plan review

Meeting held with Dev Manager and Lead Dev to review test plan

Feature Testing

• Feature testing

Complete feature testing, including:

• fio.test enhanced with functional tests

• Tests run cleanly

• Functional tests well documented (in fio.test) and reviewed with team

Performance testing

• Performance testing

Complete performance testing, including:

• Work with Dev Lead to create performance test plan

• fio.test enhanced with performance tests

History node testing

• History node testing

Test against node with V1 History and confirm no errors in log file (add results to Dev Spec)

For transactions that automatically create accounts (e.g., regdomain) if the public key used is new, we need to make sure that the correct entries are added to the the history_plugin.cpp. See for example:

To test, the transaction should be run, and a history get_actions for the target account should show the (regdomain, etc.) action.

When released to testnet, it should be confirmed that shows the appropriate transaction history.

QA test review

• QA test review

System and performance tests and results reviewed with Dev team

UAT

Merge to develop and install on DEV

• Install release on DEV server

Install release on DEV server. This is a task to ensure that their feature or fix is on a publicly accessible DEV server so it can be reviewed by Product Management. This should be done after system testing is complete.

System testing

• System testing

Complete system testing, including:

• All bugs and outstanding items completed

• JS tests completed and run cleanly against DEV server

Feature complete

• Confirm feature and QA complete

Confirm all bugs and outstanding items completed

Product management

• Product Management signoff

Get signoff from Product Management

Testnet

Testnet rollout verification

• Testnet rollout verification

With developer, perform the Testnet rollout verification for the feature and report findings in story

Mainnet

Mainnet rollout verification

• Mainnet rollout verification

With developer, perform the Testnet rollout verification for the feature and report findings in story