Use Case: Distributed Systems / Microservices
From 12 Factor, if there are multiple codebases, it’s not an app – it’s a distributed system. We should support distributed systems, especially mindful of the rising trend in microservices and Docker adoption. We cover multi-project pipelines elsewhere, but we can go further with system-level views and coordinated deploys.
- Pipeline (and job?) list at the group level (so you can see all pipelines for related microservices)
- This implies having a CI/CD menu at the group level, and charts for analytics
- This implies browsing Docker images at group level as well.
- Multiple pipelines per repo (so you can cleanly support a monorepo of microservices with different pipelines)
- New view of related apps in a distributed system
- Zoom out in the project pipeline
- Group in GitLab for team/issue/activity tracking (maybe using nested groups, but maybe allowing multiple inheritance)
- Block deploys of one component if it depends on a version of another component that has not been deployed yet to the same environment e.g.:
- Annotate relationship between merge requests so that we know if one MR blocks another.
- Track deploys of MRs to each environment so we know, for example, when a given MR is in production.
- We can block merges of one MR until upstream changes are merged.
- We can block deploys of one MR until upstream changes are deployed (to the same environment).
- This can work across projects so individual services get deployed in the right order.
- Coordinated deploy of all related apps to a new environment. e.g. autogenerate a "cloudformation" because we know how the projects relate to each other. This could, for example, be used by GitHost to spin up a new single-tenant instances of GitLab for a new customer.