Maak uw volgende deployment herhaalbaar

Verzamel identificeerbare inputs

Gebruik een applicatie die je in een niet-productieomgeving kunt bouwen, toegang tot de bron en het artefactregister, een versioned configuratieschema en een externe secretstore. Houd een bekende werkende release aan. Dit zijn inputs voor je automatisering; PrivacyNodes biedt via deze website geen deployment-API of pipeline-runner.

Pin het artefact in plaats van te vertrouwen op een veranderlijk label zoals latest. Docker documenteert digest-pinning om een exacte basisimage te identificeren, met de noodzaak om updates bewust te beoordelen. Reproduceerbaarheid en patchen zijn beide verantwoordelijkheden: een oude kwetsbare image voor altijd bewaren is geen onderhoudsplan.

Technische referentie: Docker build best practices.

Schrijf een releaseverslag voordat je verkeer wijzigt

Dit is een documentformaat, geen uitvoerbaar script. Vul de placeholders in vanuit het beoordeelde artefact. Een bronrevisie alleen beschrijft geen omgevingswijzigingen. Neem de waargenomen migratieduur, verwacht lockgedrag, configuratieverschillen en het laatst werkende artefact op.

# 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

Bewaar het verslag ergens bereikbaar wanneer de applicatie uitligt. Verwijs naar beschermde herstelreferenties zonder hun waarden op te nemen. Noem de beheerder die promotie kan stoppen en het punt waarna de geplande rollback niet meer geldig is.

Scheid voorbereiding van promotie

Bouw en inspecteer eerst het artefact. Valideer configuratie en secretverwijzingen voordat je het nieuwe proces start. Pas alleen de schemastap toe die voor deze release is beoordeeld. Start de nieuwe versie in de beoogde omgeving en controleer afhankelijkheden voordat je verkeer verplaatst; vermijd het combineren van een niet-beoordeelde destructieve migratie met een gewone image-update.

Bij Compose toont een gestarte container geen gereedheid aan. Een betekenisvolle healthcheck en condition: service_healthy kunnen het wachten op afhankelijkheden nuttig maken, maar kunnen een klantworkflow niet verifiëren. De applicatie moet nog steeds omgaan met een afhankelijkheid die na de start niet beschikbaar wordt.

Technische referentie: Docker Compose opstartvolgorde.

Verifieer meer dan een groene poort

Controleer voor de rapportage-API een geauthenticeerd testverzoek, een leesbewerking op het beoogde schema, een kleine export in de wachtrij en toegang tot het bijbehorende bestand. Gebruik een aparte testnaamruimte en onderdruk productiemeldingen. Controleer of overlappende versies gepland werk niet per ongeluk kunnen dupliceren.

Schrijf verwachte uitvoer op voordat u controleert: correct accountbereik, het verwachte voorbeeldrecord, één voltooide export en geen ongeoorloofde gegevens tussen accounts. Registreer daarna de werkelijke uitvoer en timing. Een startpagina die HTTP 200 retourneert is onvoldoende als een worker herhaaldelijk faalt of een migratie de API verouderde waarden laat lezen.

Maak de herstelbeslissing expliciet

Als het proces niet start, houd verkeer op de werkende versie. Als een workflowcontrole mislukt, stop de promotie en bewaar geredigeerd bewijs. Een additief schema dat compatibel is met het oude artifact kan applicatierollback mogelijk maken. Na een incompatibele transformatie kan oude code onveilig zijn; volg het beoordeelde forward-fix- of gegevensherstelplan.

Herhaal een mislukte migratie niet oneindig. Bepaal wat is vastgelegd, of opnieuw proberen veilig is en of gebruikers onder het nieuwe schema hebben geschreven. De migratiehandleiding werkt deze grens uit met een kolomwijziging. Beschouw het bestaan van een rollback-knop niet als bewijs dat gegevens kunnen worden teruggedraaid.

Laat een verslag achter dat een andere beheerder kan volgen

Vergelijk geïmplementeerde artifact- en configuratie-identificatoren met het geplande record. Bewaar controles, mislukte pogingen en de gekozen herstelactie. Houd het laatst werkende artifact onder een expliciet bewaarbeleid; verwijder het niet zolang de validatie onvolledig is.

Een nuttige repetitie stelt een andere geautoriseerde beheerder in staat de invoer uit te leggen, de controles te herhalen en herstelinstructies te vinden zonder uw shell-geschiedenis te doorzoeken. Het bewijst geen zero downtime of toekomstig succes. Herzie het wanneer schema, workergedrag of afhankelijkheden veranderen. Beperk vervolgens de machtigingen van de deployment-identiteit.