ESW Dev

ESW Entwicklungsumgebung · esw-dev.de

Build und Deployment

Einordnung

Dieses Dokument beschreibt den Build- und Deployment-Prozess der Einsatzsoftware. Es definiert, wie aus Quellcode nachvollziehbare, prüfbare und offline verteilbare Releases entstehen und wie diese in den Zielumgebungen installiert, aktualisiert und zurückgerollt werden.

Der Inhalt ist absichtlich technologie- und sprachneutral. Er legt Randbedingungen fest, die spätere Technologieentscheidungen (Programmiersprachen, Frameworks, Toolchains) objektiv begrenzen.

Referenzen:

Zielsetzung

Der Build- und Deployment-Ansatz MUSS folgende Ziele erfüllen:

  • Offline installierbar und offline aktualisierbar
  • Nachvollziehbare Versionierung und Release-Artefakte
  • Integritätsschutz der Artefakte (Manipulationsschutz)
  • Betrieb durch hauptamtliche Strukturen realistisch möglich
  • Unterstützung durch Ehrenamt (2nd Level, Entwicklung) möglich
  • Langfristig wartbar (mehrjährige Releasezyklen möglich)

Nicht-Ziele in dieser Phase:

  • Vollständiges Sicherheitskonzept (siehe Security-Baseline)
  • Vollständige CI/CD-Implementierung im Detail
  • Festlegung auf konkrete Paketformate (wo noch offen)

Begriffe

  • Build: Erzeugung von Artefakten aus Quellcode.
  • Artefakt: Paket, Container, Installer, Image, Konfigurationsbundle.
  • Release: Versionierte Menge von Artefakten inkl. Release Notes.
  • Deployment: Installation und Inbetriebnahme von Artefakten.
  • Rollback: Rückkehr auf eine vorherige Version.
  • Offline-Deployment: Verteilung ohne Internetzugang (USB, lokales Netz).

Randbedingungen aus der Betriebsumgebung

Aus Betriebsumgebung ergeben sich u. a.:

  • Windows 10 LTSC (derzeit), Windows 11 LTSC (geplant)
  • Debian als Serverplattform (wenn Linux-Server genutzt werden)
  • Containerbetrieb zulässig, aber nur Docker oder Podman
  • Kein Kubernetes oder vergleichbare Orchestrierung als Voraussetzung
  • Offline installierbar und offline nutzbar (auch Updates)
  • iOS/Android für mobile Datenerfassung (Gerätegenerationen gemischt)
  • Edge/Firefox als relevante Browser auf Windows-Clients

Grundprinzipien

Offline-First für Artefakte

Alle produktiven Releases MÜSSEN als offline verteilbare Pakete bereitgestellt werden.

Das bedeutet:

  • Artefakte dürfen keine Internet-Downloads zur Laufzeit erzwingen.
  • Abhängigkeiten MÜSSEN entweder gebündelt oder spiegelbar sein.
  • Der Betrieb MUSS ohne Zugriff auf externe Registries möglich sein.

Nachvollziehbarkeit und Reproduzierbarkeit

Builds SOLLTEN reproduzierbar sein (deterministisch), mindestens aber stabil nachvollziehbar.

Mindestanforderungen:

  • Jede Version ist über ein Tag/Commit eindeutig referenzierbar.
  • Build-Umgebung und Abhängigkeiten sind versioniert dokumentiert.
  • Artefakte tragen eindeutige Versionskennzeichen.

Integrität und Vertrauenskette

Artefakte MÜSSEN vor Manipulation geschützt werden.

Mindestens:

  • Für jedes Release: Prüfsummen (z. B. SHA-256) je Artefakt.
  • Digitale Signaturen SOLLTEN für Release-Bundles genutzt werden.
  • Signierschlüssel MÜSSEN geschützt verwaltet werden (siehe Security-Baseline).

Minimaler Betriebsaufwand

Deployment MUSS mit behördlichen Betriebsrealitäten vereinbar sein:

  • Standardisierte Installationsschritte
  • Klare Update- und Rollback-Prozeduren
  • Keine fragile, hochkomplexe Toolchain auf Client-Systemen
  • Diagnosefähigkeit durch Logs und Health-Checks

Langlebigkeit

Der Ansatz MUSS langfristige Wartung ermöglichen:

  • LTS-Releasezweige sind möglich.
  • Sicherheitsfixes sind unabhängig von Feature-Releases möglich.
  • Alte Releases müssen reproduzierbar nachbaubar oder mindestens aus Archiv installierbar bleiben.

Artefaktstrategie nach Plattform

Dieses Kapitel beschreibt, welche Artefakte pro Plattform sinnvoll sind. Wo Entscheidungen noch offen sind, werden Optionen aufgezeigt.

Windows-Clients (Arbeitsplätze)

Ziele:

  • Einfache Installation
  • Offline-Updates
  • Rollback möglich
  • Keine Adminrechte, soweit realistisch

Mögliche Artefaktformen (Optionen):

  • Installer (z. B. MSI/MSIX/EXE)
  • Portable ZIP (Self-contained, ohne Installation)
  • Kiosk-/Display-Mode als spezielle Konfiguration

