Entwicklungsumgebung und App-Lebenszyklus

Entwicklungsumgebung und App-Lebenszyklus

0:00 Im ersten Modul haben wir entschieden, was gebaut werden soll und wo es erscheint. Jetzt geht es darum, das tatsächlich sichtbar zu machen. Der Weg dorthin ist bei Forge kurz — vier Befehle, und die App läuft in einer echten Jira-Instanz. Genau diese Kürze ist allerdings auch die Falle: Weil es so schnell geht, gehen viele diesen Weg nie bewusst zu Ende und wundern sich später, warum eine Änderung bei anderen nicht ankommt.

0:24 Wir gehen ihn deshalb einmal vollständig, mit allen Zwischenschritten, und schauen uns dabei an, wo eine App eigentlich lebt.

Von der leeren Instanz zur laufenden App

0:31 Dieser zweite Teil des ersten Tages ist bewusst praktisch. Wir legen ein Projekt an, verstehen seine Struktur, klären die Laufzeit und melden die erste Berechtigung an. Am Ende steht eine App, die Sie in Jira anklicken können — und das Wissen, welcher Befehl was bewirkt. Das ist wichtiger, als es klingt, denn fast jedes Problem der kommenden Tage lässt sich auf die Frage zurückführen: Welcher Stand läuft gerade eigentlich wo?

Forge CLI und Entwicklungsinstanz

0:57 Fangen wir mit dem Werkzeug an, das Sie in den nächsten fünf Tagen am häufigsten in der Hand haben werden: der Forge CLI. Die CLI ist die einzige Brücke zwischen Ihrem Arbeitsplatz und der Plattform. Das ist angenehm, weil es keine zweite Wahrheit gibt — es gibt kein Portal, in dem man nebenbei etwas anderes einstellt. Sie erzeugt das Projekt, registriert die App unter einer festen Kennung, rollt sie in eine Umgebung aus und installiert sie auf einer Site.

1:24 Wichtig ist der letzte Baustein: die Entwicklungsinstanz. Das ist eine eigene Jira-Cloud-Umgebung, in der Sie installieren dürfen, ohne jemandem den Arbeitstag zu verderben. Wer hier mit einer produktiven Instanz arbeitet, lernt das früher oder später auf die unangenehme Weise. Merken Sie sich diese vier Glieder, sie erklären später die meisten Verwirrungen. Sie ändern etwas. Sie rollen aus — damit liegt der neue Stand auf der Plattform.

1:50 Sie installieren oder aktualisieren — damit kommt er auf einer konkreten Site an. Und erst dann ist er sichtbar. Die entscheidende Einsicht steckt zwischen dem zweiten und dritten Glied: Ausrollen allein reicht nicht immer. Solange sich nur Code ändert, genügt es meist. Sobald sich das Manifest ändert, fehlt ohne Installation der halbe Schritt.

2:12 Diese sechs Zeilen sind der komplette Weg von nichts zu einer laufenden App. Sie installieren die CLI, melden sich an, erzeugen ein Projekt aus der UI-Kit-Vorlage, rollen aus und installieren. Worauf es ankommt, steht nicht im Befehl, sondern in der Fußzeile: Ohne Angabe einer Umgebung arbeiten alle diese Befehle auf der Entwicklungsumgebung.

2:32 Das ist bequem und richtig, solange man es weiß. Es ist eine der häufigsten Ursachen für den Satz „bei mir funktioniert es" — weil tatsächlich zwei verschiedene Stände in zwei verschiedenen Umgebungen laufen. Der Tunnel ist das Werkzeug, das die Entwicklung erträglich macht: Ihre Instanz spricht mit dem Code auf Ihrem Rechner, Sie speichern, laden neu und sehen das Ergebnis.

2:54 Die Ausgaben laufen dabei in Ihrem Terminal mit. Der entscheidende Schritt ist Nummer vier, und er wird am häufigsten vergessen: Was im Tunnel funktioniert hat, existiert für alle anderen noch nicht. Erst das Ausrollen macht daraus einen Stand, den die Plattform kennt. Und wenn Sie am Manifest etwas geändert haben, kommt die Installation dazu.

