Checkliste zur Quellcode-Übergabe für Kunden und Agenturen

Was eine Quellcode-Übergabe erreichen sollte

Eine Quellcode-Übergabe ist der Moment, in dem ein Projekt von „etwas, das die Agentur betreibt“ zu „etwas, das der Kunde besitzt“ wird. Ohne eine klare Übergabe tauchen typische Probleme schnell auf: Die App baut nur auf einem Laptop, die Produktion hängt von einem Secret ab, das niemand findet, oder ein kleiner Fix wird zur tagelangen Fehlersuche.

Das Ziel jeder Checkliste zur Quellcode-Übergabe ist einfach: Nach der Übergabe kann der Kunde das Produkt bauen, ausführen und deployen, ohne die Agentur ständig erreichen zu müssen. Das heißt nicht „nie wieder Support“. Es bedeutet, dass die Grundlagen wiederholbar und dokumentiert sind, sodass die nächste Person mit Vertrauen übernehmen kann.

Was als Liefergegenstände zählt, sollte explizit sein. Mindestens enthält eine vollständige Übergabe üblicherweise:

• Das vollständige Repository (inklusive Deployment-Dateien und Migrationsskripten)
• Setup-Dokumentation, die auf einer sauberen Maschine funktioniert
• Zugangsdaten-Übergabe (Konten, Berechtigungen und wo das System läuft)
• Ein Runbook für Routineaufgaben (Deploys, Rollbacks, Backups, Logs)
• Einen finalen „bekannt-guten“ Versions-Tag oder Snapshot, auf den sich der Kunde beziehen kann

Der Umfang ist genauso wichtig wie der Inhalt. Manche Übergaben umfassen nur eine Umgebung (z. B. Produktion). Andere beinhalten Dev, Staging und Produktion mit getrennten Einstellungen und Prozessen. Wenn nicht klar benannt wird, welche Umgebungen enthalten sind, interpretieren verschiedene Leute das unterschiedlich — und daraus entstehen Ausfälle.

Eine praktische Definition von Erfolg ist ein Verifikationstest: Eine Person, die die App nicht gebaut hat, kann den Code exportieren (z. B. von einer Plattform wie Koder.ai), den Anweisungen folgen, Umgebungsvariablen setzen, Migrationen ausführen, bauen und in die vereinbarte Umgebung deployen.

Diese Checkliste konzentriert sich auf technische Bereitschaft: Umgebungsvariablen, Secrets-Rotation, Datenbank-Migrationen, Deployment-Skripte und Build-Verifikation. Sie behandelt keine rechtlichen Aspekte, Verträge, IP-Klauseln oder Zahlungsstreitigkeiten. Das ist wichtig, gehört aber in eine separate Vereinbarung.

Bevor Sie exportieren: Eigentum und Zeitplan klären

Eine saubere Übergabe beginnt, bevor ein Export stattfindet. Wenn Sie vereinbaren, wer was wann besitzt, vermeiden Sie Überraschungen wie gebrochene Deployments, unbezahltes Hosting oder fehlende Zugänge.

Legen Sie das Übergabedatum und ein kurzes Freeze-Fenster fest

Wählen Sie ein Übergabedatum und definieren Sie ein Freeze-Fenster (oft 24–72 Stunden), in dem nur dringende Fixes eingespielt werden. So bleiben der exportierte Code und das laufende System synchron. Wenn während des Freeze ein Hotfix nötig ist, dokumentieren Sie genau, was sich geändert hat, und stellen Sie sicher, dass es im finalen Export enthalten ist.

Klären Sie Eigentum an Konten und Abrechnung

Entscheiden Sie, wer DNS, Cloud-Hosting und bezahlte Dienste nach der Übergabe besitzt. Das ist nicht nur Formalität. Bleibt die Abrechnung auf der Karte der Agentur, können Dienste später ohne Vorwarnung pausiert werden.

Eine praktische Vorgehensweise:

• Nennen Sie den Kontoinhaber für DNS, Hosting und E-Mail
• Bestätigen Sie, wer ab dem Übergabedatum welche Rechnungen bezahlt
• Entscheiden Sie, ob Konten übertragen oder unter dem Kunden neu erstellt werden
• Notieren Sie den Support-Kontakt für jeden Provider

