aiMOOC

Continuous Integration und automatisierte Qualitätssicherung

QR-Code

Einleitung

Warum dieser Kurs? Du entwickelst eine fiktive Messdaten-App. Bisher lässt sie sich lokal starten; jetzt soll jede Änderung wiederholt auf Importfehler, Tests, Syntax und saubere Ergebnisdateien geprüft werden. Du baust eine lokale Continuous Integration (CI) als überprüfbaren Ablauf – ohne Cloudkonto, kostenpflichtige KI oder Verbindung zu einer Maschine. Ein erfolgreiches Prüfergebnis ist ein Nachweis über definierte Kontrollen, keine Sicherheits- oder Produktionsfreigabe.

Zielgruppe: Auszubildende im 2. bis 3. Ausbildungsjahr. Voraussetzungen: A1 oder Grundlagen in Python, Dateien, Git und einfachen Tests. Vorwissen kannst du am vorhandenen Lernangebot auf MOOCwiki aktivieren: Was bewirkt ein Commit? Was unterscheidet eine Funktion und einen Test? Die verlinkte Seite war beim Recherchezugriff nicht abrufbar; ihr genauer Inhalt wird deshalb nicht behauptet.

Lernprodukt: Ein Projektordner mit import.py, build.py, ci.py, tests, synthetischer CSV-Datei und einer lokal erzeugten JSON-Datei. Du belegst drei Abnahmekriterien: (A) Testfehler blockiert das Artefakt, (B) das Artefakt enthält keine Secrets, (C) ein zweiter identischer Lauf ist reproduzierbar. Anschließend begründest du einen Fehlerfall und trennst die automatische Prüfung von einer menschlichen Review- und Freigabeentscheidung.

Arbeitsrahmen: Nur erfundene Sensorwerte, kein echter Anlagenanschluss, keine realen Zugangsdaten und keine Maschinensteuerung. Befehle ausschließlich im selbst angelegten Übungsordner ausführen. Die Begriffe Build, Test, Runner und Review werden im Verlauf erklärt. Dieses unabhängige OER-Lernangebot ist weder eine offizielle Liebherr-Schulung noch eine IHK-Zertifizierung.

CI verstehen: von der Änderung zum Prüfnachweis

Was Continuous Integration leistet

Continuous Integration bedeutet, kleine Codeänderungen regelmäßig in einen gemeinsamen Entwicklungsstand zu integrieren und automatisiert zu prüfen. In einem typischen Ablauf lösen Commit oder Pull Request eine Pipeline aus: Eine festgelegte Folge von Schritten wie Syntaxprüfung, Tests und Build. Ein Runner ist die Umgebung, die diese Schritte ausführt. Hier ersetzt dein eigener Rechner einen entfernten Runner. Ein rotes Ergebnis signalisiert einen fehlgeschlagenen definierten Schritt, ein grünes Ergebnis nur, dass die eingerichteten Prüfungen bestanden wurden.

Build bedeutet, aus festgelegten Eingaben ein nutzbares Ergebnis zu erzeugen – beispielsweise eine JSON-Zusammenfassung oder ein Softwarepaket. Ein Artefakt ist die dabei erzeugte Datei. Statische Analyse untersucht Code, ohne die fachlichen Funktionen normal auszuführen; Syntaxprüfung ist eine einfache Form davon. Dynamische Tests rufen Funktionen mit Beispieldaten auf und vergleichen Ergebnisse mit Erwartungen. Ein Review ist die inhaltliche Prüfung durch einen Menschen. Die drei Aufgaben sind verwandt, aber nicht austauschbar.

Abbildung: Grundidee der kontinuierlichen Integration. Quelle und Alternativtext stehen im Mediennachweis; ohne Bild gilt: Änderung → Prüfung → Ergebnis.

Ergänzung: „Was ist CI/CD?“ (the native web, deutsch, 2021). Ohne Video: Ein Commit stößt wiederholbare Tests an; automatische Bereitstellung ist ein anderer Schritt.

CI, Delivery und Freigabe unterscheiden

Continuous Delivery hält eine Anwendung mithilfe von Prüfungen grundsätzlich bereit für eine mögliche Auslieferung. Continuous Deployment automatisiert darüber hinaus die Auslieferung bei erfüllten Voraussetzungen. Unser Kurs endet bewusst vor jeder Bereitstellung. Eine gültige Datei darf nicht eigenständig in eine Anlage oder produktive Umgebung gelangen. Branch-Regeln, verpflichtende Reviews und getrennte Freigabeberechtigungen bleiben bestehen.

Die englischsprachige Grafik zeigt zusätzliche Stufen nach der Integration. Zum Verständnis ohne Grafik: lokaler Test → Build-Nachweis → separate menschliche Entscheidung; kein automatischer Betrieb.

Wiederholbarkeit statt einmaligem Erfolg

