Bereitstellung und Betrieb

Bereitstellung und Betrieb

0:00 Wann ist eine App eigentlich fertig? Die ehrlichste Antwort, die ich kenne: Wenn jemand anderes sie installieren, betreiben und im Fehlerfall zurücknehmen kann. Alles davor ist ein Prototyp mit guter Laune. In diesem Modul geht es um genau diese letzte Strecke — Umgebungen, Releases, Beobachtung, Verteilung. Das ist der Teil, der in Seminaren gern gekürzt wird und im Projekt am längsten nachwirkt.

0:24 Und es ist der Teil, bei dem Forge einem viel abnimmt, solange man die Reihenfolge der Befehle kennt.

Bereitstellung und Betrieb

0:30 Nach der Migration am Vormittag jetzt der Betrieb. Wir klären, was die drei Umgebungen bedeuten, wie eine Version von der Änderung bis zur Installation kommt, was man im laufenden Betrieb beobachtet und welche Wege nach draußen es gibt. Am Ende steht eine Release-Checkliste für Klarpfad — und eine Betriebsnotiz, die auch jemand lesen kann, der die App nicht gebaut hat.

Umgebungen trennen

0:51 Beginnen wir mit den drei Umgebungen — und mit der häufigsten Verwechslung der ganzen Woche. Forge kennt drei Umgebungen: Entwicklung, Staging, Produktion. Jede hat eigene Installationen, eigene Variablen und vor allem eigene Daten. Das ist mehr als Organisation — es ist der Grund, warum Sie in der Entwicklung ohne Sorge ausprobieren können.

1:12 Praktisch hilfreich ist der Namenszusatz: In Entwicklung und Staging trägt der App-Titel ein Suffix, in Produktion nicht. Nutzende sehen also, womit sie gerade arbeiten. Klingt nach einem Detail und erspart im Support erstaunlich viele Missverständnisse. Fünf Zeilen, und alles hängt an zwei Buchstaben: der Angabe der Umgebung. Die erste Zeile ohne Angabe geht in die Entwicklung.

1:36 Die weiteren adressieren gezielt Staging und Produktion. Beachten Sie die letzte Zeile: Ist die App auf einer Site schon installiert, aktualisieren Sie mit dem Upgrade-Schalter, statt neu zu installieren. Und die Fußzeile ist die Warnung, die ich Ihnen mit auf den Weg gebe: Ohne Angabe arbeiten alle Befehle auf der Entwicklung.

1:55 Das ist die häufigste Verwechslung überhaupt — auch bei erfahrenen Teams, meist freitags. Vier Gründe, und der erste knüpft an gestern an: Der Speicher ist je Installation getrennt, Testdaten bleiben also in der Testumgebung. Ein fehlerhafter Stand trifft nur die Umgebung, in der er steht — das ist die eigentliche Versicherung.

2:15 Variablen und Zugangsdaten unterscheiden sich, was verhindert, dass ein Test versehentlich gegen ein Produktivsystem läuft. Und der Namenszusatz macht für Nutzende sichtbar, was sie vor sich haben. Vier kleine Dinge, die zusammen den Unterschied zwischen ruhigem und aufregendem Betrieb ausmachen. Der erste Punkt ist der eben erwähnte fehlende Umgebungsschalter — mit unangenehmer Wirkung, wenn er beim Ausrollen fehlt und die Produktion trifft, die man gar nicht gemeint hatte.

2:42 Der zweite ist der, der Datenschützer nervös macht: Produktionsdaten zum Testen in die Entwicklung kopieren. Das ist fast immer unnötig; realistische Testdaten lassen sich erzeugen. Und der dritte ist eine Frage der Disziplin: Staging existiert, wird aber übersprungen, weil es schneller geht. Es geht genau so lange schneller, bis es das nicht mehr tut.

Von der Änderung zur installierten Version

3:03 Jetzt der Weg selbst — und der Schritt, den man auch am fünften Tag noch vergisst. Der Weg ist immer derselbe: bauen und prüfen, ausrollen, installieren oder aktualisieren, im Produkt gegenprüfen. Neu ist hier vor allem die Berechtigungsfrage am Ende: Ändern sich Scopes, verlangt das Upgrade eine erneute Zustimmung der Administration.

