Das Auftragsbuch hat jetzt einen neuen Weg: Die Auftragsliste kommt aus der Web-API, es gibt eine Blazor-Seite, und die Daten liegen in Azure SQL. Niemand wird das an einem Montag für alle einschalten. Frau Aydin und zwei Kollegen probieren es zuerst, dann die Disposition, dann die Firma, und bei jedem Problem muss der alte Weg in Minuten zurück sein, ohne dass jemand ein Programm neu installiert.
Dafür gibt es Schalter, die man je Person oder Gruppe umlegt. Diese Lektion baut sie mit der Bibliothek, die Microsoft dafür anbietet, legt die Stufen der Freigabe fest und sagt, woran Sie ablesen, ob die nächste Stufe kommen darf. Wie man eine neue Version eines Programms stufenweise ausliefert (Einsatzstufen, Umgebungen, Pipeline), steht in K3, Modul 3.7; hier geht es um eine Funktion, die in einer Version schon steckt, aber nicht für alle gilt.
Zwei Arten von Schaltern
Eine Version auszurollen und eine Funktion freizuschalten sind zwei Entscheidungen. Man verwechselt sie leicht, und dann fehlt bei einem Fehler der passende Handgriff:
| Version ausliefern | Funktion freischalten (Feature-Schalter) | |
|---|---|---|
| Frage | Welcher Code läuft? | Welchen Weg nimmt der Code für diese Person? |
| Gilt für | alle, die diese Version haben | je Person, Gruppe oder Prozent |
| Rückfall | alte Version wieder ausliefern (Minuten bis Stunden) | Schalter umlegen (Sekunden bis Minuten) |
| Wer entscheidet | Pipeline und Betrieb | Fachbereich und Projekt, gemeinsam |
| Lebensdauer | bis zur nächsten Version | bis zum Ende der Migration, dann wird der Schalter gelöscht |
Der letzte Punkt ist der wichtigste. Ein Schalter für die Migration ist Schulden mit Fälligkeitsdatum: Jeder Schalter verdoppelt die Zahl der Wege, die jemand testen müsste, und ein Schalter, der nach dem Abschalten des alten Programms noch im Code steht, führt zu totem Code mit Bedeutung. Schreiben Sie bei jedem Schalter dazu, wann er verschwindet; in Lektion M6.5 räumen Sie sie auf.