Schreiben Sie das in einfacher Sprache auf, damit beide Seiten es nachvollziehen können.

Listen Sie die Umgebungen und deren Lauforte auf

Vereinbaren Sie, welche Umgebungen es gibt (local, staging, production) und wo jede läuft. Notieren Sie, ob Staging ein separater Server, eine separate Datenbank oder nur ein Feature-Flag ist. Wenn Sie eine Plattform wie Koder.ai verwendet haben, bestätigen Sie, was dort gehostet ist und was nach dem Export in der Infrastruktur des Kunden laufen soll.

Sammeln Sie Zugänge frühzeitig

Warten Sie nicht bis zum letzten Tag, um Zugänge anzufordern. Stellen Sie sicher, dass die richtigen Personen Zugriff auf das Repo, CI, Hosting, die Datenbank und den E-Mail-Provider haben.

Vereinbaren Sie außerdem den finalen Abnahmetest und den Sign-off-Prozess. Zum Beispiel: „Der Kunde kann auf einer sauberen Maschine bauen, Migrationen ausführen, nach Staging deployen und den Smoke-Test bestehen. Danach signieren beide Seiten die Abnahme schriftlich."

Repo- und Dokumentations-Basics

Eine gute Checkliste für Quellcode-Übergabe beginnt mit einem Repository, das ein neues Team in Minuten öffnen und verstehen kann. Bestätigen Sie, was enthalten ist (App-Code, Config-Vorlagen, Skripte) und was bewusst fehlt (echte Secrets, private Keys, große generierte Dateien). Wenn etwas ausgeschlossen ist, sagen Sie, wo es liegt und wer dafür verantwortlich ist.

Halten Sie die Struktur vorhersehbar. Ziel sind klare Top-Level-Ordner wie frontend/, backend/, mobile/, infra/, scripts/ und docs/. Ist das Projekt ein Monorepo, erklären Sie, wie die Teile zusammenhängen und wie man jedes einzelne startet.

Das README sollte für jemanden nutzbar sein, der das Projekt nicht gebaut hat. Es sollte Voraussetzungen und den schnellsten Weg zu einer funktionierenden Entwicklungsumgebung beschreiben — ohne Rätselraten.

Was mindestens dokumentiert werden sollte

Fügen Sie einen kurzen, menschlichen README-Abschnitt hinzu, der beantwortet:

• Was dieses Repo enthält und was es tut (ein Absatz)
• Voraussetzungen mit genauen Versionen (Runtime, Paketmanager, Docker falls nötig)
• Ein-Kommando-Startschritte für lokale Entwicklung (und was „erfolgreich“ bedeutet)
• Wie man Tests ausführt und ein Produktions-Artefakt baut
• Wo wichtige Dokumente zu finden sind: Architektur-Notizen, Migrationen, Deployment-Hinweise

Fügen Sie einfache Architektur-Notizen in verständlicher Sprache hinzu: wer spricht mit wem und warum. Ein kleines Diagramm ist optional; ein paar Sätze genügen meist. Beispiel: „React-Frontend ruft die Go-API auf. Die API liest und schreibt in PostgreSQL. Hintergrundjobs laufen als separater Worker-Prozess.“

Schließlich fügen Sie einen versionierten Changelog oder Release-Notes für den Handoff-Build bei. Das kann eine CHANGELOG.md oder eine kurze „Handoff Release Notes“-Datei sein, die das genaue Commit/Tag, den Auslieferungsinhalt und bekannte Probleme aufführt.

Wenn der Code aus einer Plattform wie Koder.ai exportiert wurde, notieren Sie den generierten Projekttyp (Web, Server, Mobile), die erwartete Toolchain (z. B. React, Go, PostgreSQL, Flutter) und die unterstützten OS/Tooling-Versionen, die der Kunde verwenden sollte, um den Build zu reproduzieren.

Umgebungsvariablen: Inventar und Dokumentation

Umgebungsvariablen sind oft der Grund, warum eine „funktionierende App“ nach der Übergabe fehlschlägt. Eine gute Checkliste behandelt sie als Produktbestandteil, nicht als Nachgedanken.