MUSS-Anforderungen:

  • Offline installierbar
  • Offline aktualisierbar
  • Versionsnummer sichtbar
  • Installationsanleitung pro Version

SOLL-Anforderungen:

  • Code Signing des Installers
  • Automatisierbarer Silent-Install (z. B. für Rollout)

Mobile Clients (Android / iOS)

Ziele:

  • Robuste Datenerfassung im Einsatz
  • Offline-Nutzung
  • Kontrollierbare Verteilung (Behörden-/Organisationsbetrieb)

Artefaktformen (Optionen):

  • Android: signierte APK (und optional AAB für Store/MDM)
  • iOS: signierte IPA (Verteilung via MDM/Enterprise/Store)

MUSS-Anforderungen:

  • Offline nutzbar nach Installation
  • Version sichtbar
  • Updatepakete müssen offline bereitstellbar sein (z. B. via MDM oder manuelles Einspielen, je nach Betrieb)

SOLL-Anforderungen:

  • Geräteverwaltung (MDM) als bevorzugter Verteilweg (Details später zu konkretisieren)
  • Kryptografische Schlüsselmaterialien geschützt im OS (siehe Security-Baseline)

Hinweis:

Die konkrete Distributionsstrategie (Store vs. MDM vs. Enterprise) ist eine spätere Betriebsentscheidung, MUSS aber offlinefähig geplant werden (z. B. Rollout im abgeschotteten Netz).

Anzeige-/Kiosk-Systeme (z. B. Raspberry Pi)

Ziele:

  • Autostart der Visualisierung
  • Minimaler Pflegeaufwand
  • Robustheit im Dauerbetrieb

Artefaktformen (Optionen):

  • Vorgefertigtes System-Image (SD-Karte/SSD) mit Kiosk-Setup
  • Containerbundle (falls Kiosk-Inhalt containerisiert ist)
  • Lokale Installation + Autostartskript

MUSS-Anforderungen:

  • Offline installierbar
  • Autostart der vorgesehenen Anzeige
  • Dokumentierte Wiederherstellung (Re-Image)

Server-Komponenten (Debian)

Ziele:

  • Betrieb lokal, föderiert oder zentral möglich
  • Offline-Installation und -Updates
  • Betrieb ohne komplexe Orchestrierung
  • Container optional, aber nicht zwingend

Artefaktformen (Optionen):

  • Debian-Pakete (DEB) über lokales Repo oder Bundle
  • Containerimages (Docker/Podman), offline als TAR exportierbar
  • Compose/Podman-Compose Bundle inkl. Konfiguration

MUSS-Anforderungen:

  • Offline installierbar
  • Offline aktualisierbar
  • Konfiguration versioniert und dokumentiert
  • Upgradepfad dokumentiert

SOLL-Anforderungen:

  • Trennung von Konfiguration und Daten (12-Factor-Prinzip soweit sinnvoll, ohne Cloud-Annahmen)
  • Health-Checks pro Dienst
  • Automatisierbarer Start/Stop

Build-Prozess

Quellcode und Versionierung

MUSS:

  • Jede Release-Version ist durch ein Git-Tag oder equivalent markiert.
  • Changelog pro Release ist vorhanden.
  • Versionierung ist eindeutig und konsistent.

SOLL:

  • Semantische Versionierung (SemVer) oder ein äquivalentes Schema, das kompatible und nicht kompatible Änderungen erkennbar macht.

Build-Umgebungen

MUSS:

  • Build-Umgebung ist dokumentiert (OS, Toolchain, Versionen).
  • Builds sind automatisierbar (Script/CI).

SOLL:

  • Builds erfolgen in kontrollierten Build-Containern oder auf definierten Build-Agenten, um Drift zu vermeiden.
  • Separate Build-Pipelines pro Zielplattform (Windows, Linux, Android, iOS) mit konsistenter Artefaktbenennung.

Abhängigkeitsmanagement

MUSS:

  • Abhängigkeiten sind versioniert festgelegt (Lockfiles, Pinning).
  • Abhängigkeiten sind offline verfügbar oder spiegelbar.

SOLL:

  • Interne Spiegel (Mirror/Proxy) für Paketquellen:
    • OS-Pakete (Debian)
    • Container-Registry (privat)
    • Sprach-/Build-Abhängigkeiten (z. B. Maven/NuGet/npm, je nach Stack)
  • Dependency-Bundling für Offline-Builds, wo Spiegel nicht reichen.

Build-Artefakte und Metadaten

MUSS:

  • Jede Ausgabe enthält:
    • Version
    • Build-Datum/Zeit
    • Commit-Referenz
  • Release umfasst:
    • Artefakte
    • Prüfsummen
    • Release Notes
    • Installations-/Updateanleitung

SOLL:

  • SBOM (Software Bill of Materials) pro Release.
  • Signierte Release-Manifestdatei.

Deployment-Modelle

Lokales Einzelsetup (Vehicle/Standort)

Typisch für Einsatzbetrieb:

  • Lokaler Server (optional) + mehrere Clients im lokalen Netz
  • Offlinefähig, später Synchronisation möglich (siehe Netzausfall)

