summaryrefslogtreecommitdiff
path: root/doc/architecture/blueprints/ci_pipeline_components/index.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/architecture/blueprints/ci_pipeline_components/index.md')
-rw-r--r--doc/architecture/blueprints/ci_pipeline_components/index.md58
1 files changed, 14 insertions, 44 deletions
diff --git a/doc/architecture/blueprints/ci_pipeline_components/index.md b/doc/architecture/blueprints/ci_pipeline_components/index.md
index 115f6909d2d..a3c72227f3e 100644
--- a/doc/architecture/blueprints/ci_pipeline_components/index.md
+++ b/doc/architecture/blueprints/ci_pipeline_components/index.md
@@ -1,12 +1,13 @@
---
-stage: Stage
-group: Pipeline Authoring
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
-comments: false
-description: 'Create a catalog of shareable pipeline constructs'
+status: proposed
+creation-date: "2022-09-14"
+authors: [ "@fabio", "@grzesiek" ]
+coach: "@kamil"
+approvers: [ "@dov" ]
+owning-stage: "~devops::verify"
+participating-stages: []
---
-
# CI/CD pipeline components catalog
## Summary
@@ -115,21 +116,22 @@ while encapsulating and isolating implementation details.
Components allow a pipeline to be assembled by using abstractions instead of having all the details defined in one place.
When using a component in a pipeline, a user shouldn't need to know the implementation details of the component and should
-only rely on the provided interface. The interface will have a version / revision, so that users understand which revision they are interfacing with.
+only rely on the provided interface.
A pipeline component defines its type which indicates in which context of the pipeline configuration the component can be used.
For example, a component of type X can only be used according to the type X use-case.
-For best experience with any systems made of components it's fundamental that components are single purpose,
-isolated, reusable and resolvable.
+For best experience with any systems made of components it's fundamental that components:
- **Single purpose**: a component must focus on a single goal and the scope be as small as possible.
-- **Isolation**: when a component is used in a pipeline, its implementation details should not leak outside the
+- **Isolated**: when a component is used in a pipeline, its implementation details should not leak outside the
component itself and into the main pipeline.
-- **Reusability:** a component is designed to be used in different pipelines.
+- **Reusable**: a component is designed to be used in different pipelines.
Depending on the assumptions it's built on a component can be more or less generic.
Generic components are more reusable but may require more customization.
-- **Resolvable:** When a component depends on another component, this dependency must be explicit and trackable.
+- **Versioned**: when using a component we must specify the version we are interested in.
+ The version identifies the exact interface and behavior of the component.
+- **Resolvable**: when a component depends on another component, this dependency must be explicit and trackable.
## Proposal
@@ -186,35 +188,3 @@ Some limits we could consider adding:
- Allow self-managed administrators to populate their self-managed catalog by importing/updating
components from GitLab.com or from repository exports.
- Iterate on feedback.
-
-## Who
-
-Proposal:
-
-<!-- vale gitlab.Spelling = NO -->
-
-| Role | Who
-|------------------------------|-------------------------|
-| Author | Fabio Pitino |
-| Engineering Leader | ? |
-| Product Manager | Dov Hershkovitch |
-| Architecture Evolution Coach | Kamil TrzciƄski |
-
-DRIs:
-
-| Role | Who
-|------------------------------|------------------------|
-| Leadership | ? |
-| Product | Dov Hershkovitch |
-| Engineering | ? |
-| UX | Nadia Sotnikova |
-
-Domain experts:
-
-| Area | Who
-|------------------------------|------------------------|
-| Verify / Pipeline authoring | Avielle Wolfe |
-| Verify / Pipeline authoring | Furkan Ayhan |
-| Verify / Pipeline execution | Fabio Pitino |
-
-<!-- vale gitlab.Spelling = YES -->