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".