3:24 Das Entfernen von Scopes tut das nicht — eine hilfreiche Asymmetrie, die wir gestern schon besprochen haben. Sie bedeutet praktisch: Aufräumen ist jederzeit möglich, Erweitern kostet eine Abstimmung. Vier Glieder, und das letzte ist das, welches am häufigsten fehlt. Lint und Tests, ausrollen, installieren oder aktualisieren — und dann im Produkt prüfen.

3:45 Dieses letzte Glied ist kein Formalismus: Genau dort zeigt sich, ob das Upgrade tatsächlich stattgefunden hat oder ob noch die alte Fassung läuft. Zwei Minuten im Produkt ersparen den Anruf am Montag. Und wenn Sie die vier Glieder als feste Kette verinnerlicht haben, brauchen Sie die Checkliste eigentlich nur noch für die Kollegen.

4:05 Fünf Schritte, deren Reihenfolge Risiko abbaut. Lint und Tests zuerst, und das Ergebnis festhalten — nicht für die Akten, sondern damit man später weiß, was geprüft war. Dann Staging mit der Prüfliste vom vierten Tag. Dann Produktion mit Upgrade. Schritt vier ist der organisatorische: die Zustimmung einholen, falls Scopes hinzugekommen sind.

4:26 Und Schritt fünf ist der, den die Fußzeile eigens hervorhebt: ein vollständiger Ablauf im Produkt. Er fällt am häufigsten weg — und genau dort zeigt sich ein fehlendes Upgrade. Der erste Punkt ist der Klassiker, den wir seit dem ersten Tag verfolgen: Nach dem Ausrollen fehlt das Upgrade, und die alte Fassung läuft weiter — mit dem verwirrenden Effekt, dass manche Kunden die Änderung sehen und andere nicht.

4:51 Der zweite ist der administrative: Die Zustimmung bleibt aus, das Upgrade hängt, und niemand merkt es, weil nichts kaputt aussieht. Und der dritte ist der, den man sich nie eingesteht: Freigegeben wird ein Stand, der nur im Tunnel geprüft wurde.

Betrieb beobachten

5:05 Damit zum laufenden Betrieb — und zu der Frage, woran man merkt, dass etwas schiefläuft, bevor es jemand meldet. Sie haben zwei Blickwinkel. Protokolle sagen, was passiert ist — einzelne Ereignisse, mit Details. Metriken sagen, wie oft und wie schnell — also das Muster. Für die Fehlersuche brauchen Sie Protokolle, für die Beobachtung Metriken. Dazu kommt der Verbrauch, der aus Aufrufen und Speicher entsteht und sich in Kosten niederschlägt.

5:34 Diese drei Dinge gehören zusammen betrachtet. Wer nur Protokolle liest, sieht Bäume und keinen Wald. Fünf Zeilen, und die rechte Spalte ist die eigentliche Botschaft: Für jede Größe gibt es ein typisches Warnsignal. Ein Anstieg der Fehlerrate nach einem Release. Schleichend längere Laufzeiten. Ein wiederkehrender Fachfehler in den Protokollen — oft ein Hinweis, dass eine Meldung unverständlich ist und Nutzende immer wieder dasselbe falsch machen.

6:00 Und die Fußzeile nennt das Signal, das Sie am zweiten Tag schon kennengelernt haben: Vervielfachte Aufrufe bei gleicher Nutzung bedeuten fast immer einen Effekt ohne saubere Abhängigkeit. Der erste Punkt beschreibt den Normalzustand in vielen Teams: Beobachtet wird erst, wenn die erste Meldung kommt. Dann ist die Ursache oft schon Tage alt.

6:20 Der zweite ist die halbe Lösung — Protokolle werden gelesen, Metriken nie, und damit fehlt genau der Blick auf Muster. Und der dritte ist eine Gewohnheit, die sich leicht ändern lässt: Nach einem Release schaut niemand nach, ob die Fehlerrate steigt. Fünf Minuten am Tag nach dem Release, mehr braucht es nicht.

Verteilungswege

6:39 Bleibt die Frage, wie die App zu ihren Nutzenden kommt — und die hat zwei sehr unterschiedliche Antworten. Für den internen Einsatz genügt ein Installationslink aus der Entwicklerkonsole. Wichtig dabei: Solange die Verteilung auf „nicht geteilt" steht, erreichen ihn nur Mitwirkende der App — ein Detail, das regelmäßig für ratlose Kollegen sorgt, die den Link bekommen haben und nichts installieren können.