3:14 Diese Reihenfolge lohnt sich als Gewohnheit, nicht als Nachschlagewerk. Alle drei Punkte sind Varianten desselben Missverständnisses über den Ort des Codes. Die Änderung wirkt nur im Tunnel und ist nach dem Schließen weg — der Klassiker am Ende eines langen Nachmittags. Eine Manifest-Änderung wird ausgerollt, aber nicht installiert, und die App verhält sich rätselhaft altmodisch.

3:36 Und der dritte Punkt ist kein technischer, sondern ein organisatorischer: Entwickelt wird auf einer Instanz mit echten Projektdaten. Das geht sehr lange gut und dann einmal nicht.

Projektstruktur und manifest.yml

3:47 Schauen wir uns an, was die Vorlage eigentlich angelegt hat — und warum die Struktur genau so aussieht. Die Struktur eines UI-Kit-Projekts erzählt bereits die Architektur. Es gibt zwei Einstiegspunkte, und das ist Absicht: Die Oberfläche liegt im Frontend-Ordner, die Resolver liegen daneben. Diese Trennung ist nicht Geschmackssache, sondern eine Vertrauensgrenze, über die wir am dritten Tag ausführlich sprechen werden.

4:12 Das Manifest hält beides zusammen — es verbindet Modul, Oberfläche und Backend-Funktion und beschreibt zugleich Berechtigungen und Laufzeit. Wenn Sie eine fremde Forge-App verstehen wollen, lesen Sie zuerst diese Datei. Sie ist kürzer als jede Dokumentation und aktueller. Hier ist das Manifest in seiner kleinsten sinnvollen Form.

4:32 Verfolgen Sie einmal die Verweise, dann sehen Sie das Prinzip: Das Modul nennt eine Ressource, und unten steht, welche Datei diese Ressource ist. Das Modul nennt einen Resolver, und die Funktion mit diesem Schlüssel wird an anderer Stelle mit ihrem Einstiegspunkt angemeldet. Alles ist über Schlüssel verbunden, nichts über Dateipfade im Code.

4:51 Das ist der Grund, warum eine Umbenennung hier so leicht schiefgeht — der Schlüssel muss auf beiden Seiten stimmen, und niemand prüft das für Sie, außer dem Ausrollen selbst. Diese vier Pfade sind das ganze Projekt. Was ich Ihnen mitgeben möchte, ist die Logik dahinter: Jede Zeile hat genau eine Verantwortung. Das Manifest beschreibt, das Frontend zeigt, die Resolver handeln, die Paketdatei verwaltet.

5:15 Sobald Sie merken, dass Fachlogik im Frontend-Ordner wächst, ist das ein Signal — nicht weil es verboten wäre, sondern weil dieser Code später nicht mehr abzusichern ist. Die Fußzeile nennt nebenbei eine harte Grenze: Das Manifest darf zweihundert Kilobyte groß werden. Das klingt viel und reicht auch, aber bei sehr großen Apps ist es schon knapp geworden.

5:37 Der erste Punkt ist menschlich völlig nachvollziehbar: Im Frontend sieht man das Ergebnis sofort, im Resolver muss man ausrollen. Deshalb wandert Logik nach oben. Der Preis kommt am vierten Tag, wenn wir über Sicherheit sprechen. Der zweite Punkt trifft jeden einmal: Schlüssel im Manifest und Ordnername laufen auseinander, und die Fehlermeldung ist weniger hilfreich, als man hoffen würde.

5:59 Und der dritte ist eine Frage der Disziplin — mehrere Module in einer Datei sind am Anfang bequem und nach drei Monaten unlesbar.

Laufzeit und Versionsstände

