Wenn ein Build endet
Nach einer sauberen Übergabe kann dein Team die Software über eigene Konten betreiben, ändern und wiederherstellen. Lass dir Code und Historie, Dokumentation, Tests, eine funktionierende Deployment-Pipeline und Zugriff auf die benötigten Systeme geben. Das übernehmende Team sollte die Software vor der Abnahme selbst deployen und wiederherstellen.
Dreißig-Minuten-Call buchenKurze Antwort
Prüfe die Übergabe, indem dein Team die Software mit dem übergebenen Code, den Runbooks und den eigenen Konten baut, deployt und wiederherstellt.
Passt für
Passt nicht für
Wie man eine saubere Übergabe von einer Lock-in-Falle unterscheidet.
Repos in deiner Organisation, mit voller Git-Historie.
Code liegt im Konto des Anbieters, oder ein Zip ohne Historie.
Die Konten liegen beim Kunden, Dienstzugänge wurden neu ausgestellt oder rotiert.
Keys und Logins bleiben beim Anbieter.
Deine Organisation kontrolliert die benötigten Hosting-, DNS- und Monitoring-Konten. Die Betriebsrollen sind zugewiesen.
Der Anbieter ist der einzige Admin in der Produktion.
Architektur, Setup und Runbooks sind aufgeschrieben.
Wissen steckt im Kopf des ursprünglichen Entwicklers.
Automatisierte Tests und eine Pipeline, die du selbst betreibst.
Keine Tests, oder Deploys, die nur der Anbieter auslösen kann.
Jedes kompetente Team kann übernehmen.
Nur der ursprüngliche Erbauer kann etwas ändern.
Das übernehmende Team sollte die Software ohne die ursprünglichen Entwickler deployen und wiederherstellen können.
Wir liefern Code und Historie in deinen Repositories, dazu Dokumentation, Runbooks, Tests und eine Deployment-Pipeline. Vereinbare, wer die Produktionskonten kontrolliert und wie das übernehmende Team deployt, wiederherstellt und den Anbieter wechselt. Bei einem verwalteten Dienst reicht der Zugriff gegebenenfalls nur bis zur Ebene des eigenen Mandanten. Dokumentiere die Grenzen, den Datenexport und wer Änderungen freigibt.
Eine Person, die das System nicht gebaut hat, beginnt mit einem frischen Checkout in der Organisation des Kunden. Lass sie nach dem Runbook bauen, testen und in eine sichere Umgebung deployen. Prüft, ob ein Alarm den neuen Bereitschaftsdienst erreicht. Spielt ein Backup in eine isolierte Umgebung ein und prüft repräsentative Datensätze und einen wichtigen Nutzerablauf. Messt die Wiederherstellungszeit und den möglichen Datenverlust. Vergleicht beides mit den vereinbarten Zielen. AWS Well-Architected zu Wiederherstellungstests.
Bei der Repository-Übertragung können Einstellungen mitwandern, die du noch prüfen musst. GitHub behält beispielsweise zugeordnete Webhooks, Secrets und Deploy-Schlüssel bei. Prüfe diese ebenso wie externe Runner, Paketregistries und Deployment-Identitäten. Stelle Zugangsdaten in den Konten des Kunden neu aus oder rotiere sie, teste sie und widerrufe ersetzte Zugänge. Halte fest, wer für Verlängerungen, Abrechnung, Lizenzen und externe Dienste zuständig ist. GitHub-Dokumentation zur Repository-Übertragung.
Mit der Abnahmecheckliste für Datenpipelines vereinbaren Sie Kennzahlen, Quellenabgleich, verspätete Daten, sichere Wiederholungen und Berichtsverantwortung.
Bestätige jeden dieser Punkte, bevor du die Übergabe akzeptierst.
Hak die Punkte ab, während du vorgehst. Nichts wird gespeichert oder gesendet.
Diese Fälle beschreiben Produkte, die in Produktion gingen. Prüfe deine eigene Übergabe anhand der Übung.
AR-RWA-Plattform: 2 Mio. $+ über das Produkt eingenommen, 1.000+ gleichzeitige Nutzer, sechs Wochen flat.
AI-native Assessment-Plattform, von 0 auf Produktion in 6 Wochen unter komprimiertem Marktdruck.
Das sind ausgewählte Projekte, nicht unser gesamtes Portfolio. Seit 2018 haben wir 100+ Produkte ausgeliefert.
Wenn du deine Software nicht ohne die Leute betreiben kannst, die sie gebaut haben, besitzt du sie noch nicht.