Skip to main content

Architecture Decision Records

This section contains Architecture Decision Records (ADRs) documenting key technical decisions made for EGI's CI/CD golden path and engineering standards.

Historical Context

Some ADRs document Kubernetes-specific or earlier golden-path decisions. They remain valuable historical records, but they are not the universal operations model for current production ownership. Use Anchor Handoff for the current production ownership boundary.

What is an ADR?​

An Architecture Decision Record (ADR) captures an important architectural decision made along with its context and consequences. Each ADR follows a simple format:

  • Status: Proposed, Accepted, Deprecated, Superseded
  • Context: The issue motivating this decision
  • Decision: The change being proposed or adopted
  • Consequences: The resulting context after applying the decision

Current ADRs​

0001: GitOps Engine for Kubernetes​

Historical Kubernetes-specific decision about Argo CD in the earlier GitOps model.

0002: Secrets Management​

Strategy for managing secrets across K8s and non-K8s deployment targets using External Secrets Operator and provider secret stores.

0003: Promotion Gates​

Use of GitHub Environments with required reviewers for production deployments while keeping dev and staging automated.

0004: Status Surfacing​

Design of a status event service for surfacing CI/CD events to downstream consumers.

Writing New ADRs​

When making significant architectural decisions:

  1. Create a new ADR file with the next number: XXXX-short-title.md
  2. Use the ADR template structure (Status, Context, Decision, Consequences)
  3. Keep it concise but complete
  4. Update this README with a link to the new ADR
  5. Get team review before marking it as accepted