Bestehende Software an ein neues Team übergeben
Prüfen Sie die Übergabe vom eindeutigen Quellstand bis zur kleinen, rücknehmbaren Änderung in der Testumgebung.
Lassen Sie das neue Team den Weg selbst nachvollziehen
Eine Übergabe wird greifbar, wenn das neue Team die Anwendung mit eigenen berechtigten Konten aufsetzen und eine vereinbarte Änderung prüfen kann. Ein Quellcodearchiv und eine Vorführung durch das bisherige Team liefern dafür noch nicht alle Nachweise.
Ordnen Sie zuerst den laufenden Stand einem eindeutigen Quellstand zu. Halten Sie benötigte Dateien, Abhängigkeiten, Werkzeugversionen und den Weg zum ausführbaren Ergebnis fest. SLSA unterscheidet Quellen, weitere Eingaben, Build und ausgelieferte Artefakte. So kann das neue Team nachvollziehen, aus welchen Eingaben der übergebene Stand entstanden ist.
Beispiel: eine Textänderung vom Aufbau bis zum Rückweg
Das folgende Szenario ist erfunden. Ein Serviceformular wird im Stand v2.3.0 übergeben. Das neue Team soll den Hilfetext „Lieferhinweis“ zu „Zugang und Anlieferung“ präzisieren. Datenfelder und Datenbankschema bleiben in diesem Beispiel unverändert. Die Tabelle beschreibt erwartete Nachweise, keinen ausgeführten Test.
Schritt | Vereinbarte Aufgabe | Erwarteter Nachweis |
|---|---|---|
Quellen erreichen | Mit eigenem berechtigtem Konto den dokumentierten Quellstand und benötigte Zusatzdateien abrufen. | Der übergebene Stand ist eindeutig; auch benötigte private Pakete und zusätzliche Repository-Inhalte sind erreichbar. |
Umgebung aufsetzen | Anleitung für Laufzeit, Paketinstallation und Testkonfiguration verwenden. | Die Testanwendung startet ohne Produktionszugänge oder private Dateien des bisherigen Entwicklers. |
Kleine Änderung prüfen | Den Hilfetext ändern und den bestehenden Speichervorgang mit synthetischen Daten durchgehen. | Der neue Text erscheint; der vereinbarte Speichervorgang funktioniert weiterhin. |
Änderung zurücknehmen | Die Textänderung in der Testumgebung zurücknehmen und den dokumentierten Startweg verwenden. | Der ursprüngliche Text und der zuvor geprüfte Formularablauf sind wieder vorhanden. |
Die letzte Zeile belegt nur den Rückweg dieser Änderung. Wiederherstellung einer Datenbank oder ein Produktionswechsel benötigen eigene passende Prüfungen.
Ergänzen Sie den Betrieb und die offenen Punkte
Dokumentieren Sie Konfigurationsnamen, sichere Bezugswege für Geheimnisse, private Paketquellen und vorhandene Build-Konfiguration einschließlich einer passenden Lockdatei für Abhängigkeiten. Echte Geheimnisse gehören nicht ins Quellcodearchiv. Prüfen Sie auch zusätzlich gespeicherte große Dateien und eingebundene Repositories, falls das Projekt solche verwendet.
Klären Sie Zugänge und Zuständigkeiten für Bereitstellung, Überwachung, Sicherungen und Störungen. Bei einem GitHub-Repository-Transfer bleiben unter anderem Webhooks, Secrets und Deploy Keys zugeordnet. Prüfen Sie deshalb ausdrücklich, welche Anbindungen und Zugriffe künftig bestehen sollen. Eine Übertragung allein bereinigt sie nicht.
Wenn ein Schritt scheitert, halten Sie fehlende Voraussetzung, verantwortliche Rolle und nächsten Nachweis fest. Trennen Sie offene Punkte von erfolgreich gezeigten Ergebnissen. Vereinbaren Sie, ab wann das neue Team welche Aufgaben übernimmt und wer bis dahin ansprechbar bleibt.
Quellen
Geschrieben von
- Katharina WeberRedakteurin für Software und TechnologieKatharina Weber betreut bei ASES die Beiträge zur Softwareentwicklung. Sie schreibt über Fragen, die Unternehmen bei der Auswahl von Software, der Entwicklung neuer Anwendungen und der Modernisierung bestehender Systeme beschäftigen.
Weiterlesen
Alle Beiträge
Softwareentwicklung mit ASES
Individuelle Software, Web- und Mobile-Apps