7:02 Der Marketplace ist der andere Weg: für fremde Kunden, mit Listung, Prüfungen und Nachweisen. Die beiden Wege unterscheiden sich weniger in der Technik als in allem, was drumherum verlangt wird. Die Gegenüberstellung macht den Unterschied in vier Zeilen deutlich. Links genügt ein Link, rechts braucht es Listung und Prüfung. Links eigene Sites, rechts fremde Kunden.

7:25 Links eine Freigabe im Haus, rechts Sicherheitsnachweise. Und links schnell änderbar, rechts Versionen und Zusagen. Wenn Sie den rechten Weg gehen wollen, planen Sie Vorlauf ein — nicht für die Technik, sondern für alles andere. Der linke Weg dagegen ist in einer Stunde eingerichtet. Vier Gründe, und der erste ist der überraschendste: Lizenzierung im Manifest schließt den Installationslink aus.

7:50 Wer also früh Lizenzierung einschaltet, blockiert sich das einfache interne Testen. Der zweite Punkt betrifft Nachweise mit Vorlauf. Der dritte ist der, der im Alltag zubeißt: Nutzende außerhalb des Mitwirkendenkreises brauchen eine geteilte Verteilung — auch Kundenkonten im Service-Portal. Und der vierte fasst zusammen: Ein Wechsel des Wegs ändert Anforderungen an App und Dokumentation.

8:14 Der erste Punkt ist der eben beschriebene ratlose Kollege mit dem Link. Der zweite ist die früh eingeschaltete Lizenzierung, die das Testen blockiert — und sich nicht einfach zurücknehmen lässt. Und der dritte klingt harmlos und ist es nicht: Release Notes der Plattform werden vor einem Upgrade nicht gelesen. Genau dort stehen die Hinweise auf abgekündigte Laufzeiten, geänderte Komponenten und neue Anforderungen — die Themen, über die wir diese Woche gesprochen haben.

Übung

8:40 In der Übung schreiben Sie auf, was bisher nur in Ihrem Kopf steht — und probieren den Rückweg einmal aus. Klarpfad soll bei der Falkenmoos GmbH intern verteilt werden. Damit stellen sich Fragen, die nicht im Code stehen: Wer aktualisiert die App? Wer reagiert im Fehlerfall? Und wie sieht ein Rückzug auf die Vorversion aus? Diese drei Fragen entscheiden darüber, ob eine App betreut wird oder nur existiert.

9:05 Und sie sind schnell beantwortet, solange man sie stellt, bevor der erste Vorfall eintritt. Zwei Ergebnisse: eine Checkliste mit Befehlen und eine Betriebsnotiz. Das Erfolgskriterium nennt drei Inhalte für die Notiz — Beobachtung, Zuständigkeit, Rückzugsweg. Besonders der letzte ist wichtig, weil er im Ernstfall unter Zeitdruck gebraucht wird und dann niemand nachdenken möchte.

9:29 Wer früh fertig ist, ergänzt, was sich ändert, sobald ein Scope hinzukommt — ein Fall, der bei einer lebenden App früher oder später sicher eintritt. Die Schritte eins und zwei machen aus Wissen ein Dokument: alle Schritte aufschreiben, je Schritt den Befehl mit Umgebung ergänzen. Schritt drei ist der Realitätstest — einmal nach Staging ausrollen und die Liste tatsächlich durchlaufen. Dabei fallen die Lücken auf, nicht beim Schreiben.

9:55 Schritt vier klärt Beobachtung und Zuständigkeit. Und Schritt fünf ist der, den fast alle überspringen: den Rückzug beschreiben und einmal durchspielen. Ein Rückweg, den man nie gegangen ist, ist eine Vermutung. Drei Punkte, die Sie in echten Teams wiederfinden werden. Die Checkliste endet mit dem Deployment — dabei beginnt der Betrieb genau dort.

10:16 Der Rückzugsweg wird beschrieben, aber nie ausprobiert. Und die Zuständigkeit bleibt bei der Person, die die App gebaut hat; das funktioniert, bis diese Person im Urlaub ist. Nach der Pause folgt das Abschlussprojekt — dort führen Sie Ihre App vor und lassen sie von einer anderen Gruppe prüfen.