Cycle Analytics: first iteration
A new issue to not remove the content of the original issue, which is found here: https://gitlab.com/gitlab-org/gitlab-ce/issues/20975
Proposal
Cycle analytics tracks the median time between idea => production steps. This iteration does not ship a Chat ops integration, so we leave that out for now.
Idea to production consists of several events, which we've labeled with a name and the time that is represented in that thing. E.g. Plan represents the time spend in the planning phase, so the time that the idea exists and is planned, but no one has started implementing it yet.
- Issue (Tracker)
- from issue creation until given a milestone or list label (first assignment, any milestone, milestone date or assignee is not required)
- Plan (Board)
- from given a milestone or list label until the first commit
- Code (IDE)
- from first commit until the merge request is created (this might exclude coding time if you use WIP, so be it)
- Test (CI)
- total test time for all commits/merges
- Review (MR)
- from merge request creation until MR merged (closed MR's won't be deployed)
- Staging (CD)
- from MR merge until deploy to production (production is last stage/environment)
- Production (Total)
- sum of the above excluding Test (CI) time
The dropdown at the top allows users to have the summary for the:
- Last 30 days (the things that went to production the last 30 days.)
- Last 90 days
We will add more items in this dropdown in the future - probably things like Current year
and All time
.
Differences with original design
- no chat part => not possible without integration of Chatops, needs another release at least
- no feed of events => to reduce scope of iteration
- reduced information on top => ditto, but if code coverage is easy to add, we should. Collaborator info seems useless
- no delta's => to reduce scope
- less statistics => to reduce scope and reserve for EE enhancements
Questions
How do we track whether a branch corresponds to an issue?
Not sure. I'm thinking the best strategy is to use either the suggested branch name (when you create a new one in an issue) or by using that in a regex, for instance *5-branch-permissions*
, so you can still do things like jobv/5-branch-permissions
.
@sytses also suggested to check whether an issue is closed by a branch https://gitlab.com/gitlab-org/gitlab-ce/issues/21170#note_14155739
Original design
This is the original design, I've simplified it above to reduce the iteration size.
New design elements we need
-
A design for this page -
Blank state for the feature -
In some cases, we will have stages (like Review step for instance) which will be blanked. We need a design for empty rows.
References
- #21375 (closed) Cycle Analytics: v1 Rollout