6:07 Jetzt ein Thema, das im Seminar unspektakulär wirkt und im Projektalltag regelmäßig für Aufregung sorgt: Versionen. Im Manifest steht, in welcher Node-Version Ihre Funktionen laufen. Zum Stichtag dieses Seminars empfiehlt Atlassian nodejs24.x; die Versionen 22 und 20 werden noch unterstützt. Das ist eine dieser Angaben, die man einmal schreibt und dann nie wieder ansieht — und genau deshalb erwähne ich sie so ausdrücklich. Laufzeiten werden abgekündigt.

6:36 Wenn das passiert, ist es kein Notfall, solange man es mitbekommt, und ein sehr unangenehmer Termin, wenn nicht. Optional lassen sich Speicher und Architektur angeben, was bei rechenintensiven Funktionen ein Thema wird. Drei Zeilen, mehr ist es nicht. Interessant ist die Fußzeile: Die Angabe ist nicht optional. Ohne sie bricht das Ausrollen ab.

6:58 Das ist eine bewusste Entscheidung der Plattform — sie zwingt Sie, eine Laufzeit zu benennen, statt Ihnen stillschweigend irgendeine zuzuweisen, die sich später ändert. Ähnlich hilfreich ist die Speicherangabe: Sie ist ein Hebel, wenn Funktionen an Grenzen stoßen, und zugleich einer, der Kosten beeinflusst. Beides gehört in die Notiz, die Sie ohnehin über Ihre Architekturentscheidungen führen.

7:22 Vier Gründe, und sie haben alle dieselbe Struktur: Etwas ändert sich außerhalb Ihres Projekts, und Sie merken es nur, wenn Sie hinsehen. Laufzeiten werden abgekündigt. Die CLI wird jeweils sechs Monate nach ihrem Erscheinen unterstützt. Die Paketversionen ändern Komponenten und Verhalten. Und Vorschaufunktionen ändern sich ohnehin, wann sie wollen. Meine Empfehlung: Setzen Sie sich einen festen Termin — einmal im Quartal ins Änderungsprotokoll schauen.

7:50 Das kostet zwanzig Minuten und erspart Ihnen den Tag, an dem plötzlich nichts mehr geht. Der mittlere Punkt wird Sie im Alltag am häufigsten treffen, deshalb hebe ich ihn hervor: Beispielcode aus dem Netz setzt fast immer eine ältere Paketversion voraus. Das ist bei Forge ein so großes Thema, dass wir am fünften Tag ein eigenes Modul dafür haben.

8:10 Die anderen beiden Punkte sind schlichte Aufmerksamkeitsfragen — die Laufzeit steht seit dem ersten Tag unverändert da, und das Änderungsprotokoll wird erst gelesen, wenn etwas kaputt ist. Dann steht allerdings meist schon eine Anfrage von einem Kunden daneben.

Berechtigungen im Manifest anmelden

8:24 Zum Abschluss des Tages das Thema, das eine Forge-App von einer gewöhnlichen Anwendung am deutlichsten unterscheidet: Berechtigungen stehen in einer Datei. Das ist ein ungewohnter, aber ausgesprochen gesunder Ansatz. Was Ihre App darf, steht nicht im Code verstreut, sondern an einer Stelle — und diese Stelle kann ein Administrator lesen, bevor er die App installiert.

8:46 Was dort nicht steht, ist zur Laufzeit nicht möglich. Aufrufe an Domains, die nicht angemeldet sind, werden abgewiesen. Braucht Ihre App gar keine Rechte, schreiben Sie eine leere Liste — auch das ist eine Aussage, und zwar eine ausgesprochen vertrauenswürdige. Zwei Blöcke, zwei Richtungen. Oben, was die App im Produkt tun darf — hier lesen und schreiben. Unten, wohin sie nach draußen sprechen darf.

9:11 Die Fußzeile ist der eigentliche Merksatz: Jeder Scope braucht einen Grund, der sich einem Administrator erklären lässt. Das ist kein bürokratischer Wunsch. In größeren Unternehmen entscheidet genau diese Erklärbarkeit darüber, ob Ihre App installiert wird oder in einer Prüfschleife hängen bleibt. Am vierten Tag schauen wir uns an, was passiert, wenn man an dieser Stelle großzügig war.

