1
0
Fork 0
deploy-lock/docs/concepts.md

59 lines
1.8 KiB
Markdown

# Concepts
Explain the following:
## Contents
- [Concepts](#concepts)
- [Contents](#contents)
- [Deploy Path](#deploy-path)
- [Exclusive and Partial Locks](#exclusive-and-partial-locks)
- [Multi-Party Locks](#multi-party-locks)
## Deploy Path
The path to a service, starting with the cluster and environment: `apps/staging/a/auth-app`.
Path components may include:
- cluster
- env (`account`)
- target
- service (namespace)
- branch (`ref`)
When _locking_ a path, only the leaf path is locked, not parents.
When _checking_ a path, each segment is checked recursively, so a lock at `apps/staging` will prevent all services
from being deployed into both the `apps/staging/a` and `apps/staging/b` clusters.
- cluster comes first because that is how we structure the git repositories (repo = cluster, branch = env)
- to lock multiple clusters in the same environment, run the command repeatedly with the same lock data
- to lock a specific branch, put it in the path: `apps/staging/a/auth-app/main`
Ultimately, the deploy path's layout should follow the hierarchy of resources that you want to lock. One potential
order, for a multi-cloud Kubernetes architecture, is:
- cloud
- account
- region
- network
- cluster
- namespace
- resource name
Such as `aws/staging/us-east-1/apps/a/auth-app/api` or `gcp/production/us-east4-a/tools/gitlab/runner/ci`.
Including the region in the path can be limiting, but also allows locking an entire provider-region in case of serious
upstream incidents.
## Exclusive and Partial Locks
Some locks allow certain types, some locks don't allow anything. Why is that?
## Multi-Party Locks
Idea: make `LockData.author` an array, with commands to add/remove an author to an existing lock.
Why: there may be more than one person/team who needs to sign off on an incident before it is closed.