Ein Verfahren ist wiederholbar, wenn du denselben Ablauf unter festgelegten Bedingungen erneut starten kannst. Ein reproduzierbares Artefakt hat für dieselben Eingaben, dieselben relevanten Werkzeugeinstellungen und dieselbe Laufzeitumgebung dieselben Bytes; daran lässt sich der SHA-256-Hash vergleichen. Uhren, zufällige IDs, veränderliche Abhängigkeiten oder unsortierte Reihenfolgen können dieses Ziel zerstören. Ein reproduzierbarer Fehler bleibt ein Fehler – Reproduzierbarkeit ist keine Korrektheitsgarantie.

Mini-Check: Was würde ein grüner Testlauf über einen nie getesteten ungültigen Sensorwert aussagen? Er beweist darüber nichts. Notiere deshalb zu jedem Prüfschritt, was er nachweist und was offenbleibt.

Messdaten fachlich prüfen und gezielt testen

Der synthetische Modellfall

Lege einen neuen lokalen Ordner „messdaten-ci“ an. Die Datei sample.csv enthält exakt diese erfundenen Messwerte:

sensor,value
A,12.5
B,-3.0

Die Regeln lauten: Genau die Spalten „sensor“ und „value“ sind zulässig; ein Sensorname darf nicht leer sein; der Wert muss eine endliche Zahl sein; mindestens ein Datensatz muss vorliegen. Fehlende Werte, zusätzliche Spalten und NaN oder Infinity sind unzulässig. Das sind didaktische Importregeln, keine Industriestandards oder vollständige Cybersicherheitsvalidierung.

Schreibe import.py:

import csv
import io
import math

def import_rows(text):
    rows = csv.DictReader(io.StringIO(text))
    if rows.fieldnames != ["sensor", "value"]:
        raise ValueError("Falsche Spalten")
    result = []
    for row in rows:
        if None in row:
            raise ValueError("Zusätzliche Spalte")
        name = row["sensor"]
        value = row["value"]
        if name is None or value is None or not name.strip():
            raise ValueError("Unvollständiger Datensatz")
        try:
            number = float(value)
        except ValueError as error:
            raise ValueError("Kein Zahlenwert") from error
        if not math.isfinite(number):
            raise ValueError("Nicht endlicher Wert")
        result.append({"sensor": name.strip(), "value": number})
    if not result:
        raise ValueError("Keine Daten")
    return result

Erklärung: CSV ist ein einfaches tabellarisches Textformat; DictReader liest die Kopfzeile als Feldnamen. Eine Exception ist eine absichtlich ausgelöste Fehlermeldung; sie verhindert, dass ungültige Daten still als gültig behandelt werden. math.isfinite weist NaN und positive oder negative Unendlichkeit zurück. Für echte Messsysteme wären weitere Anforderungen wie Kodierung, Grenzwerte, Einheiten und Bedrohungsanalyse separat zu definieren.

Unit-Tests als ausführbare Anforderungen

Lege im Unterordner tests die Datei test_import.py an; der Ordner darf leer beginnen. Python bietet mit unittest bereits ein Testframework. Ein Unit-Test prüft eine kleine Funktion isoliert. Ein Negativtest erwartet die kontrollierte Ablehnung fehlerhafter Eingaben.

import unittest
from import_module import import_rows

class TestImport(unittest.TestCase):
    def test_valid(self):
        actual = import_rows("sensor,value\nA,12.5\n")
        self.assertEqual(actual, [{"sensor": "A", "value": 12.5}])

    def test_header(self):
        with self.assertRaises(ValueError):
            import_rows("value,sensor\n12.5,A\n")

    def test_missing_value(self):
        with self.assertRaises(ValueError):
            import_rows("sensor,value\nA\n")

    def test_infinity(self):
        with self.assertRaises(ValueError):
            import_rows("sensor,value\nA,Infinity\n")

    def test_empty(self):
        with self.assertRaises(ValueError):
            import_rows("sensor,value\n")

Wichtige Dateinamensanpassung: Speichere den obigen Importfunktionscode unter import_module.py (statt import.py), weil „import“ in Python ein reserviertes Wort ist. Diese Umbenennung betrifft allein das didaktische Dateibeispiel und nicht den Kurstitel. Ersetze die erste Datei im Projektplan entsprechend. Das Beispiel ist mit Python 3.10 oder neuer ausführbar.

Testausführung: Starte im Projektordner python -m unittest discover -s tests -v. Auf manchen Rechnern heißt der Befehl python3. Verändere anschließend test_valid zu einer falschen Erwartung (etwa 99.0 statt 12.5). Der Testlauf muss fehlschlagen. Repariere den Test danach – sonst kann die spätere Pipeline nicht erfolgreich sein.

Von einzelnen Tests zur Prüfliste

Prüfung	Beispiel	Nachweis	Grenze
Importprüfung	Falsche CSV-Spalten lösen ValueError aus	Negativtest schlägt bei fehlender Ablehnung fehl	Prüft noch keine Sensoreinheiten
Unit-Test	A,12.5 liefert die erwartete Zahl	Soll-Ist-Vergleich	Nur abgedeckte Fälle
Syntaxprüfung	Python-Dateien werden kompiliert	Fehler in der Python-Syntax erkannt	Kein Ersatz für fachliche Tests
Artefaktprüfung	Genau definierte Ergebnisfelder	Dateiinhalt überprüfbar	Kein umfassender Geheimnisscanner
Review	Zweite Person begutachtet Zweck und Grenzen	Dokumentierte Entscheidung	Nicht durch grüne Tests ersetzbar

