# Delivery Foundations

> Die Lieferkette als kontrollierter Systempfad: Änderungen, Nachweise, Artefakte und Releases.

Track: [DevOps Delivery & CI/CD](https://physar.tech/learn/devops-cicd)  
Kanonische Fassung: https://physar.tech/learn/devops-cicd/delivery-foundations  
Stand: 2026-07-25  
Interaktiver Teil: 2 Checks (nur im Browser)

## Delivery ist eine kontrollierte Kette

### Vom Commit zum laufenden System

Eine Delivery-Pipeline übersetzt eine Änderung in ein identifizierbares Artefakt und einen kontrollierten Release. Der wichtige Vertrag lautet: Welche Revision, Abhängigkeiten, Tests und Freigaben führten zu genau diesem laufenden Zustand?

_[Abbildung: Das identifizierte Artefakt bleibt über Prüfung, begrenzte Exposition und einen getesteten Rückweg nachvollziehbar.]_

> **Merksatz:** Wiederholbarkeit und Nachweisbarkeit sind Eigenschaften des ganzen Pfads, nicht eines einzelnen CI-Jobs.

### Vertrauen wird schrittweise aufgebaut

Änderung nachvollziehbar erfassen → Automatisiert bauen und prüfen → Unveränderliches Artefakt identifizieren → Artefakt durch Umgebungen promoten → Auswirkung beobachten und gegebenenfalls zurückrollen

### Sicher und schnell sind kein Gegensatz

Kleine, häufige Änderungen senken das Risiko pro Release nur, wenn Tests, Review, Provenance und Rollback tatsächlich verlässlich sind. Ein manuelles Ausnahmeverfahren darf nicht der normale Produktionspfad werden.

> **Abgrenzung:** LLM-spezifische Prompt- und Modell-Rollouts bleiben im Track `llm-production-ops`.

### Nächste Checks

- Artefakt einmal bauen und kontrolliert promoten
- Gates nach Risiko statt nach Ritual wählen
- Rollback als getesteten Betriebsweg behandeln

## Quellen

- NIST SP 800-218: Secure Software Development Framework — https://doi.org/10.6028/NIST.SP.800-218
- Google SRE Workbook: Canarying Releases — https://sre.google/workbook/canarying-releases/