| 1 | | sub-page |
| | 1 | = Definition of Done for Feature Branches = |
| | 2 | The definition of done is an agile document that clarifies what it means for a set of development work to be completed. It is both a check list and a set of guidelines that should be followed. |
| | 3 | |
| | 4 | == Development Practices == |
| | 5 | * Code has followed the style guide for BOINC (http://boinc.berkeley.edu/trac/wiki/CodingStyle) |
| | 6 | * Does not contain unrelated code changes |
| | 7 | * Uses atomic commits (https://www.freshconsulting.com/atomic-commits/) |
| | 8 | |
| | 9 | == Testing == |
| | 10 | * The code compiles on relevant major platforms (this should be available via automation) |
| | 11 | * For Client or API it builds on reference systems (Ubuntu 14.04LTS, OSX 10.11, Windows Visual Studio 2013) (enabled via Travis CI and !AppVeyor) |
| | 12 | * For Server it builds on reference systems (Ubuntu 14.04LTS) |
| | 13 | * The code passes all existing automated build and unit tests |
| | 14 | * The developer has tested the code in a working environment (i.e. ran the client code with a project, tested server changes against an alpha project, etc) |
| | 15 | |
| | 16 | == Documentation == |
| | 17 | * The pull request to merge a branch should list the issue(s) that it fixes. (Use keywords to link the pull request to issue: https://help.github.com/articles/closing-issues-using-keywords/) |
| | 18 | * If this code changes the available features or behavior of the system, then the documentation on the BOINC wiki needs to be updated to reflect that (reference the version it belongs to) |
| | 19 | |
| | 20 | = = |
| | 21 | = = |
| | 22 | = = |
| | 23 | ---- |
| | 24 | = Pending - Not Yet Applicable = |
| | 25 | The following will be added to the definition of done when the necessary automation and configuration is enabled. |
| | 26 | |
| | 27 | == Development Practices == #DefinitionofDoneforFeatureBranches-DevelopmentPractices.1 |
| | 28 | * Code developed includes automated unit tests or is already covered by existing tests. |
| | 29 | * Will be added when a framework is adopted for each part of the code |
| | 30 | * Code quality scans have been run and no new issues have created due to these changes. (need information on code quality scans) |
| | 31 | * Will be added as soon as Scruitinzer and Coverity are configured to generate useful information without a lot of noise due to conflicts in code styles |