Hilfestellung: Arbeite zuerst mit einem gültigen und einem ungültigen CSV-Beispiel. Vertiefung: Ergänze Grenzwerte, doppelte Sensor-IDs und mehrere Datensätze und benenne jeweils die neue Annahme.

Lokalen CI-Ablauf bauen und Testfehler blockieren

Das Build-Ergebnis bewusst klein halten

Schreibe build.py. Der Build nimmt ausschließlich die synthetische Datei sample.csv und erzeugt dist/messwerte.json. Er kopiert keine Umgebungsvariablen, Schlüsseldateien, Protokolle oder fremde Ordner. Statt eines ZIP-Archivs verwenden wir zunächst eine stabil serialisierte JSON-Datei.

import json
from pathlib import Path
from import_module import import_rows

def build(target=Path("dist/messwerte.json")):
    rows = import_rows(
        Path("sample.csv").read_text(encoding="utf-8")
    )
    payload = {"schema": "messdaten-v1", "rows": rows}
    text = json.dumps(
        payload, sort_keys=True, ensure_ascii=False,
        separators=(",", ":")
    ) + "\n"
    target.parent.mkdir(parents=True, exist_ok=True)
    target.write_text(text, encoding="utf-8")
    return target

Warum diese Auswahl? Eine Positivliste ist leichter zu begründen als ein ungeprüftes Kopieren des ganzen Arbeitsordners. Weil der Testdatensatz synthetisch ist und die Buildfunktion nur definierte Felder verwendet, sollte kein Secret enthalten sein. Trotzdem ist für echte Projekte zusätzlich ein professioneller Geheimnis-Scan nötig.

Ein einziger Einstiegspunkt für die Pipeline

Lege ci.py an:

from pathlib import Path
import hashlib
import subprocess
import sys

artifact = Path("dist/messwerte.json")
artifact.unlink(missing_ok=True)

steps = [
    [sys.executable, "-m", "compileall", "-q",
     "import_module.py", "build.py", "ci.py", "tests"],
    [sys.executable, "-m", "unittest",
     "discover", "-s", "tests", "-v"],
]

for command in steps:
    result = subprocess.run(command, check=False)
    if result.returncode != 0:
        print("CI STOP: Prüfschritt fehlgeschlagen")
        sys.exit(result.returncode)

from build import build
output = build()
digest = hashlib.sha256(output.read_bytes()).hexdigest()
print("CI OK; SHA-256:", digest)

Mit python ci.py führst du die beiden Prüfungen in definierter Reihenfolge aus. compileall übersetzt Python-Quelltext zu Bytecode und findet Syntaxfehler; es ist keine umfassende Sicherheitsanalyse. unittest gibt bei fehlgeschlagenen Tests einen Fehlerstatus zurück. subprocess.run startet diese Befehle; returncode enthält ihren Exitcode. sys.exit stoppt den Ablauf. Erst nach beiden erfolgreichen Prüfschritten wird die Ergebnisdatei erstellt. Fehlerhafte Daten beim Build führen ebenfalls zum Abbruch, weil die Exception nicht verschluckt wird.

Abnahme A – Fehler blockiert: Starte die Pipeline zunächst mit gültigen Tests. Notiere den Hash, lösche die Ergebnisdatei nicht manuell, ändere dann eine Test-Erwartung bewusst falsch und starte erneut. Erwartung: „CI STOP“, ein Exitcode ungleich null und keine dist/messwerte.json. Zu Beginn entfernt ci.py eine alte Ergebnisdatei; so wird kein altes Artefakt fälschlich als neuer Erfolg gewertet. Repariere die Test-Erwartung und prüfe den grünen Lauf. Dokumentiere vorher – Änderung – danach samt Exitcode und Artefaktzustand.

Ergänzung: „Prozesse mit GitHub Actions“ (the native web, deutsch, 2021). Das gezeigte Cloud-Werkzeug ist optional; die Übung bleibt vollständig lokal ausführbar.

Statische Prüfungen vertiefen

Pflichtprüfung ist die Syntaxkontrolle über compileall. Prüfe zusätzlich im Übungsordner Einrückungsfehler mit python -m tabnanny import_module.py build.py ci.py tests und erläutere, welche Fehlertypen dadurch erkannt werden können. Für eine erweiterte lokale Analyse kannst du freiwillig ein zuvor lokal installiertes Ruff mit ruff check . einsetzen. Solange Ruff nicht vorhanden ist, bleibt die Kernaufgabe mit Python-Standardbibliothek lösbar. Das Tool Ruff und jede externe Paketversion müssen für reproduzierbare Teamläufe dokumentiert und kontrolliert aktualisiert werden; ein nachträglicher Download ist nicht Bestandteil der Offline-Aufgabe.