9:34 Der rote Faden ist hier eine Haltung: mit nichts anfangen und nur ergänzen, was sich beweisen lässt. Starten Sie mit einer leeren Liste. Ergänzen Sie einen Scope erst, wenn ein konkreter Aufruf daran scheitert. Und schreiben Sie in derselben Minute den Grund dazu — in einem halben Jahr weiß es niemand mehr, und dann bleibt der Scope einfach stehen.

9:54 Schritt vier erinnert an das, was wir vorhin gelernt haben: Eine Manifest-Änderung braucht auch die Installation. Und Schritt fünf ist der Termin vor dem Release, an dem Sie die Liste noch einmal gegen den Code halten. Der erste Punkt beschreibt den häufigsten Weg, auf dem Apps zu breite Rechte bekommen: Man setzt etwas zum Ausprobieren und nimmt es nie zurück, weil ja alles funktioniert.

10:16 Der zweite ist tückischer, weil er an einem Upgrade hängt — wenn Scopes hinzukommen, verlangt die Installation eine neue Zustimmung, und wer darauf nicht vorbereitet ist, hat plötzlich Administratoren am Telefon. Der dritte Punkt ist die Fernwirkung des fehlenden Kommentars: Niemand kann sagen, welcher Aufruf welchen Scope braucht, also traut sich niemand, einen zu entfernen.

Übung

10:37 Damit haben Sie alles zusammen, um Klarpfad zum ersten Mal wirklich laufen zu sehen — und um den Unterschied zwischen Ausrollen und Installieren am eigenen Bildschirm zu erleben. Die Übung ist bewusst schlicht: Klarpfad braucht in diesem Schritt nichts weiter als eine sichtbare Fläche am Jira-Vorgang. Keine Daten, keine Logik.

10:55 Erst danach kommt die erste Berechtigung dazu — und genau dieser zweite Teil ist der eigentliche Lerninhalt. Sie werden sehen, dass ein Ausrollen allein nicht reicht und die Instanz eine Rückfrage stellt. Diese Rückfrage ist kein Hindernis, sondern das Sicherheitsversprechen der Plattform in sichtbarer Form. Das Erfolgskriterium hat zwei Teile, und beide sind wichtig. Erstens: Das Panel erscheint an einem Vorgang — das ist der sichtbare Teil.

11:22 Zweitens: Nach dem Ergänzen eines Scopes ist die Zustimmung bei der Installation belegt. Halten Sie diese Rückfrage fest, machen Sie ruhig ein Bildschirmfoto. Sie werden am vierten und fünften Tag mehrfach darauf zurückkommen, wenn wir über Sicherheit und über Upgrades in produktiven Umgebungen sprechen. Wer früh fertig ist, setzt die Speicherangabe und prüft im Protokoll, ob sie greift.

11:46 Fünf Schritte, und der Ablauf spiegelt genau den Lebenszyklus, über den wir gesprochen haben: erzeugen, anpassen, ausrollen, installieren, ändern und erneut installieren. Der vierte Schritt ist der, um den es eigentlich geht — dort ergänzen Sie den Scope und erleben, was eine Manifest-Änderung auslöst. Nehmen Sie sich für den fünften Schritt wirklich Zeit: Die Rückfrage der Instanz kurz zu lesen und einzuordnen, ist mehr wert als eine weitere Funktion in der Oberfläche.

12:13 Sie werden diese drei Punkte während der Übung mindestens einmal selbst erleben — das ist nicht schlimm, sondern der Zweck. Nach der Manifest-Änderung wird nur ausgerollt, und nichts passiert. Der Modulschlüssel wird geändert, die Ressource nicht nachgezogen, und die App verschwindet. Und die Installation landet auf einer Instanz, auf der andere arbeiten. Merken Sie sich die Symptome: Sie sind die Abkürzung zur Diagnose an allen folgenden Tagen.

12:39 Im nächsten Modul geht es dann um das, was die meisten am liebsten zuerst machen würden — die Oberfläche.