... | ... | @@ -70,28 +70,29 @@ When changes are requested after approval, the issue is weighted again and any o |
|
|
|
|
|
## Development
|
|
|
|
|
|
All issues ready for development are on the [Development Board](https://gitlab.coko.foundation/ncbi/ncbi/-/boards/324)
|
|
|
All issues ready for development, after scope approval, are on the [Development Board](https://gitlab.coko.foundation/ncbi/ncbi/-/boards/324). Any issue in "Dev: to do" can be picked up, but the priorities are the issues in the current [milestone](https://gitlab.coko.foundation/ncbi/ncbi/-/milestones). Coko project managers may reschedule an issue if the scope changes.
|
|
|
|
|
|
Development begins on the issue when the relevant cycle starts (See [Milestone](https://gitlab.coko.foundation/ncbi/ncbi/-/milestones)). Dione may reschedule an issue if the scope changes.
|
|
|
|
|
|
### Development phases:
|
|
|
|
|
|
Issues are added to the Dev board after scope approval and weighting. Any issue in the "Dev to do" can be picked up, but the priority are the issues in the the current milestone.
|
|
|
### Development and QA phases:
|
|
|
|
|
|
1. Dev to do →
|
|
|
2. Dev Doing →
|
|
|
3. Dev Blocked (when relevant) →
|
|
|
4. Dev QA (assigned to @sidorelauku) →
|
|
|
5. Dev QA fixes →
|
|
|
6. Dev Done →
|
|
|
7. Dev Dione QA (check on staging)
|
|
|
|
|
|
Dev is 'done' when it its been tested and meets the sign-off criteria in the issue description.
|
|
|
1. Dev: to do →
|
|
|
2. Dev: doing →
|
|
|
3. Dev: blocked (when relevant, assign back to Coko project manager) →
|
|
|
4. QA: to do →
|
|
|
5. QA: doing →
|
|
|
6. Dev: QA fixes → (when relevant, assign back to developer)
|
|
|
7. QA: passed → (ready to be merged to `develop` branch)
|
|
|
8. QA: ncbidev (when relevant, final check on ncbidev)
|
|
|
9. Dev: Done (ready to be merged to `staging` branch)
|
|
|
|
|
|
* Issues move from "Dev: doing" to "QA: to do" when the assigned developer has completed and tested the functionality in the issue description on the feature branch, this includes writing unit tests when relevant.
|
|
|
* Issues are considered "QA: passed" when the branch has been tested and the intergation test is done.
|
|
|
* Issues are considered "Dev: Done" and can be closed when tested on `ncbidev` site and the feature meets the BCMS sign-off criteria in the issue description.
|
|
|
|
|
|
#### How we manage branches:
|
|
|
|
|
|
We have two main branches:
|
|
|
* 'master' - the code here is stable and matches with the code of the application that the client sees.
|
|
|
* 'develop' - the code here is less stable than the master branch since it is work-in-progress. Tested code in this branch is merged into 'master' for client reviews.
|
|
|
* Each issue is developed and tested in its own branch before being merged into 'develop'.
|
|
|
1. `develop` - the code here is less stable than the `staging` branch since it is work-in-progress.
|
|
|
* Each issue is developed and tested in its own branch before being merged into `develop`.
|
|
|
* Tested code in this branch is merged into `staging` for client reviews.
|
|
|
2. `staging` - the code here is stable and matches with the code of the application that the client sees.
|
|
|
|