Zusatzregel für ein Team: Eine später mögliche Git-basierte CI führt die gleichen Skripte in einer isolierten Umgebung aus. Für fremde Pull Requests dürfen keine Geheimnisse oder überhöhten Schreibrechte an den Testprozess weitergegeben werden. Erforderliche Statusprüfungen und Review-Regeln werden von berechtigten Verantwortlichen eingerichtet, nicht von der Messdaten-App selbst.

Artefakte, Secrets und Reproduzierbarkeit nachweisen

Abnahme B: Kein Secret im erzeugten Produkt

Ein Secret ist eine vertrauliche Information wie Passwort, Zugangstoken oder privater Schlüssel. Lege keine echten Geheimnisse im Übungsordner ab. Simuliere eine mögliche Leckage mit der rein erfundenen Kennung SYNTHETIC_CANARY_ONLY, die keinerlei Berechtigung besitzt. Ein Canary ist eine absichtlich erkennbare Testzeichenfolge.

Erweitere tests/test_import.py im selben TestImport-Klassenblock um einen Test für das Artefakt; füge die zusätzlichen Imports oben in der Datei hinzu:

import os
import tempfile
from pathlib import Path
from unittest.mock import patch
from build import build

    def test_artifact_without_canary(self):
        with tempfile.TemporaryDirectory() as folder:
            target = Path(folder) / "messwerte.json"
            with patch.dict(
                os.environ,
                {"TRAINING_SECRET": "SYNTHETIC_CANARY_ONLY"}
            ):
                build(target)
            data = target.read_text(encoding="utf-8")
            self.assertNotIn("SYNTHETIC_CANARY_ONLY", data)
            self.assertEqual(
                set(__import__("json").loads(data)),
                {"rows", "schema"}
            )

Achtung zur Einrückung: Die Zeile „def test_artifact_without_canary“ erhält vier Leerzeichen und gehört in die bereits vorhandene Klasse TestImport. Die Imports stehen vor der Klasse. Der Test verwendet ein separates temporäres Verzeichnis und erzeugt damit kein produktives Build-Artefakt. Er zeigt, dass genau dieser Canary nicht in der Ergebnisdatei steht und dass nur definierte Oberfelder vorkommen. Er beweist nicht, dass beliebige unbekannte Secrets unmöglich sind. Der eigentliche Schutz ist der sparsame Zugriff: keine realen Tokens, keine Umgebungsvariablen im Build, keine vollständigen Verzeichnisarchive und sorgfältige Prüfung des Ausgabeformats.

Fehlerexperiment: Füge zu Lernzwecken im Build testweise ein Feld mit der synthetischen Umgebungsvariable hinzu. Der Canary-Test muss rot werden; entferne das Feld wieder. Arbeite niemals mit einem echten Passwort oder Schlüssel.

Abnahme C: Identische Eingaben liefern identische Bytes

Füge in der Testklasse folgenden Test hinzu und den Import hashlib oben:

import hashlib

    def test_repeatable_bytes(self):
        with tempfile.TemporaryDirectory() as folder:
            target = Path(folder) / "result.json"
            build(target)
            first = target.read_bytes()
            build(target)
            second = target.read_bytes()
            self.assertEqual(first, second)
            self.assertEqual(
                hashlib.sha256(first).hexdigest(),
                hashlib.sha256(second).hexdigest()
            )

Begründung: Die CSV-Datei bleibt gleich, json.dumps sortiert Schlüssel und nutzt definierte Trennzeichen sowie UTF-8. Ohne Zeitstempel oder zufällige Felder bleiben die Bytes im Modellfall gleich. Das ist eine lokale Reproduzierbarkeitsprüfung mit gleicher Installation; vollständige Reproduzierbarkeit zwischen Betriebssystemen, Python-Versionen und anderen Eingaben erfordert zusätzliche Festlegungen. Für komplexe Builds können die dokumentierten Konzepte von SOURCE_DATE_EPOCH helfen – nicht jede Buildsoftware unterstützt sie automatisch.

Fehlerexperiment: Ergänze zeitweise ein aktuelles Zeitfeld in der Build-Ausgabe. Wenn sich das Feld zwischen den Läufen ändert, muss der Bytevergleich scheitern. Ein zweimaliger Lauf im selben sehr kurzen Zeitfenster könnte bei grober Zeitauflösung zufällig übereinstimmen; verwende zum sicheren Negativtest stattdessen zwei ausdrücklich unterschiedliche feste Zeitstempel. Danach entfernst du die Veränderung.

Drei nachvollziehbare Abnahmeprotokolle

Kriterium	Vorbereitung	Erwartete Beobachtung	Schluss und Grenze
A: Fehler blockiert	Absichtlich falsche Unit-Test-Erwartung	Exitcode ungleich null; kein neues dist/messwerte.json	Der definierte Fehler stoppt diese lokale Pipeline, aber nicht jeden denkbaren Fehler
B: Ohne Secrets	Synthetischen Canary als Umgebungsvariable setzen	Canary nicht im JSON; definierte Felder בלבד	Positivliste und Test reduzieren Leckagerisiko; kein globaler Geheimnisschutzbeweis
C: Reproduzierbar	Dieselbe CSV zweimal mit identischer Umgebung bauen	Gleiche Bytes und SHA-256-Werte	Belegt Gleichheit dieser zwei Läufe, nicht aller Systeme

