Freitag, 16 Uhr
Freitag um 16 Uhr kopiert Lena eine Änderung von Hand auf den Server des Shops. Sie vergisst eine Datei.
Die Kassenseite fällt aus. Bis Montag merkt es niemand. Der Shop verliert ein ganzes Wochenende an Bestellungen.
Die meisten Teams liefern nicht mehr von Hand aus. Eine Maschine führt jedes Mal dieselben Prüfungen aus und vergisst keine Datei.
Am Ende dieser Lektion
Notiz
Ich kann eine Pipeline beschreiben, die Code testet und ausliefert.
Schlüsselwörter
| Begriff | Was er bedeutet |
|---|---|
| Pipeline | Schritte, die eine Maschine bei jeder Änderung ausführt |
| Stufe | ein Schritt einer Pipeline |
| Continuous Integration (CI) | jede Änderung sofort nach dem Hochladen testen |
| Continuous Delivery (CD) | jede getestete Änderung auf demselben sicheren Weg ausliefern |
| Staging | eine Kopie des Live-Systems für eine letzte Prüfung |
| Rollback | zurück zur letzten Version, die funktionierte |
Die Zellen, die Lernende ausfüllen, bleiben in dieser Vorschau leer.
Eine Pipeline führt immer dieselben Schritte aus
Eine Pipeline startet von selbst, sobald jemand eine Änderung hochlädt. Sie führt ihre Stufen der Reihe nach aus.
Schlägt eine Stufe fehl, hält die Pipeline an. Nichts danach läuft, und die Änderung wird nicht ausgeliefert.
Jede Änderung sofort zu testen heißt Continuous Integration. Starten Sie die Pipeline unten und brechen Sie dann den Test, wie der Kommentar sagt.
Eine kleine Pipeline ausführen
mkdir -p shop && cd shop
printf '24\n' > summe.txt # die Antwort des Codes: Artikel 20 Euro plus 4 Euro Versand
pruefe_stil() { echo "Stufe 1: Stil prüfen ... ok"; }
fuehre_tests_aus() {
echo "Stufe 2: Tests ausführen"
if [ "$(cat summe.txt)" = "24" ]; then
echo " Test Warenkorb-Summe ... bestanden"
else
echo " Test Warenkorb-Summe ... FEHLGESCHLAGEN"
return 1
fi
}
baue_image() { echo "Stufe 3: Image bestellungen:1.5 bauen ... ok"; }
stelle_bereit() { echo "Stufe 4: auf Live bereitstellen ... ok"; }
set -e # bei der ersten fehlgeschlagenen Stufe anhalten
pruefe_stil
fuehre_tests_aus
baue_image
stelle_bereit
echo "Pipeline bestanden: die Änderung ist live"
# Ändern Sie in der zweiten Zeile 24 in 25 und drücken Sie auf Ausführen. Welche Stufen laufen noch?
Die vier Stufen im Überblick
| Stufe | Frage, die sie beantwortet | Bei Misserfolg |
|---|---|---|
| Stil prüfen | Ist der Code ordentlich geschrieben? | Pipeline hält an |
| Tests ausführen | Tut der Code, was er soll? | Pipeline hält an |
| Image bauen | Lässt sich die App packen? | Pipeline hält an |
| Bereitstellen | Kommt die App auf den Server? | Rollback prüfen |
Die Zellen, die Lernende ausfüllen, bleiben in dieser Vorschau leer.
Ein häufiger Fehler
Warnung
Viele denken, eine grüne Pipeline heiße: Es gibt keine Fehler. Das stimmt nicht. Eine Pipeline zeigt nur, dass die vorhandenen Tests bestanden haben. Einen Fall, den niemand als Test geschrieben hat, sieht sie nicht. Grün heißt also: nichts Bekanntes ist kaputt.
Die Stufen stehen in einer Datei
Die Pipeline ist kein Geheimnis im Kopf einer Person. Sie steht in einer Textdatei im Projekt, meist in YAML.
Jede Stufe hat einen Namen und einen Befehl. Das Team liest, ändert und prüft die Datei wie jeden anderen Code.
Unten schreibt Bash so eine Datei und liest sie zurück. Das ist nur ein Text und läuft hier nicht als echte Pipeline.
Eine Pipeline-Datei lesen
mkdir -p shop && cd shop
cat > pipeline.yml <<'EOF'
on: push
jobs:
ausliefern:
runs-on: ubuntu-latest
steps:
- name: Stil pruefen
run: ruff check .
- name: Tests ausfuehren
run: pytest
- name: Image bauen
run: docker build -t bestellungen:1.5 .
- name: Auf Staging bereitstellen
run: ./deploy.sh staging
EOF
# Die Namen der Stufen in der Reihenfolge
grep "name:" pipeline.yml
# Wie viele Befehle die Pipeline ausführt
grep -c "run:" pipeline.yml
# Fügen Sie eine Stufe „Auf Live bereitstellen“ hinzu, die ./deploy.sh live ausführt, und starten Sie erneut.
Continuous Delivery liefert in Schritten aus
Nach den Tests geht das gebaute Image zuerst nach Staging, einer Kopie des Live-Systems. Dort prüft das Team ein letztes Mal.
Danach folgt Live. Geht etwas schief, macht das Team einen Rollback: Es startet wieder die letzte Version, die funktionierte.
Dieser feste Weg heißt Continuous Delivery. Er macht Auslieferungen langweilig, und langweilig ist hier gut.