| | Tasks | Deliverables / Notifications |
---|
Links | | | |
Dev Epic or Story | | Project manager will create initial Epic or Story |
BD-3758
-
Getting issue details...
STATUS
|
FIP Wiki | | Project manager will create FIP Wiki | [FIP-43] Update get_fee validation |
Development Stories | | - Subtasks/stories created for items in the Development Milestone Checklist
|
BD-3851
-
Getting issue details...
STATUS
|
Github repo | | - Create bug/feature branch
See: https://developers.fioprotocol.io/docs/developers/git | |
Requirements, Design, and Scoping | | | |
Meeting - Kickoff meeting | | - Kickoff meeting held with Product Manager to review requirements
| |
Complete FIP (if applicable) | | - FIP reviewed and moved to Accepted status
| |
Complete functional / technical design | | Design Draft should include a first draft of all elements outlined in the Development Spec. | |
Scoping | | - Create project stories for development for each of the remaining tasks that are included with the release
- 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 | | | |
Design review | | - Functional spec approved by architecture champions and team
| |
Finalize FIP | | - FIP updated with any changes resulting from design review
| |
Development | | | |
Project management | | - Maintain status in Epic Summary
| |
Development | | - Create draft feature branch off of develop or other target branch (e.g., feature/fip6-lock-tokens)
See: https://developers.fioprotocol.io/docs/developers/git | |
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.
| |
Update FIP (or development document) | | - FIP / development spec updated to reflect the details of the implementation
| |
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
| |
Code review | | - Once code is complete, request 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.
| |
Unit Testing | | | |
Action and getter testing | | - fio.test test branch created
- fio.test enhanced with initial action and getter tests
- Tests run cleanly
| |
Performance testing | | - First level performance testing results reviewed with architecture champions (can be performed on dev machine, try to uncover any obvious perf limits)
| |
Release Plan | | | |
Msig deployment | | - Create wiki page in Releases directory to track any msigs needed to deploy the feature
Example: [fio 3.3 fio.contracts 2.7] Release script | |
QA | | | |
Handoff to QA | | - Review code and unit tests with QA and Release Management.
| |
UAT | | | |
Merge to develop and install on DEV | | - Rebase feature branch and merge to develop or feature branch for UAT testing
- Install release on DEV server
This is a developer 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. | |
Feature complete | | - All bugs and outstanding items completed
- Work with QA to confirm JS tests run cleanly against DEV server
| |
Product signoff | | - Signoff from Product Management
This is feature or bug specific signoff from Product Management so is controlled by the lead developer. | |
Devnet | | | |
Devnet testing | | - Work with release engineer to fully test any new contracts and actions.
| Devnet testing is tracked in the Release Milestone Checklist |
Testnet | | | |
Test planning | | - Work with release team to ensure correct Testnet rollout (addaction, setfee, contract updates, etc).
| See Release Milestone Checklist |
Testnet rollout verification | | - Perform the Testnet rollout verification for the feature and report findings (add results to Dev Spec)
| |
Mainnet | | | |
Test planning | | - Work with release team to ensure correct Mainnet rollout (addaction, setfee, contract updates, etc).
| See Release Milestone Checklist |
Mainnet rollout verification | | - Perform the Mainnet rollout verification for the feature and report findings (add results to Dev Spec)
| |
0 Comments