Hinweis für die Dokumentation: Halte jeweils den genauen Prüfaufruf, Python-Version, Eingabedatei, beobachteten Exitcode und den Hash beziehungsweise den Grund für sein Fehlen fest. Ein Hash ist ein Fingerabdruck der Datei, keine Signatur und keine Genehmigung.

Beispiel eines komplexeren CI-Workflows (Grafik auf Englisch). Ohne Grafik: Ein Team kann mehrere Checks unabhängig ausführen, muss ihre Ergebnisse aber vor einer Freigabe gemeinsam beurteilen.

Rechte, Reviews und begründete Entscheidungen

Automatisierte Nachweise sind keine Freigabe

Trenne vier Rollen: Entwicklerinnen und Entwickler ändern die App und ihre Tests; ein Prüfprozess führt definierte Schritte mit minimalen Rechten aus; eine zweite berechtigte Person begutachtet Änderungen, Prüfergebnisse und offene Risiken; eine getrennte zuständige Instanz entscheidet gegebenenfalls über die Freigabe. Eine erfolgreiche Pipeline darf weder Reviewpflichten aushebeln noch eine produktive Anlage steuern. Least Privilege bedeutet: jeder Prozess erhält nur die notwendigen Rechte. Testläufe brauchen in unserem Modell weder Netzfreigabe noch Zugang zur Produktion.

Die Illustration zum Zusammenführen von Git-Zweigen zeigt, dass ein Merge eine eigene Entscheidung ist:

Git-Branches (Beschriftung teilweise Ukrainisch). Ohne Grafik: Änderungen laufen zunächst getrennt und werden erst nach Prüfung zusammengeführt.

Fehlerfall: grüne Pipeline, fachlich falsche Messgröße

Stell dir vor, die App akzeptiert den Sensorwert 85.0 als technisch gültige Zahl. Ein Review entdeckt jedoch, dass die verabredete Einheit Celsius war, während die CSV-Zeile Fahrenheit meint. Die bestehenden Tests bleiben grün, weil sie nur die Formatregeln prüfen. Die korrekte Entscheidung ist nicht „automatisch freigeben“, sondern: neue fachliche Anforderung dokumentieren, betroffene Schnittstelle und Datenquelle prüfen, einen passenden Test ergänzen und die Änderung erneut reviewen. Ob Grenzwerte, Umrechnung oder Ablehnung richtig sind, ist ohne Fachspezifikation ungewiss. Im Übungsfall wird nur simuliert.

Arbeitsfrage: Wer darf einen fehlenden fachlichen Test nachtragen, wer bewertet die fachliche Einheit und wer erteilt eine spätere reale Freigabe? Formuliere deine Antwort in drei getrennten Sätzen und begründe, warum ein automatisches Tool diese Verantwortlichkeiten nicht ersetzen kann.

Risikoanalyse für spätere KI-Agenten und Cloud-CI

Falls KI-Agenten irgendwann Code oder Workflows bearbeiten, gelten zusätzliche Risiken: Ein Tool kann untrusted Eingaben verarbeiten; ein fremder Pull Request kann missbräuchliche Befehle enthalten; ein Artefakt kann sensible Informationen einschleusen. Vermeide deshalb Geheimnisse im untrusted Testlauf, beschränke Token-Rechte, lasse Änderungen an der Pipeline begutachten und trenne Ausführung von Veröffentlichung. Die MCP-Sicherheitsempfehlungen im Dokumentationspfad 2026-07-28 behandeln unter anderem Tokenweitergabe, Zustimmungsgrenzen und minimale Berechtigungen. Sie sind ein Rechercheeinstieg, keine fertige Zertifizierung dieser Messdaten-App.

Das NIST AI 600-1 Generative-AI-Profil (Juli 2024) ordnet Governance, Risikoabbildung, Messung und Behandlung ein. Es hilft besonders, wenn KI-generierter Code überprüft werden muss; es ist nicht die technische Spezifikation für Python-CI und ersetzt weder OWASP-CI-Härtung noch ein Fachreview. Als praxisnähere Ergänzung dient die OWASP CI/CD Security Cheat Sheet.

Vertiefung: Entwirf für ein künftiges Team eine Regel, nach der Änderungen an Build-Skripten einen unabhängigen Review benötigen, der Runner nur Leserechte erhält und ein Freigabeprozess gesondert autorisiert werden muss. Prüfe, welche der drei Abnahmekriterien sich automatisiert beweisen lassen und welche menschliche Interpretation verlangen.

Interaktive Aufgaben

Quiz: Prüfe dein Wissen

Was kennzeichnet Continuous Integration im Modellfall? (Häufige Änderungen mit wiederholbaren automatischen Prüfungen zusammenführen) (!Jede Änderung ohne Tests sofort produktiv schalten) (!Nur einmal am Projektende das Programm starten) (!Den Quellcode durch ein Geheimnis ersetzen)

Was muss geschehen, wenn ein verpflichtender Unit-Test fehlschlägt? (Der Build wird gestoppt und das Ergebnis nicht neu erstellt) (!Die fehlerhafte Prüfung wird automatisch gelöscht) (!Die Software wird trotzdem für eine Anlage freigegeben) (!Der Fehlerstatus wird unabhängig vom Ergebnis auf null gesetzt)

