Prüfen, veröffentlichen und zurücksetzen
Von einer geprüften Änderung zur Vorschau und zum laufenden Betrieb.
Voraussetzung: Sie kennen Commit, Branch und den Unterschied zwischen Code und Daten.
Danach können Sie
Sie können die nächsten Schritte zwischen einem KI-Vorschlag und der benutzten Anwendung benennen. Für Ihr Projekt wissen Sie, wo geprüft wird, wie eine Veröffentlichung ausgelöst wird und was bei einem Problem zurückgenommen werden kann.
Vier verschiedene Stände
| Stand | Wozu er dient | Was er noch nicht beweist |
|---|---|---|
| Lokale Änderung | Auf Ihrem Computer bearbeiten | Dass Kollegen oder die benutzte App diese Änderung bereits haben |
| Gespeicherter Git-Stand | Änderung nachvollziehen und austauschen | Dass die Anwendung fachlich richtig funktioniert |
| Getestete Vorschau | Verhalten mit geeigneten Konten und Daten prüfen | Dass produktive Daten und Dienste gleich konfiguriert sind |
| Veröffentlichte Anwendung | Den freigegebenen Stand tatsächlich benutzen | Dass alle Fehler und zukünftigen Änderungen ausgeschlossen sind |
Ein Push kann in einem eingerichteten Projekt Automatisierungen anstossen. Erklären Sie deshalb zuerst den tatsächlichen Ablauf anhand der Projektdateien und des Hosting-Kontos. Der Unterschied zwischen diesen Ständen gilt auch, wenn Ihr Anbieter mehrere Schritte automatisch verbindet.
Einen konkreten Prüffall formulieren
Für einen Statusfilter ist «die Seite öffnet sich» zu wenig. Ein sinnvoller fachlicher Test lautet beispielsweise: «Bei drei Musteraufträgen, davon zwei offen und einer erledigt, zeigt der Filter Offen genau die zwei offenen Aufträge. Nach Zurücksetzen sind wieder alle drei sichtbar.»
Prüfen Sie ausserdem bestehendes Verhalten und verbotene Aktionen: Kann ein Techniker weiterhin nur seine eigenen Aufträge sehen? Ist eine leere Ergebnisliste verständlich? Funktioniert die Bedienung auf einem schmalen Bildschirm?
Automatisierte Tests machen passende Regeln wiederholbar. Sie müssen aber zu den tatsächlich wichtigen Anforderungen passen. Das Entfernen eines fehlgeschlagenen Tests, nur damit wieder alles grün erscheint, klärt die Ursache nicht.
Die Befehle Ihres Projekts finden
Die README oder das Projektblatt sollte nennen: benötigte Softwareversionen, Installation, lokaler Start, Prüfungen und Build. Ein Build erstellt die zur Ausführung oder Auslieferung vorgesehenen Dateien. Er kann erfolgreich sein, obwohl ein fachlicher Ablauf falsch ist.
Lassen Sie die KI zunächst die vorhandenen Befehle aus der tatsächlichen Konfiguration erklären. Führen Sie nicht beliebige Standardbefehle aus einer anderen Anwendung aus. Wenn ein neues Projekt noch keinen Test- oder Startbefehl besitzt, muss dieser eingerichtet werden; er ist dadurch noch nicht automatisch vorhanden.
Die Vorschau prüfen und veröffentlichen
- Lesen Sie den Diff und führen Sie die vorgesehenen automatisierten Prüfungen aus.
- Prüfen Sie den fachlichen Ablauf mit den vereinbarten Testdaten und Konten.
- Halten Sie fest, welcher Commit geprüft wurde und welche offenen Punkte bestehen.
- Prüfen Sie, dass die Vorschau die vorgesehenen Testdienste verwendet. Ein eigener Branch allein trennt keine Datenbank und keine Zugangsdaten.
- Veröffentlichen Sie über den tatsächlich eingerichteten Projektweg. Kontrollieren Sie danach Adresse, dargestellten Stand und einen passenden Funktionstest.
Bei gemeinsamer Arbeit unterstützen Branches und Pull Requests eine nachvollziehbare Prüfung. Eine Zusammenführung ersetzt die Projektprüfungen nicht. GitHub flow.
Vorher wissen, wie Sie zurückkommen
Für eine reine Anzeigeänderung kann ein neuer korrigierender Commit oder die Rückkehr zu einer geprüften Veröffentlichung ausreichen. Eine Änderung am Datenbankschema, an Aufträgen oder an einem externen Dienst kann zusätzliche Folgen haben. Alter Code passt nicht zwingend zu einer bereits veränderten Datenstruktur.
Schreiben Sie deshalb vor einer solchen Änderung auf: letzter geprüfter Code-Stand, betroffene Datenänderungen, Rücknahmeweg, Sicherungs-/Wiederherstellungsweg und zuständige Person. Ob eine Datenwiederherstellung möglich ist, muss an der tatsächlichen Sicherung geprüft werden. Siehe Daten und Sicherungen.
Erfolgskontrolle
Sie können erklären, welche Prüfungen für genau diese Änderung bestanden wurden, welcher Stand veröffentlicht ist und wie Sie ein Problem behandeln würden. Für die Auftrags-App könnte der Nachweis aus dem Commit, den Ergebnissen der Filter-/Zugriffstests und einer dokumentierten Vorschau bestehen. Das Vorgehen wird im Projektwissen festgehalten.