Come up with ubiquitous language for pipeline-to-pipeline relationship
Problem
In the context of pipeline-to-pipeline relationship we have used various terms over time and the code does not reflect a Ubiquitous Language.
- upstream pipeline / downstream pipeline: used when a pipeline creates a downstream pipeline. Problem: upstream/downstream terms are time-sensitive. They primarily indicate what ran before/after.
- parent pipeline / child pipeline: used for pipeline that creates another pipeline within the same project. Problem: cross-project pipeline could still be thought as parent-child pipeline
-
Ci::Pipeline#triggered_pipelines
: used to indicate all downstream pipelines. Problem: see problems with the "trigger" term below -
Ci::Pipeline#triggered_by
: used to indicate the upstream pipeline. Problem: this is a duplicate term of upstream/parent. Also we use the term "trigger" with "trigger token", "trigger request", "trigger variables". -
Ci::Sources::Pipeline
we usesource_
for project/pipeline/job. Problem: another synonym of upstream/trigger/parent - what terms do we use for a pipeline that subscribes to another pipeline?
Other related terms:
The terms trigger
, spawn
, create
are used interchangeably. For trigger I think of a system that is fixed and deterministic and we simply decide to run it as-is. When a pipeline injects a configuration at creation-time (like parent/child pipeline) it's not really triggering a pipeline but rather generate/create a pipeline with some input parameters.
Goal
-
Come up with terms that will be used consistently in the codebase and documentation -
Change the terms in the code base backend => Issue to be created -
Change the terms in the documentation Technical Writing => Issue to be created
Weighting rubric
Size | Score | Description | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
Trivial | 1 | Mostly small to medium UI changes, smaller UX improvements, without unanswered questions. UX may need to stay involved with the issue but might not have to do work. | ||||||||
Small | 2 | Simple UI or UX change where we understand all of the requirements, but may need to find solutions to known questions/problems. | ||||||||
Medium | 3 | A medium change (lots of UI or UX changes/improvements required). Multiple pages are involved, we're starting to design/redesign small flows. Some unknown questions may arise during the work. | ||||||||
Large | 5 | A complicated change where other team members will need to be involved. Spans across multiple pages, we're working on medium-sized flows. There are significant open questions that need to be answered. | ||||||||
Huge | 8 | A complex change that spans across large flows and may require input from other designers. This is the largest flow design/redesign that we would take on in a single milestone. | ||||||||
Gigantic | 13 | A significant change that spans across multiple flows and that would require significant input from others (teams, team members, user feedback) and there are many unknown unknowns. It's unlikely we would commit to this in a milestone, and the preference would be to further clarify requirements and/or break in to smaller issues. |
Edited by Jason Yavorska