Beginnen Sie mit einem Inventar, dem ein neues Team ohne Raten folgen kann. Halten Sie es in klarer Sprache und fügen Sie ein Beispiel für das Werteformat hinzu (keine echten Secrets). Wenn eine Variable optional ist, beschreiben Sie, was passiert, wenn sie fehlt, und welcher Default verwendet wird.

Eine einfache Präsentation des Inventars ist:

• Variablenname, was er steuert, und ein Beispiel-Format
• Erforderlich vs. optional sowie das Standardverhalten
• Wo sie gesetzt wird (CI, Hosting-Dashboard, lokale .env-Datei)
• Welche Umgebungen unterschiedliche Werte benötigen (dev, staging, production)
• Wer für Änderungen verantwortlich ist (Kunde, Agentur oder geteilt)

Heben Sie umgebungsspezifische Unterschiede klar hervor. Zum Beispiel zeigt Staging auf eine Testdatenbank und einen Sandbox-Zahlungsanbieter, während Produktion Live-Services nutzt. Notieren Sie auch Werte, die in mehreren Systemen übereinstimmen müssen, wie Callback-URLs, erlaubte Origins oder Bundle-IDs mobiler Apps.

Dokumentieren Sie, wo jeder Wert aktuell liegt. Viele Teams verteilen Werte über mehrere Orte: lokale .env-Dateien für Entwicklung, CI-Variablen für Builds und Hosting-Einstellungen zur Laufzeit. Wenn Sie Koder.ai zum Export genutzt haben, legen Sie eine .env.example-Datei bei und vermerken Sie, welche Variablen vor dem ersten Build ausgefüllt werden müssen.

Prüfen Sie abschließend, dass keine Secrets im Repo versteckt sind. Untersuchen Sie nicht nur die aktuellen Dateien, sondern auch die Commit-Historie auf versehentlich veröffentlichte Keys, alte .env-Dateien oder kopierte Zugangsdaten in Beispielkonfigurationen.

Konkretes Beispiel: Ein React-Frontend plus Go-API könnte API_BASE_URL für das Web enthalten und DATABASE_URL sowie JWT_SIGNING_KEY für das Backend. Wenn Staging eine andere Domain nutzt, schreiben Sie beide Werte auf und erklären, wo sie geändert werden, damit das Team nicht versehentlich Staging-Einstellungen in Produktion pustet.

Secrets Rotation: Sicher übertragen und verifizieren

Eine Übergabe ist erst dann abgeschlossen, wenn der Kunde alle Zugangsdaten kontrolliert, die die App benötigt. Das heißt: Secrets rotieren, nicht nur teilen. Wenn eine Agentur (oder ein ehemaliger Auftragnehmer) noch funktionierende Keys hat, besteht eine nicht auditierbare Hintertür.

Beginnen Sie mit einem vollständigen Inventar. Hören Sie nicht bei Datenbank-Passwörtern auf. Beziehen Sie Drittanbieter-API-Keys, OAuth-Client-Secrets, Webhook-Signing-Secrets, JWT-Signatur-Keys, SMTP-Zugangsdaten, Storage-Access-Keys und temporäre Tokens aus CI mit ein.

Ein einfacher Ablauf für den Rotationstag:

• Listen Sie jedes Secret auf, was es freischaltet und wo es derzeit gesetzt ist (lokale Env-Dateien, CI, Hosting-Dashboard, Vault)
• Erstellen Sie neue Zugangsdaten unter den Accounts des Kunden und legen Sie für jedes einen Owner fest (eine Person und ein Team-Inbox)
• Aktualisieren Sie die App-Konfiguration mit den neuen Werten und deployen Sie zuerst in eine Staging- oder Testumgebung
• Widerrufen Sie die alten Zugangsdaten sofort, nachdem die neuen bestätigt funktionieren
• Dokumentieren Sie die genauen Rotationsschritte, damit die nächste Rotation schnell und langweilig ist

Nach der Rotation beweisen Sie, dass nichts kaputtgegangen ist. Führen Sie kurze „echte Benutzer“-Tests aus, statt nur Logs zu prüfen.

Konzentrieren Sie sich auf Flows, die von Secrets abhängen:

