Page Comparison

Definition

Dev Epic or Story

PM

• Create initial Epic or Story

FIP Wiki

PM

• Create FIP Wiki

[FIP-46] FIO read performance

Stories

PM

• Create stories and subtasks

Subtasks/stories created for items in the Development Milestone Checklist

Requirements and Scoping

Kickoff meeting

PM

• Kickoff meeting

Kickoff meeting held with Product Manager to review requirements

Complete FIP (if applicable)

PM / Dev

• FIP reviewed and moved to Accepted status

Master Release Schedule

PM

• Update master release schedule with feature actions and endpoints

Design and Scoping

Complete functional / technical design

Dev

• 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: [FIP-nn] Development - Spec

Scoping

Dev

• 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

Dev

• Functional spec approved by architecture champions and team

Finalize FIP

Dev

• FIP-NN Finalize FIP

Update FIP with any changes resulting from design review

Development

Complete development

Dev

• 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: https://developers.fioprotocol.io/docs/developers/git )

• Create draft PR for branch

RAM bumps for new actions

Dev

• 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

Dev

• 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

Dev

• 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)

Dev

• 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

Dev

• 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

Dev

• 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: [FIP-nn] Deployment and rollout guide

Unit Testing

Action and getter unit testing

Dev

• 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

Dev

• 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

Dev

• 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

Dev

• Handoff to QA

Review code and unit tests with QA and Release Management.

SDKs

SDKs

PM

• SDK updates

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

N/A

QA

Handoff to QA

QA

• Handoff to QA

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

Create Test Cases

QA

• Create test cases

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

Meeting - Test plan review

QA

• Test plan review

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

Feature Testing

QA

• 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

QA

• Performance testing

Complete performance testing, including:

• Work with Dev Lead to create performance test plan

• fio.test enhanced with performance tests

History node testing

QA

• 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: https://github.com/fioprotocol/fio/pull/363/files

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 http://bloks.io shows the appropriate transaction history.

QA test review

QA

• QA test review

System and performance tests and results reviewed with Dev team

UAT

Merge to develop and install on DEV

PM

• 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

QAPM

• System testing

Complete system testing, including:

• All bugs and outstanding items completed

• JS tests completed and run cleanly against DEV server

Feature complete

PM

• Confirm feature and QA complete

Confirm all bugs and outstanding items completed

Product management

PM

• Product Management signoff

Get signoff from Product Management

Testnet

Testnet rollout verification

PM

• Testnet rollout verification

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

Mainnet

Mainnet rollout verification

PM

• Mainnet rollout verification

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