Welche Prüfung erkennt eine falsche Spaltenreihenfolge der CSV? (Ein Test gegen die festgelegte Kopfzeile) (!Ein Vergleich der Dateinamenlängen) (!Eine automatische Veröffentlichungsfreigabe) (!Ein Test allein auf den freien Speicherplatz)

Warum verhindert compileall allein keine fachlichen Fehler? (Es kontrolliert Python-Syntax und nicht die Bedeutung der Messwerte) (!Es prüft bereits jede physikalische Einheit) (!Es ersetzt den Review durch eine andere Person) (!Es führt automatisch eine vollständige Risikoanalyse durch)

Wie wird im Kurs ein Secret im Artefakt vermieden? (Durch eng festgelegte Ausgabefelder ohne geheime Umgebungsdaten) (!Durch Speicherung aller Umgebungsvariablen im Bericht) (!Durch Aufnahme des gesamten Projektordners) (!Durch Abschalten aller Importtests)

Was zeigen gleiche SHA-256-Werte bei den zwei lokalen Testläufen? (Die ausgegebenen Bytes stimmen in diesen zwei Läufen überein) (!Das Programm hat eine amtliche Sicherheitsfreigabe) (!Jede zukünftige Änderung bleibt fehlerfrei) (!Die Quelldaten wurden von einer Messanlage bestätigt)

Wer entscheidet nach einer erfolgreichen lokalen Prüfung über eine reale Freigabe? (Eine ausdrücklich dafür berechtigte verantwortliche Stelle) (!Automatisch jeder erfolgreich abgeschlossene Python-Test) (!Die Funktion zur CSV-Einlesung selbst) (!Ein beliebiges Artefakt ohne Dokumentation)

Warum nutzt der Kurs synthetische Canary-Werte? (Um den Umgang mit möglichen Lecks ohne reale Geheimnisse zu prüfen) (!Um Produktionszugänge in Tests sichtbar zu machen) (!Um reale Nutzerpasswörter zu ersetzen und zu veröffentlichen) (!Um alle Sicherheitsprüfungen unnötig zu machen)

Was ist eine sinnvolle Reaktion auf grüne Tests bei falscher Einheit? (Fachanforderung klären und einen passenden Test mit Review ergänzen) (!Die Einheit ohne Prüfung als richtig erklären) (!Den grünen Teststatus als Freigabeurkunde verwenden) (!Die CSV-Datei ungeprüft an eine Maschine übertragen)

Welche Aussage zu KI-Agenten und CI-Rechten stimmt? (Untrusted Code benötigt begrenzte Rechte und getrennte Freigabewege) (!Fremde Beiträge brauchen automatisch alle Repository-Secrets) (!Ein Agent darf eigenständig die Reviewpflicht entfernen) (!Ein grüner Linterbericht erlaubt jede Produktionsaktion)

Memory: Begriffe und Funktionen

Pipeline	Festgelegte Abfolge automatisierter Prüfschritte
Runner	Umgebung zum Ausführen eines Prüfablaufs
Unit-Test	Isolierte Prüfung einer kleinen Programmeinheit
Artefakt	Gespeicherte Ausgabe eines Build-Prozesses
Canary	Rein synthetische Markierung zum Erkennen eines unerwünschten Datenabflusses
Review	Inhaltliche Prüfung einer Änderung durch eine zuständige Person

Drag and Drop: Schritt und Zweck zuordnen

Ordne den passenden Begriff zu	Prüfzweck
Importvalidierung	Fehlerhafte CSV-Felder kontrolliert zurückweisen
Syntaxprüfung	Grammatikfehler im Python-Code erkennen
Unit-Test	Funktionsergebnis mit einer Erwartung vergleichen
Build	Aus festgelegten Eingaben eine Ergebnisdatei erzeugen
Reviewentscheidung	Befugte Menschen beurteilen Nachweise und offene Risiken

Kreuzworträtsel

Pipeline	Wie heißt die automatisierte Abfolge von Prüfschritten?
Runner	Wie heißt die Umgebung, die eine CI-Aufgabe ausführt?
Commit	Wie nennt Git eine festgehaltene Codeänderung?
Artefakt	Wie heißt die beim Build erzeugte Ergebnisdatei allgemein?
Review	Wie heißt die menschliche Begutachtung einer Codeänderung?
Hashwert	Wie heißt der berechnete Fingerabdruck einer Datei?

LearningApps: Weitere Übungen finden

Die Suchergebnisse sind externe Angebote und können wechseln. Die vollständigen Übungen in diesem Kurs benötigen LearningApps nicht.

Lückentext: den CI-Nachweis verstehen

Eine wiederholt ausführbare Folge von Prüfungen heißt

.

Der Befehl unittest führt dynamische

aus.

Ein fehlerhafter verpflichtender Prüfschritt liefert einen Exitcode ungleich

.

Eine Ergebnisdatei eines Builds heißt

.

Vertrauliche Zugangsinformationen nennt man