• Login, Registrierung, Passwort-Reset und Token-Refresh
• Zahlungen, E-Mail-Versand und Dateiuploads
• Webhooks (Signatur-Prüfung und Retry-Handling)
• Hintergrundjobs oder geplante Tasks, die externe APIs aufrufen
• Admin-Aktionen mit privilegierten Endpunkten

Beispiel: Wurde ein Projekt aus Koder.ai exportiert und die App nutzt einen Zahlungsanbieter sowie E-Mail-Delivery, rotieren Sie beide Keys, redeployen, führen eine Testtransaktion aus und senden eine Test-E-Mail. Erst wenn das funktioniert, widerrufen Sie agentur-eigene Keys.

Dokumentieren Sie abschließend, wo Secrets künftig leben (Vault, CI-Variablen oder Hosting-Einstellungen), wer sie ändern darf und wie ein Rollback erfolgen kann, falls eine Rotation Fehler verursacht.

Datenbank-Migrationen und Datenhandling

Eine Übergabe wirkt abgeschlossen, während die Datenbank oft als erstes versagt. Behandeln Sie Migrationen und Daten wie ein eigenständiges Produkt: versioniert, wiederholbar und getestet.

Beginnen Sie damit, die aktuelle Datenbank-Version und den Speicherort der Migrationen im Repo aufzuschreiben. Seien Sie konkret: Ordnerpfad, Namensmuster und die ID der neuesten Migration (oder Timestamp). Wenn Sie PostgreSQL verwenden (häufig bei Go-Backends), notieren Sie auch erforderliche Extensions.

Was dokumentiert werden sollte (damit andere es ausführen können)

Fügen Sie ein kurzes Runbook hinzu, das diese Fragen beantwortet:

• Welcher Befehl führt Migrationen aus und in welcher Reihenfolge (Datenbank anlegen, Migrationen anwenden, dann Seeds)
• Wie unterscheidet sich das je nach Umgebung (local, staging, production), inklusive "Safe Mode"-Flags
• Ob Migrationen automatisch beim Deploy laufen oder manuell angestoßen werden müssen und wer dazu berechtigt ist
• Seed-Daten-Strategie: keine, nur Demo oder minimale Pflichtdatensätze (Admin, Default-Settings)
• Rollback-Plan: was rückgängig gemacht werden kann und was nicht (z. B. destruktive Spaltenlöschungen)

Rollbacks sollten ehrlich dokumentiert werden. Manche Änderungen sind nur mit Backup-Restore umkehrbar. Weisen Sie darauf hin und koppeln Sie es an einen Backup-Schritt (Snapshot vor Deploy, Restore-Prozess verifizieren).

Vor Abschluss der Übergabe führen Sie Migrationen idealerweise auf einer Kopie der Produktionsdaten aus. Das deckt langsame Queries, fehlende Indexe und Probleme auf, die nur bei realen Daten auftreten. Ein realistischer Test ist: Code exportieren, Umgebungsvariablen setzen, eine anonymisierte Dump wiederherstellen und dann Migrationen von Grund auf anwenden.

Wurde die App in einer Plattform wie Koder.ai gebaut und dann exportiert, prüfen Sie, ob Migrationsdateien und Seed-Skripte im Export enthalten sind und vom Backend-Startprozess korrekt referenziert werden.

Build und CI: Wiederholbarkeit sicherstellen

