| ... | ... | @@ -21,10 +21,8 @@ Code must not be committed |
|
|
|
* if it does not build, or
|
|
|
|
* if it does not pass all unit tests
|
|
|
|
on the developer's local machine.
|
|
|
|
**Exception:**
|
|
|
|
Code on a feature branch may fail tests when explicitly labelled as *WIP*, eg, in order to pass code to colleagues.
|
|
|
|
|
|
|
|
|
|
|
|
**Exception:** Code on a feature branch may fail tests when explicitly labelled as *WIP*, eg, in order to pass code to colleagues.
|
|
|
|
|
|
|
|
## Releases, Develop, Master
|
|
|
|
|
| ... | ... | @@ -35,24 +33,22 @@ We *release* our software to our group via *master*. |
|
|
|
This happens frequently, on a regular basis.
|
|
|
|
|
|
|
|
In contrast, *develop* integrates completed portions of functionality.
|
|
|
|
|
|
|
|
|
|
|
|
All things building on Phoenix are strongly encouraged to build against *master*.
|
|
|
|
|
|
|
|
## Milestones
|
|
|
|
|
|
|
|
Milestones specify a certain functionality.
|
|
|
|
They shall live on the order of 2 weeks.
|
|
|
|
We encourage compact milstones that do not live longer than 2 weeks (on average).
|
|
|
|
We prefer shorter milestones.
|
|
|
|
They consist of single actionable steps, aka issues.
|
|
|
|
They are merged to develop only when completed.
|
|
|
|
Consequently, Milestone = Feature Branch.
|
|
|
|
Consequently, milestones spawn feature branchs and henceforth share their life time.
|
|
|
|
|
|
|
|
A milestone must refer to a *functionality* issue (see there).
|
|
|
|
A milestone must refer to a *functionality* issue.
|
|
|
|
Consequently, milestones cannot be created without prior discussion.
|
|
|
|
|
|
|
|
We do not use the progress bar of a milestone.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Issues
|
|
|
|
|
|
|
|
We need issue categories aka labels (plus the ones defining the boards' columns):
|
| ... | ... | @@ -84,12 +80,11 @@ No new code may be written without first filing an issue for it. |
|
|
|
|
|
|
|
In order to track issues and to simplify merge requests, every commit addressing an issue has to name the issue in the commit message (3rd+ line).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Feature Branch
|
|
|
|
|
|
|
|
Whenever new code -- due to issues and milestones -- is added to the code base in the develop branch, a feature branch is created.
|
|
|
|
It is named by the milestone causing the branch to be spawned off of develop.
|
|
|
|
Whenever new code -- due to issues and milestones -- is added to the code base, a feature branch is created.
|
|
|
|
Feature branches branch off develop and eventually merge back into it.
|
|
|
|
They are named after the milestone spawning the branch.
|
|
|
|
Consequently, no new code can be written without first filing a functionality issue (or a bug report); and consequently not without prior discussion.
|
|
|
|
|
|
|
|
A feature branch has to be closed via a merge request.
|
| ... | ... | @@ -98,11 +93,9 @@ A feature branch adresses only a single bit of functionality aka a milestone. |
|
|
|
|
|
|
|
*Note*: Feature branches must not grow too large, otherwise merges become infeasible.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Merge Request
|
|
|
|
|
|
|
|
A merge request shall be filed whenever functionality is presumed to be finished, i.e., *all* tests pass on the developer's machine.
|
|
|
|
A merge request shall be filed whenever functionality is presumed to be *finished*, i.e., required functionality is implemented and *all* tests pass on the developer's machine.
|
|
|
|
The merge request shall then be examined for conflicts, tested, reviewed, and eventually merged.
|
|
|
|
|
|
|
|
A merge request should be handled by people not involved in the development of the branch.
|
| ... | ... | @@ -129,6 +122,7 @@ Use `closes #1` in 3rd+ line of commit message when functionality is considered |
|
|
|
|
|
|
|
## Boards
|
|
|
|
|
|
|
|
In order to visualize progress, we use gitlab's [issue board](https://devhub.vr.rwth-aachen.de/VR-Group/Project_Phoenix/boards) for this project. The following columns are available:
|
|
|
|
* *backlog* (GitLab's standard):
|
|
|
|
* collects *functionality issues* issues and *bugs*
|
|
|
|
* *discussion*
|
| ... | ... | @@ -143,3 +137,9 @@ Use `closes #1` in 3rd+ line of commit message when functionality is considered |
|
|
|
* collects those issues that are already merged to develop, but not yet to master.
|
|
|
|
* *closed* (GitLab's standard)
|
|
|
|
* collects those issues that are merged into master
|
|
|
|
|
|
|
|
Each column has its own label attached. When you flag an issue with that label, it will automatically be placed into that column.
|
|
|
|
Newly opened issues will always show up in *backlog* and closed ones in *close*, though.
|
|
|
|
You can freely move issues through the pipeline by drag&drop.
|
|
|
|
Please make sure to consistently update issues in oder to preserve a reasonable representation of progress. Moreover, be aware that gitlab tracks the issue life cycle by [cycle analytics](https://about.gitlab.com/features/cycle-analytics/).
|
|
|
|
Eventually, this feature will help us understand how fast we can realistically work and hence "what we can ultimately afford". |