Deployment MUSS:

  • ohne Internet funktionieren
  • über USB oder lokales Netz installierbar sein

Föderiertes Setup

Mehrere lokale Instanzen, die bei Gelegenheit Daten austauschen.

Deployment SOLL:

  • identische Artefakte je Standort nutzen
  • klare Upgrade-Kompatibilitätsregeln haben
  • Konflikt- und Versionsmechanismen nicht beschädigen (siehe Netzausfall)

Zentrales Setup (Stab/LuK)

Zentraler Server, mehrere Clients greifen zu.

Deployment MUSS:

  • Updates planbar machen (Wartungsfenster)
  • Rollback ermöglichen, zumindest für Anwendungsebene

Update-Strategie

Release-Kanäle

SOLL:

  • Stable: für Produktivbetrieb
  • Test: für Erprobung (Pilotgruppen)
  • Hotfix: für kritische Fehler/Sicherheitslücken

Kompatibilität

MUSS:

  • Clients und Server müssen innerhalb eines definierten Versionsfensters zusammenarbeiten.

SOLL:

  • “N-1” oder “N-2” Kompatibilität, je nach Aufwand und Risiko.

Datenmigration

MUSS:

  • Datenbank-/Schemaänderungen sind versioniert.
  • Migrationen sind getestet.
  • Migrationspfad ist dokumentiert.

SOLL:

  • Vorwärtsmigrationen sind idempotent oder sicher wiederholbar.
  • Rollback-Plan existiert (auch wenn Schema-Rollback nicht immer möglich ist, muss ein betriebliches Rollback möglich sein).

Offline-Updates

MUSS:

  • Updates können über physische Datenträger eingespielt werden.
  • Integrität der Updatepakete ist prüfbar (Checksums/Signaturen).

SOLL:

  • Updatepakete sind “atomar” (ein Bundle pro Version).
  • Updateprozess ist scriptbar.

Rollback-Strategie

MUSS:

  • Rollback ist für Clients mindestens als Neuinstallation der vorherigen Version möglich.
  • Rollback ist für Server mindestens auf Anwendungsebene möglich.

SOLL:

  • Snapshot/Backup vor Upgrade ist Bestandteil der Prozedur.
  • Rollback-Prozedur ist dokumentiert und regelmäßig getestet.

Observability und Diagnosefähigkeit

MUSS:

  • Logs sind verfügbar und exportierbar.
  • Fehlerfälle sind eindeutig erkennbar (Exit-Codes, Meldungen).

SOLL:

  • Strukturierte Logs (JSON) serverseitig.
  • Health-Endpunkte/Checks für Serverdienste.
  • Monitoring-Integration ist möglich (nicht zwingend Bestandteil).

Security-Aspekte im Build- und Deployment-Prozess

Dieses Kapitel ist eine Ergänzung zur Security-Baseline.

MUSS:

  • Secrets dürfen nicht im Quellcode liegen.
  • CI/CD-Secrets sind geschützt verwaltet.
  • Build-Artefakte sind gegen Manipulation prüfbar.

SOLL:

  • Signierung von Artefakten und/oder Release-Manifests.
  • SBOM-Erzeugung und Archivierung.
  • Dependency-Scanning und SAST/DAST, soweit realistisch.

Dokumentationspflichten pro Release

MUSS:

  • Release Notes (Änderungen, Fixes, ggf. Breaking Changes)
  • Installationsanleitung
  • Updateanleitung
  • Rollbackanleitung
  • Prüfsummenliste

SOLL:

  • Known Issues
  • Migrationshinweise
  • Supporthinweise (Logpfade, Diagnosekommandos)

Akzeptanzkriterien (Baseline)

Ein Build/Deployment-Konzept gilt als erfüllt, wenn:

  • Alle Zielplattformen erhalten offline installierbare Artefakte.
  • Updates sind offline einspielbar.
  • Artefakte sind versioniert, prüfbar und dokumentiert.
  • Betrieb ist ohne Internet und ohne Kubernetes möglich.
  • Support kann mit Logs und klaren Prozeduren arbeiten.

Offene Punkte (später zu präzisieren)

Diese Punkte sind bewusst als später zu klären markiert:

  • Mobile Distribution: MDM/Store/Enterprise-Mechanismen und Policies
  • Konkrete Signatur- und Schlüsselverwaltung (HSM, Rollen, Prozesse)
  • Exakte Kompatibilitätsfenster (N-1/N-2) je Modul
  • SBOM-Format und Tooling
  • Konkrete Build-Agentenlandschaft und CI/CD-Implementierung

Zusammenfassung

Build und Deployment müssen die Einsatzrealität abbilden:

  • Offlinefähigkeit ist zwingend.
  • Artefakte müssen prüfbar und langfristig archivierbar sein.
  • Betrieb muss im Hauptamt realistisch möglich sein.
  • Updates und Rollbacks müssen planbar, dokumentiert und robust sein.

Dieses Dokument schafft damit eine objektive Grundlage, um Programmiersprachen und Toolchains später anhand harter Kriterien auszuwählen.