Machen Sie Ihr nächstes Deployment wiederholbar

Identifizierbare Eingaben sammeln

Verwenden Sie eine Anwendung, die Sie in einer Nicht-Produktionsumgebung bauen können, Zugriff auf den Quellcode und die zugehörige Artefakt-Registry, ein versioniertes Konfigurationsschema und einen externen Secret Store. Halten Sie ein bekanntes funktionierendes Release bereit. Dies sind Eingaben für Ihre Automatisierung; PrivacyNodes stellt über diese Website keine Deployment-API und keinen Pipeline-Runner bereit.

Pinnen Sie das Artefakt, anstatt sich auf ein veränderliches Label wie latestzu verlassen. Docker dokumentiert Digest-Pinning, um ein exaktes Basis-Image zu identifizieren, mit der Notwendigkeit, Updates bewusst zu prüfen. Reproduzierbarkeit und Patchen sind beide Verantwortlichkeiten: Ein altes verwundbares Image für immer zu behalten, ist kein Wartungsplan.

Technische Referenz: Docker-Build-Best-Practices.

Ein Release-Protokoll schreiben, bevor der Verkehr umgestellt wird

Dies ist ein Dokumentformat, kein ausführbares Skript. Füllen Sie die Platzhalter aus dem geprüften Artefakt. Eine Quellcode-Revision allein beschreibt keine Umgebungsänderungen. Nehmen Sie die beobachtete Migrationsdauer, das erwartete Lock-Verhalten, Konfigurationsunterschiede und das letzte funktionierende Artefakt auf.

# Illustrative release record — no credentials
release: reports-api-review-01
source_revision: REVISION_TO_REVIEW
artifact_digest: DIGEST_FROM_YOUR_REGISTRY
configuration_schema: config-v3
migration: add-export-state
old_code_can_read_new_schema: yes
verification:
  - authenticated-read
  - enqueue-and-complete-test-export
  - failed-dependency-behavior
rollback_decision: keep-additive-schema-and-previous-artifact
operator_and_result: TO_BE_RECORDED

Bewahren Sie das Protokoll an einem Ort auf, der erreichbar ist, wenn die Anwendung ausgefallen ist. Referenzieren Sie geschützte Wiederherstellungs-Anmeldedaten, ohne deren Werte aufzunehmen. Nennen Sie den Maintainer, der die Promotion stoppen kann, und den Punkt, nach dem das geplante Rollback nicht mehr gültig ist.

Vorbereitung von Promotion trennen

Bauen und prüfen Sie zuerst das Artefakt. Validieren Sie Konfiguration und Secret-Referenzen, bevor Sie den neuen Prozess starten. Wenden Sie nur den für dieses Release geprüften Schema-Schritt an. Starten Sie die neue Version in der vorgesehenen Umgebung und prüfen Sie Abhängigkeiten, bevor Sie den Verkehr umstellen; vermeiden Sie es, eine ungeprüfte destruktive Migration mit einem gewöhnlichen Image-Update zu kombinieren.

Bei Compose etabliert ein gestarteter Container keine Bereitschaft. Ein aussagekräftiger Health-Check und condition: service_healthy können das Warten auf Abhängigkeiten nützlich machen, aber keinen Kundenworkflow verifizieren. Die Anwendung muss weiterhin den Fall behandeln, dass eine Abhängigkeit nach dem Start nicht verfügbar wird.

Technische Referenz: Docker Compose Startreihenfolge.

Mehr als einen grünen Port verifizieren

Für die Reporting-API prüfen Sie eine authentifizierte Testanfrage, einen Lesevorgang gegen das vorgesehene Schema, einen kleinen in die Warteschlange gestellten Export und den Zugriff auf dessen Datei. Verwenden Sie einen dedizierten Test-Namespace und unterdrücken Sie Produktionsbenachrichtigungen. Stellen Sie sicher, dass überlappende Versionen geplante Arbeit nicht versehentlich duplizieren können.

Schreiben Sie erwartete Ausgaben vor der Prüfung: korrekter Kontobereich, der erwartete Beispiel-Datensatz, ein abgeschlossener Export und keine unbefugten kontenübergreifenden Daten. Zeichnen Sie danach tatsächliche Ausgaben und Zeitpunkte auf. Eine Startseite, die HTTP 200 zurückgibt, ist unzureichend, wenn ein Worker wiederholt ausfällt oder eine Migration die API dazu brachte, veraltete Werte zu lesen.

Die Wiederherstellungsentscheidung explizit machen

Wenn der Prozess nicht startet, belassen Sie den Datenverkehr auf der funktionierenden Version. Wenn eine Workflow-Prüfung fehlschlägt, stoppen Sie die Beförderung und bewahren Sie redigierte Nachweise auf. Ein additives Schema, das mit dem alten Artefakt kompatibel ist, kann ein Anwendungs-Rollback ermöglichen. Nach einer inkompatiblen Transformation kann alter Code unsicher sein; befolgen Sie den überprüften Vorwärts-Fix- oder Datenwiederherstellungsplan.

Wiederholen Sie eine fehlschlagende Migration nicht endlos. Stellen Sie fest, was committet wurde, ob ein Wiederholungsversuch sicher ist und ob Benutzer unter dem neuen Schema geschrieben haben. Die Migrationsanleitung entwickelt diese Grenze mit einer Spaltenänderung. Betrachten Sie die Existenz einer Rollback-Schaltfläche nicht als Beweis dafür, dass Daten rückgängig gemacht werden können.

Ein Protokoll hinterlassen, dem ein anderer Maintainer folgen kann

Vergleichen Sie die eingesetzten Artefakt- und Konfigurationsbezeichner mit dem geplanten Datensatz. Bewahren Sie Prüfungen, fehlgeschlagene Versuche und die gewählte Wiederherstellungsaktion auf. Halten Sie das letzte funktionierende Artefakt gemäß einer expliziten Aufbewahrungsrichtlinie vor; entfernen Sie es nicht, solange die Validierung unvollständig ist.

Eine nützliche Probe lässt einen anderen autorisierten Maintainer die Eingaben erklären, die Prüfungen wiederholen und Wiederherstellungsanweisungen finden, ohne Ihre Shell-Historie zu durchsuchen. Sie beweist weder Null-Ausfallzeit noch zukünftigen Erfolg. Überprüfen Sie sie erneut, wenn sich Schema, Worker-Verhalten oder Abhängigkeiten ändern. Als Nächstes schränken Sie die Berechtigungen der Deployment-Identität.