.

Ein rein künstlicher Marker zum Erkennen möglicher Lecks ist ein

.

Mit einem

vergleichst du zwei Dateiausgaben.

Eine fachliche Begutachtung durch eine zuständige Person heißt

.

Gleiche Ausgaben aus festgelegten gleichen Eingaben zeigen die untersuchte

.

Ein grünes Prüfergebnis ersetzt keine menschliche

.

Offene Aufgaben

Leicht

Ablaufskizze: Zeichne mit Stift fünf Stationen von der Codeänderung bis zum lokalen Prüfergebnis; erläutere in eigenen Worten, warum kein Schritt eine Produktionsfreigabe ist.
Negativfall: Entwickle eine synthetische CSV mit falscher Kopfzeile, sage den erwarteten Fehler voraus und protokolliere den tatsächlichen Test.
Begriffskarten: Erkläre Pipeline, Runner, Build, Artefakt und Review jeweils an einem konkreten Beispiel aus der Messdaten-App.
Canary-Protokoll: Beschreibe die erfundene Canary-Zeichenfolge und warum echte Passwörter niemals für eine Lernübung gebraucht werden.

Standard

Lokalen Ablauf ausführen: Lege den Projektordner an, starte python ci.py und halte Befehle, Exitcode, erstellte Datei und SHA-256-Wert in einer Tabelle fest.
Rote Pipeline: Baue einen absichtlich falschen Test ein, prüfe das Blockieren des Artefakts, repariere ihn und dokumentiere beide Beobachtungen mit Begründung.
Prüfgrenzen vergleichen: Vergleiche compileall, unittest und einen freiwillig verfügbaren Linter anhand von mindestens zwei Fehlerarten und einer nicht geprüften Fachanforderung.
Bytevergleich: Erzeuge mit identischer CSV zweimal die Ergebnisdatei und vergleiche ihren Inhalt und Hash; erkläre, welche Rahmenbedingungen dein Ergebnis begrenzen.

Schwer

Canary-Angriffssimulation: Ergänze kurz ein synthetisches Secret-Feld im Build, lasse den Test scheitern, entferne es und begründe das Prinzip minimaler Datenweitergabe.
Anforderungsprüfung: Entwirf drei neue Grenzfälle für den Import und implementiere Tests; erläutere, weshalb mehr grüne Tests nicht automatisch vollständige Abdeckung bedeuten.
Rollenmodell: Entwickle eine schriftliche Teamregel für Commit, Review, Prüfstatus und manuelle Freigabe, inklusive Rechten für untrusted Änderungen.
Fehleranalyse und Transfer: Untersuche die falsche Temperatureinheit als Fall einer grün geprüften, fachlich unzureichenden App und übertrage die Erkenntnis auf ein anderes rein simuliertes Ausbildungsprojekt.

Lernkontrolle

Ablaufanalyse: Warum ist die Reihenfolge Syntaxprüfung, Unit-Tests, Artefakterzeugung sinnvoll und was würde ein zu früh erzeugtes Artefakt verfälschen?
Prüfbeleg A: Zeige an einem echten lokalen Fehlversuch den Exitcode und das Fehlen der neu erzeugten Datei; begründe, warum ein bloß rotes Konsolenwort als Nachweis nicht genügt.
Prüfbeleg B: Erkläre anhand von Positivliste und Canary-Test, wie Secrets ferngehalten werden und welche Arten von Geheimnissen die Übung nicht vollständig erkennen würde.
Prüfbeleg C: Vergleiche zwei SHA-256-Werte und beurteile kritisch, warum gleiche Hashwerte weder eine inhaltliche Freigabe noch einen Beweis für alle Systeme darstellen.
Fehlerfall: Begründe deine Entscheidung, wenn die App zwar eine valide Zahl importiert, deren Messeinheit aber fachlich unklar ist; nenne Verantwortlichkeiten und neue Tests.
Transfer: Entwirf für eine andere synthetische CSV-App drei automatisierte Prüfungen und eine getrennte Reviewgrenze, ohne echte Zugänge oder Maschinen anzusteuern.

Lernnachweis

Abgabe: Reiche den lokalen Übungsprojektordner mit import_module.py, build.py, ci.py, sample.csv, tests und der erzeugten, rein synthetischen JSON-Datei ein. Ergänze ein kompaktes Prüfprotokoll mit den drei Ergebnissen A, B, C. Aus dem Protokoll müssen hervorgehen: konkrete Befehle; verwendete Python-Version; gültiger und absichtlich fehlerhafter Testlauf; Exitcodes; Dateiexistenz; Canary-Negativtest; zwei Dateihashes sowie eine nachvollziehbare Interpretation. Reiche keine persönlichen Daten, privaten Schlüssel, Screenshots von Zugangstoken oder Cloudprotokolle mit Secrets ein.

Bewertungsraster (Orientierung): Fachliche Importregeln und Tests 25 Prozent; nachweisbares Blockieren bei Testfehler 20 Prozent; belegter Secret-Schutz im Beispiel 15 Prozent; reproduzierbarer Build und Grenzen 20 Prozent; begründete Review-/Freigabetrennung und Transfer 20 Prozent. Ein grüner Testlauf allein reicht nicht. Dokumentiere zusätzlich einen absichtlich aufgedeckten Fehlerfall und erkläre, warum er zunächst unentdeckt bleiben konnte.