Eine Übergabe ist nur dann abgeschlossen, wenn jemand anderes die App auf einer sauberen Maschine von Grund auf neu bauen kann. Ihre Checkliste sollte die exakten Build-Kommandos, erforderlichen Versionen und das erwartete Ergebnis nennen (z. B. „Web-Bundle in /dist“, „API-Binary-Name“, „Flutter APK-Pfad").

Schreiben Sie die Tools und Paketmanager auf, die tatsächlich verwendet werden, nicht nur die vermuteten. Für einen typischen Stack kann das Node.js (npm oder pnpm) für React, das Go-Toolchain für den Server, PostgreSQL-Client-Tools für das lokale Setup und das Flutter-SDK für Mobile sein.

Machen Sie die Installation der Abhängigkeiten vorhersagbar. Bestätigen Sie, dass Lockfiles committed sind (package-lock.json, pnpm-lock.yaml, go.sum, pubspec.lock) und führen Sie eine frische Installation auf einem neuen Rechner oder in einem sauberen Container durch, um es zu beweisen.

Dokumentieren Sie Schritt für Schritt, was CI macht, damit es auf einen anderen CI-Provider kopiert werden kann:

• Abhängigkeiten installieren (mit Lockfiles)
• Tests und Lint-Checks ausführen
• Build-Artefakte erzeugen (Web-Bundle, Server-Binary, Mobile-Build)
• Artefakte produzieren (zip, Docker-Image, Release-Bundle)
• Logs und Build-Metadaten speichern (Version, Commit, Datum)

Trennen Sie Build-Zeit-Konfiguration von Laufzeit-Konfiguration. Build-Zeit-Config beeinflusst, was kompiliert wird (z. B. eine in ein Web-Bundle eingebettete API-URL). Laufzeit-Config wird zur Startzeit injiziert (z. B. Datenbank-URLs, API-Keys, Feature-Flags). Gemischte Konfiguration ist ein häufiger Grund für „es funktioniert in CI“ aber nicht nach dem Deploy.

Geben Sie ein einfaches lokales Verifikationsrezept. Schon eine kurze Befehlsliste reicht:

# Web
pnpm install
pnpm test
pnpm build

# API
go test ./...
go build ./cmd/server

# Mobile
flutter pub get
flutter test
flutter build apk

Wenn Sie aus einer Plattform wie Koder.ai exportieren, legen Sie generierte CI-Dateien oder Build-Presets bei, die beim Deploy verwendet wurden, damit der Kunde den gleichen Build außerhalb der Plattform reproduzieren kann.

Deployment-Skripte und Release-Prozess

Eine gute Checkliste endet nicht bei „hier ist das Repo“. Sie erklärt auch, wie der Code zum laufenden Dienst wird und wer den Knopf drückt.

Beginnen Sie damit, zu dokumentieren, wie Deploys aktuell erfolgen: vollständig manuell (Befehle auf einem Server ausführen), CI-gesteuert (Pipeline baut und deployt) oder über eine gehostete Plattform. Geben Sie an, wo Konfigurationen liegen und welche Umgebungen existieren (dev, staging, production).

Machen Sie die Release-Schritte wiederholbar. Hängt der Prozess davon ab, dass sich jemand 12 Befehle merkt, schreiben Sie Skripte und vermerken Sie die benötigten Berechtigungen.

Was zum Deployment-Paket gehört

Geben Sie dem Kunden genug, um am ersten Tag zu deployen:

• Build- und Run-Kommandos (inklusive exakter Versionen von Node, Go, Flutter etc.)
• Deployment-Skripte (Shell-Skripte, Makefile-Targets oder Pipeline-Konfigurationen)
• Erforderliche Zugänge: Cloud-Rollen, Container-Registry, DNS, Datenbank-Admin
• Hinweise zur Umgebungs-Konfiguration: wo Env-Variablen gesetzt sind und wie sie je Umgebung variieren
• Release-Namenskonvention: Tags/Releases und wie man identifiziert, was läuft

Vereinbaren Sie Downtime-Erwartungen. Ist „zero downtime“ erforderlich, beschreiben Sie das praktisch (Blue-Green, Rolling Deploy, Read-Only-Fenster für Migrationen). Ist Downtime akzeptabel, definieren Sie ein klares Zeitfenster.

Statische Assets und Caches sind häufige Fehlerquellen. Notieren Sie, wie Assets gebaut und serviert werden, wann Caches invalidiert werden müssen und ob ein CDN im Spiel ist.

Ausführbares Rollback

Ein Rollback sollte ein kurzes, getestetes Rezept sein, das an ein Tag oder Release-ID gebunden ist. Beispiel: den vorherigen Tag deployen, falls nötig einen Datenbank-Snapshot zurückspielen und Caches invalidieren.

Wurde die App in Koder.ai erstellt und dann exportiert, erwähnen Sie den zuletzt bekannten guten Snapshot und die exakte Export-Version, damit der Kunde Code schnell mit einem funktionierenden Release abgleichen kann.

Schritt-für-Schritt: Verifiziere den Build nach dem Export

Verifikation ist der Moment, in dem sich zeigt, ob die Übergabe echt ist. Das Ziel ist einfach: Eine neue Person nimmt den exportierten Code, richtet ihn ein und bringt die gleiche App ohne Rätselraten zum Laufen.

Bevor Sie beginnen, halten Sie fest, wie „korrekt“ aussieht: die laufende App-Version, das aktuelle Commit/Tag (falls vorhanden) und ein oder zwei zentrale Screens oder API-Antworten zum Vergleich. Kam der Export von einer Plattform wie Koder.ai, notieren Sie Snapshot oder Export-Zeitstempel, damit Sie nachweisen können, dass Sie den neuesten Zustand getestet haben.

1. Bestätigen Sie, dass der Export der Produktion entspricht: Prüfen Sie die Commit-Historie, Release-Notes oder Build-Metadaten. Vergleichen Sie eine sichtbare Versionsanzeige oder ein kleines Verhalten (z. B. ein bestimmtes Setting oder UI-Label) mit der laufenden App.
2. Umgebungsvariablen und Secrets einrichten: Erstellen Sie die Ziel-Umgebungskonfiguration (lokal und staging). Nutzen Sie das bereitgestellte Env-Var-Inventar und prüfen Sie, dass nichts im Repo hartkodiert ist.
3. Abhängigkeiten installieren und Tests ausführen: Führen Sie eine saubere Installation durch (keine gecachten node_modules/vendor-Ordner). Führen Sie Unit-Tests und Lint-Checks genau wie dokumentiert aus.
4. Migrationen ausführen und lokal starten: Starten Sie die Datenbank, wenden Sie Migrationen in der richtigen Reihenfolge an und starten Sie die App. Bestätigen Sie, dass die App einfache Lese-/Schreibvorgänge ausführen kann und keine Migrationen ausstehen.
5. Deploy in Staging, Smoke-Test, dann Promotion: Deployen Sie mit denselben Skripten/Pipelines, die Sie in Produktion verwenden wollen. Erst promoten, wenn Staging den Erwartungen entspricht.

Für Smoke-Tests halten Sie es kurz und risikoorientiert:

• Ein-/Ausloggen (oder Erstellung eines Testnutzers)
• Ein zentraler Workflow Ende-zu-Ende (Erstellen–Bearbeiten–Speichern)
• Eine E-Mail/Webhook/Payment-Callback falls relevant
• Grundlegendes Fehlerhandling (falsche Eingaben, fehlender Datensatz)
• Logs zeigen keine wiederholten Abstürze oder Secret-bezogene Fehler

Wenn etwas fehlschlägt, dokumentieren Sie den genauen Befehl, die Fehlerausgabe und die verwendeten Umgebungsvariablen. Diese Details sparen Stunden beim Zuständigkeitswechsel.

Häufige Fehler bei Übergaben und wie man sie vermeidet

Der schnellste Weg, eine Übergabe in einen Feuerwehreinsatz zu verwandeln, ist anzunehmen: „Der Code reicht.“ Eine gute Checkliste konzentriert sich auf die kleinen, langweiligen Details, die darüber entscheiden, ob der Kunde die App wirklich betreiben und ändern kann.

Fehler, die die meisten Probleme verursachen

Die meisten Probleme folgen wenigen Mustern:

• Secrets werden nicht rotiert, sodass alte Agentur-Passwörter, API-Keys oder Cloud-Tokens nach der Übergabe noch funktionieren.
• Umgebungsvariablen sind unvollständig, weil einige Werte nur in CI oder im Hosting-Dashboard liegen, nicht im Repo.
• One-off Änderungen in Produktion werden vergessen, z. B. ein Quick-Fix, eine manuelle DB-Änderung oder ein Config-Toggle direkt auf dem Server.
• Datenbank-Migrationen laufen lokal, schlagen aber in Produktion fehl wegen fehlender Berechtigungen, Extensions oder Schema-Ownership.
• Es gibt keinen Rollback-Plan und keinen getaggten Release (oder Release-Notes), zu dem man bei einem fehlgeschlagenen Deploy zurückkehren kann.

Wie man sie verhindert (ohne Wochen draufzupacken)

Machen Sie Rotation und Cleanup von Zugängen zu einem festen Termin, nicht zu einem „wenn wir Zeit haben“-Item. Legen Sie ein Datum fest, an dem Agentur-Konten entfernt, Service-Keys neu generiert und der Kunde bestätigt, dass er nur mit seinen eigenen Zugangsdaten deployen kann.

Für Env-Vars machen Sie ein Inventar aus drei Quellen: Repo, CI-System und Hosting-UI. Validieren Sie es durch einen sauberen Build auf einer frischen Maschine oder in einem Container.

Für Migrationen testen Sie mit der gleichen Datenbank-Rolle, die das Produktions-Deploy verwenden wird. Wenn Produktion erhöhte Schritte erfordert (z. B. Extensions aktivieren), schreiben Sie diese auf und klären Sie die Zuständigkeit.

Ein realistisches Beispiel: Nach dem Export eines Projekts aus Koder.ai deployt der Kunde erfolgreich, aber Hintergrundjobs scheitern, weil eine Queue-URL nur im Hosting-Dashboard gesetzt war. Ein einfacher Env-Var-Audit hätte das verhindert. Kombiniert mit einem getaggten Release und einem dokumentierten Rollback (z. B. „deploy tag v1.8.2 und restore letzten Snapshot“) vermeidet das Team Ausfallzeiten.

Abschließende Checkliste, ein einfaches Beispiel und nächste Schritte

Wenn Sie nur eine Seite aus dieser Quellcode-Übergabe-Checkliste behalten, dann diese. Das Ziel ist simpel: Ein sauberes Clone sollte auf einer neuen Maschine laufen, mit neuen Secrets und einer Datenbank, die sicher weitergeführt werden kann.

Schnelle Checks (von einem frischen Clone ausführen)

Führen Sie diese Prüfungen auf einem Laptop durch, der das Projekt nie gesehen hat (oder in einem sauberen Container/VM). So finden Sie fehlende Dateien, versteckte Annahmen und alte Zugangsdaten am schnellsten.

• Build von Grund auf: Abhängigkeiten installieren, Tests ausführen (falls vorhanden) und ein Release-Build ohne manuelle Änderungen erzeugen.
• Config funktioniert: Setzen Sie die dokumentierten Umgebungsvariablen und bestätigen Sie, dass die App mit frischer Konfiguration bootet.
• Secrets sind rotiert: Verifizieren Sie, dass die App mit den neuen Keys läuft, widerrufen Sie die alten Keys und prüfen Sie, dass nichts kaputtgeht.
• Migrationen laufen sauber: Starten Sie mit einer leeren DB, führen Sie Migrationen aus, starten Sie die App und prüfen einen einfachen Flow.
• Deployment-Pfad ist real: Führen Sie einmal das Deployment-Skript oder den CI-Workflow aus und bestätigen Sie, dass das gleiche Ergebnis entsteht.

Ein einfaches Handoff-Beispiel

Eine Agentur übergibt ein React-Frontend, eine Go-API und eine PostgreSQL-Datenbank. Das Kundenteam klont das Repo, kopiert die bereitgestellte .env.example in echte Umgebungsvariablen und erstellt neue Zugangsdaten für Datenbank, E-Mail-Provider und Drittanbieter-APIs. Sie führen go test (oder das vereinbarte Testkommando) aus, bauen die React-App, wenden Migrationen auf eine frische Postgres-Instanz an und starten beide Dienste. Schließlich deployen sie mit dem dokumentierten Skript und bestätigen, dass derselbe Commit später wiederaufgebaut werden kann.

Nächste Schritte

Halten Sie die Übergabe kurz und mit einem Owner. Ein 30–60-minütiger Walkthrough schlägt oft eine lange Dokumentation.

• Planen Sie eine Walkthrough-Session und dokumentieren Sie Entscheidungen (wer Deploys, Secrets und DB-Änderungen besitzt).
• Benennen Sie einen Owner für Production-Zugänge und einen Backup.
• Vereinbaren Sie ein finales „Abnahme-Build“-Commit-Hash und taggen Sie es.
• Wenn Sie in Koder.ai gebaut haben: exportieren Sie den Quellcode, nutzen Sie Snapshots und Rollback beim ersten Kunden-Deploy, um das Risiko zu verringern.