Service oriented operations: Design and IA
Problem to solve
As a lead engineer / platform engineer, I want a single place to define the lifecycle and related processes of a service, so GitLab can support me in Day 0, Day 1 and Day 2 operations.
Builds upon the discussions in Environments Design Sprint (gitlab-org/ci-cd/deploy-stage/environments-group&1)
Design issue for: Deployment workflow management with first-class... (#414920)
Expected Experience:
- A design example of a filled service list, with no metrics and no deep dive (into an individual service page yet). Search seemed important, but I am also okay cutting it for MVC to get something out to our users.
- A design example of an empty service list (no services in this environment).
- A journey map of registering a service (potentially not including UI yet, but just an idea of how users would go about this).
- A docs page on services.
User Journey
WIP Found in this Figma.
UI Paths
Path | Must specify | Comment |
---|---|---|
/<group>/<project>/-/services |
group, project, environment-name (query param) | List View |
/<group>/<project>/-/services/<service-name> |
group, project, environment-name (query param), service-name | Details View |
/<group>/<project>/-/services/<service-name>/releases |
group, project, environment-name (query param), service-name | Deployed and outstanding release artifacts for this service. This could be part of Details View. |
/<group>/<project>/-/services/<service-name>/releases/<release-version> |
group, project, service-name | Release status View. A specific release artifact for this service. This is cross-environments page and could be part of Details View. |
Additional notes
- We should update the blueprint once we've figured out how services are registered. !129696 (comment 1596594373)
Once you know how this is going to be done, please create an ADR. See an example of one: !132129 (merged)
Edited by Shinya Maeda