09.1-Integration und Release-Verwaltung

Unabhängig entwickelte Komponenten zu einem Gesamtsystem kombinieren.

Prüfen ob Komponenten wie im Entwurf vorgesehen zusammenarbeiten.

Big Bang/ Top down/ Bottom up/ Kontinuierliche Integration/ Inkrementell ist Big Bang meist überlegen.

Abhängige Komponenten müssen in sinnvoller Reihenfolge verfügbar sein.

Visualisiert benötigt-Beziehungen und unterstützt Top-down bzw. Bottom-up Planung.

Tabellarische Übersicht der Abhängigkeiten mit leichterer Ableitung von Integrationsschritten.

Platzhalter die fehlende Komponenten simulieren/ Einsatz wenn reale Komponente noch nicht verfügbar ist.

Bottom-up Integrationsreihenfolge aus der Matrix ableiten um Stubs zu vermeiden.

An Schnittstellen/ wegen unklarer Spezifikation oder spät verfügbaren externen Komponenten.

Zu integrierende Komponenten/ technische Voraussetzungen/ Reihenfolge/ Besonderheiten/ schriftlich für Nachvollziehbarkeit.

Früh planen/ früh beginnen/ Aufwand für Test und Integration nicht unterschätzen/ Strategie an Prozesse anpassen/ Aufwand erfassen/ Risiken reduzieren.

Falsche Komponenten integriert/ Doppelentwicklung/ verlorene Testdaten/ Arbeiten ohne Sicherung/ Änderungen überschrieben.

Versionen sind zeitliche Entwicklungsstufen/ Varianten sind parallele Ausprägungen für unterschiedliche Bedürfnisse.

Versionen sind linear mit Abzweigungen/ Varianten laufen parallel zur Hauptlinie.

Neue Auslieferung eines Konfigurationselements/ ersetzt die vorherige Version.

Parallel bestehende kundenspezifische Ausprägungen die sich nicht gegenseitig ersetzen.

Hoher Wartungsaufwand/ Portierungen in jede Variante/ Support für als veraltet angesehene Stände.

Um Releases planbar zu machen/ Welche Features in welche Version/ Welche Stände bekommen Updates/ Umgang mit Sicherheitslücken in Abhängigkeiten.

Das faktische Versprechen nach außen oft Handbuch oder Spezifikation nicht nur Code-APIs.

Seltene Änderungen/ nachvollziehbares Versionierungsschema/ semantische Änderungen sollen sich syntaktisch widerspiegeln.

Nachvollziehbare Regeln statt Bauchgefühl/ SemVer definiert klare Erhöhungsregeln.

Projekte bauen auf Bibliotheken und Diensten auf/ Abhängigkeiten wachsen mit Projektgröße.

Lock: zu strikte Bindung erzeugt Update-Lawinen/ Promiscuity: zu lax führt zu falscher Kompatibilitätsangabe.

Bei Lock/ Promiscuity oder beidem wodurch Entwicklung stark behindert wird.

Situation analysieren/ Soll definieren/ Schritte planen/ konsistentes Versionierungsregelwerk anwenden zB SemVer.

Tom Preston-Werner/ Regelwerk kompakt auf semver.org.

MAJOR.MINOR.PATCH/ MAJOR bei inkompatiblen Änderungen/ MINOR bei kompatiblen Features/ PATCH bei kompatiblen Bugfixes/ Prärelease und Build-Metadaten möglich.

Version core aus major.minor.patch optional Prärelease mit - und Build mit +.

Öffentliche API muss klar/ präzise/ ausführlich dokumentiert sein als Doku oder Code.

Veröffentlichten Inhalt nicht ändern/ Änderungen immer als neue Version releasen.

0.y.z ist instabile Entwicklungsphase/ ab 1.0.0 ist die öffentliche API definiert.

Bei produktiver Nutzung oder bestehender stabiler API auf die sich Nutzer verlassen.

Langes Verbleiben unter 1.0 trotz Stabilität verwechselt die Aussage zur API-Stabilität.

Bei reinen kompatiblen Bugfixes/ unklare erwartete Verhaltensbeschreibung kann Abgrenzung erschweren.

Bei kompatiblen Features/ bei Deprecation-Ankündigungen/ optional bei größeren internen Änderungen/ PATCH wird dabei auf 0 gesetzt.

Bei API-inkompatiblen Änderungen/ MINOR und PATCH werden auf 0 gesetzt.

Prärelease und Build-Metadaten/ definierte Sortierung zB 1.0.0-alpha < 1.0.0.

Deprecation vorher in MINOR ankündigen/ versehentliche Regelverletzung auf gleicher Ebene reparieren und dokumentieren.

Verstöße erkennen/ Entfernen von Kreditkarten ist MAJOR nicht MINOR/ Bugfixes gehören als PATCH nicht als neue MAJOR.