Selbstkontrolle: Kannst du zu jeder der drei Bedingungen eine konkrete Beobachtung, eine Ursache und eine Grenze nennen? Wenn nicht, wiederhole den betreffenden lokalen Test. Kein Prüfschritt in diesem Kurs erteilt eine reale Sicherheits- oder Maschinenfreigabe.

OER und Wikipedia

Stand der Quellenprüfung: 22.10.2026. Softwaredokumentationen und Videoverfügbarkeit können sich ändern. Der Beispielcode nutzt die Python-Standardbibliothek; seine konkrete Laufumgebung muss lokal geprüft werden. Die Grundlagenseite auf MOOCwiki war beim Abruf nicht zugänglich, daher ist ihr genauer Stand offen.

Wikipedia – Kontinuierliche Integration (deutsch, Überblick; Sekundärquelle).

Python-Dokumentation: unittest (aktuelle Python-3-Dokumentation; bei Nutzung konkrete lokale Python-Version notieren).
Python-Dokumentation: compileall (Grenzen der Syntaxprüfung).
pytest: Exitcodes (optionale Alternative zum Standardbibliothek-Testframework).
Ruff: Linter (optionale statische Analyse; Online-Dokumentation ohne festgehaltene Toolversion ist kein reproduzierbares Dependency-Lock).
Reproducible Builds – SOURCE_DATE_EPOCH (relevante Build-Umgebungseingaben).
OWASP CI/CD Security Cheat Sheet (Least Privilege, Artefaktintegrität und Secrets).
GitHub Docs: Secure Use (zusätzliche Sicherheitsgrenzen bei Cloud-CI; Dokumentation kann fortgeschrieben werden).
Model Context Protocol: Security Best Practices, Dokumentationspfad 2026-07-28 (Sicherheitskontext für Agenten; nicht mit CI-Zertifizierung gleichsetzen).
NIST AI 600-1, Generative Artificial Intelligence Profile, Juli 2024 (Risiko- und Governance-Perspektive, nicht Prüfstandard für die Beispiel-App).
Vorhandenes MOOCwiki-Grundlagenangebot (Abruf für diese Erstellung nicht möglich; zur Wiederholung individuell nutzen).

Verifizierte externe Medien und Rechteangaben: Alle folgenden Wikimedia-Commons-Dateiseiten wurden bei der Erstellung geprüft; die Medien werden über ihren bestehenden Namen eingebunden, nicht neu produziert. Lizenzbedingungen gelten weiter. Die eingebetteten Videos waren als YouTube-Einträge mit Titel, Herausgeber und Veröffentlichungsdatum recherchierbar; aktuelle Abspielbarkeit bei jedem Nutzer, spätere Sperrungen und Nutzungsrechte am Video sind dadurch nicht garantiert. Videoeinbettungen sind Links zum Anbieter, keine freie Lizenz oder OER-Nachnutzung.

Medium und Alternativinhalt	Dateiseite / Nachweis	Urheberschaft	Rechte / Hinweise
Continuous Integration.jpg; Diagramm: Änderung, Module, Integrationsschritte	Wikimedia Commons	Pratik89Roy	CC BY-SA 4.0
Continuous Delivery process diagram.svg; Stufen von Integration bis möglicher Bereitstellung	Wikimedia Commons	Grégoire Détrez, nach Jez Humble; spätere Sprachfassung vorhanden	CC BY-SA 4.0; englischsprachige Grafik
Wikimedia CI workflow.svg; Beispiel einer mehrstufigen Pipeline	Wikimedia Commons	Antoine „hashar“ Musso / Wikimedia Foundation	CC BY-SA 3.0
Git branches merge.svg; Zusammenführung zweier Entwicklungszweige	Wikimedia Commons	Bunyk	CC BY-SA 4.0; Beschriftung teils Ukrainisch
Was ist CI/CD? – Vortragsvideo, ersetzbar durch das erste Kapitel	YouTube-Eintrag	the native web GmbH, 06.06.2021	Externes Video, keine freie Nachnutzungslizenz verifiziert
Prozesse mit GitHub Actions – Video, ersetzbar durch das lokale Beispiel	YouTube-Eintrag	the native web GmbH, 01.03.2021	Externes Video, keine freie Nachnutzungslizenz verifiziert

Medienfreie Alternative: Nutze die Textabschnitte, ASCII-artig notierte Schrittabfolge „Änderung – statische Prüfung – Test – Build – Review“ und alle vollständigen Codebeispiele. Für das Lernprodukt sind weder Video, Audio noch externe Grafik technisch erforderlich. Spezielles fremdes Audiomaterial oder animierte Medien wurden nicht eingebunden, weil keine hinreichend passende, lizenzklar belegte Quelle für den konkreten Lernschritt bestätigt werden konnte. Das Material kann lokal und ohne kostenpflichtiges KI-Konto bearbeitet werden.