Bereich Team

Der Ort, aus dem das Team seine Umgebung bezieht. Statt eine Datei per Chat herumzureichen — was ein Szenario teilen tut — liegt das Szenario in einem Katalog und jede Person übernimmt es, wenn sie es braucht.

Der Bereich erscheint nur, wenn ein Katalog konfiguriert ist. Wenn du „Team” nicht in der Seitenleiste siehst, fehlt deiner Installation nichts: Dieses Projekt hat keinen Katalog, und konfiguriert wird er in aseptic.project.yml.

Was zu sehen ist

Die Liste dessen, was das Team teilt. Wählt man einen Eintrag aus, beantwortet die Detailansicht die beiden Fragen, die man sich vor jeder Übernahme stellt:

• Was es mitbringt — wie viele Services, wie viele Mocks und wie viele Start-Einstellungen. Bringt es nur die Szenario-Definition mit, steht auch das dort.
• Was hier fehlt — was dieses Szenario braucht und deine Maschine noch nicht hat: eine Datenbankverbindung, auf die das Paket verweist, eine Zugangsdatei ohne Wert, ein Repository, das nicht in deinem Arbeitsbereich liegt, oder ein Micro, der auf einem anderen Branch registriert ist.

Diese zweite Liste ist der Grund, warum die Detailansicht existiert. Blind zu übernehmen und die Lücke erst zu bemerken, wenn das Szenario nicht startet, ist genau die Zeit, die das hier spart.

Übernehmen

Übernehmen holt das Szenario herein und gleicht es mit deinem Katalog ab, ohne ihn zu überschreiben: Es ist derselbe Weg wie der Import einer Datei, mit denselben Konfliktregeln.

Fehlt etwas, sagt es die Detailansicht samt Abhilfe daneben: welche Zugangsdaten zu hinterlegen sind, welches Repository noch fehlt, auf welchem Branch jeder Dienst registriert wurde. Und wenn du es lieber später klärst, kannst du trotzdem übernehmen: Das Szenario landet in deinem Katalog und startet erst, wenn die Lücke geschlossen ist — besser, als es gar nicht holen zu können.

Wenn das Team es ändert

Die Übernahme hinterlässt einen Faden: Das Szenario wird mit dem Eintrag vermerkt, aus dem es stammt, und mit der genauen Fassung, die geholt wurde. Das erlaubt der App später eine Aussage, die vorher nicht möglich war: das ist nicht mehr das, was das Team teilt.

In der Liste trägt jeder Eintrag seinen Zustand:

• Aktuell — was hier liegt, entspricht dem, was das Team veröffentlicht.
• Geändert — jemand hat es nach der Übernahme erneut veröffentlicht.
• (ohne Markierung) — es wurde noch nicht auf diese Maschine geholt.

Unmarkierte Einträge sind in einem großen Katalog die Mehrheit, und genau deshalb tragen sie keine Markierung: wäre alles markiert, ginge die eine Markierung, die etwas verlangt, zwischen den übrigen unter.

Beim Öffnen eines bereits übernommenen Eintrags ergänzt die Detailansicht Was sich ändert: welche Dienste sich von den hiesigen unterscheiden und in welchen konkreten Feldern. Und die Schaltfläche wechselt von Übernehmen zu Aktualisieren, denn genau das tut sie: sie überschreibt das vorhandene Szenario, statt eine Kopie daneben zu legen. Dreimal übernehmen ergibt nicht mehr „Zahlungen QA“, „Zahlungen QA (2)“ und „Zahlungen QA (3)“.

Verglichen wird der Inhalt, also zählt das erneute Veröffentlichen desselben nicht als Änderung. Ein Hinweis, der auslöst, ohne dass jemand etwas angefasst hat, wird bald nicht mehr gelesen — und mit ihm der, auf den es ankommt.

Wenn jemand einen Eintrag aus dem Katalog entfernt, funktioniert das daraus entstandene Szenario hier weiter — aber der Bereich sagt es oben, statt es still verschwinden zu lassen: dahinter steht niemand mehr, der es aktualisieren wird.

Veröffentlichen

Ein Szenario veröffentlichen… stellt es dem ganzen Team zur Verfügung, mit einer Zeile dazu, wofür es gut ist. Der Weg dorthin führt über die Kopfzeile des Bereichs oder über das Szenario selbst, mit Mit dem Team teilen… in seinem Menü. Diese Zeile ist das, was andere in der Liste sehen — sie zu schreiben lohnt sich.

Deine lokale Startschicht reist nicht mit. Die Flags und Variablen, mit denen du einen Micro hochfährst, gehören zu deiner Maschine und müssen auf einer anderen nicht gelten; veröffentlicht werden das Szenario, seine Manifeste und seine Mocks.

Zurückziehen entfernt einen Eintrag aus dem Katalog des gesamten Teams, nicht nur aus deinem. Deshalb wird nachgefragt: Du löschst nichts, was nur dir gehört.

Der Team-Schlüssel

Ist der Katalog gehostet, wird er Ende-zu-Ende verschlüsselt: Was der Server speichert, sind Blöcke, die der Server nicht öffnen kann. Der Schlüssel gehört dem Team und verlässt dessen Maschinen nie.

Er wird einmal erzeugt — Neuen Schlüssel erzeugen — und auf den übrigen Maschinen eingefügt — Team-Schlüssel eingeben. Die App verlangt beim Speichern eine Wiederholung; so prüft sie, dass du ihn wirklich irgendwo hin kopiert hast, bevor es weitergeht.

Es lohnt sich, den Hinweis neben der Schaltfläche zu lesen und ihm zu glauben: Verliert das Team den Schlüssel, ist der Katalog nicht wiederherstellbar. Kein Zurücksetzen hilft, weil niemand sonst ihn hat. Sein Platz ist dort, wo das Team seine übrigen Geheimnisse aufbewahrt.

Ein über Git bereitgestellter Katalog braucht keinen Schlüssel: Dort ist die Zugriffskontrolle die des Repositories selbst.

Dasselbe aus dem Terminal

All das gibt es auch im CLI — damit lässt sich die Umgebung in einem Continuous-Integration-Job aufbauen oder auf der Maschine von jemandem, der gerade angefangen hat:

aseptic team list                     # was das Team teilt
aseptic team status                   # noch das, was das Team teilt?
aseptic team adopt pagos-qa --apply   # holen und hier übernehmen
aseptic start "Pagos QA"

Ohne --apply zeigt adopt nur den Plan und was auf dieser Maschine fehlt — dieselbe Liste wie in der Detailansicht. Vollständig in CLI-Befehle.

Was das nicht ist

Es ist kein Ort für den Code deiner Micros: Repos bleiben Repos. Geteilt wird, wie sie zusammenspielen — welche Micros, in welchem Modus, mit welchen Mocks und welchen aufgelösten Abhängigkeiten. Also genau das, was in keine README passt und am Ende mündlich weitergegeben wird.