Een implementatie terugdraaien

If a deployment breaks production, you can put an earlier build back in front of traffic in seconds without rebuilding anything. This guide covers how rollback works, how to pick the right…

Als een implementatie de productie onderbreekt, kunt u in enkele seconden een eerdere build terug voor het verkeer zetten zonder iets opnieuw te bouwen. Deze handleiding behandelt hoe terugdraaien werkt, hoe u de juiste implementatie kiest, de automatische terugdraaiingen die Orbit voor u kan uitvoeren, en wat u moet doen nadat u hebt teruggedraaid.

Hoe terugdraaien werkt

Orbit bewaart het verpakte artefact van elke succesvolle build. Een terugdraaiing voert uw installatie of buildopdracht niet opnieuw uit: het bevordert een artefact dat al bestaat en al is gebruikt, dus het is voltooid in enkele seconden en kan niet mislukken om een van de redenen dat een build kan mislukken.

Dat is precies de reden om het eerst te proberen. Terugdraaien is sneller en veel voorspelbaarder dan proberen naar voren te repareren terwijl uw site kapot is.

Terugdraaien naar een eerdere implementatie

Open uw project in Orbit.
Open het tabblad Deployments.
Zoek de laatste implementatie waarvan u weet dat deze goed was.
Klik Roll back op die rij en bevestig.

De bevestiging zegt precies wat er zal gebeuren: verkeer wordt onmiddellijk bediend vanuit de oudere build, en de huidige implementatie wordt vervangen.

Tabblad Deployments met de actie roll back

U kunt ook terugdraaien vanaf de detailpagina van een implementatie, waar de knop Rollback to luidt met de korte commit-hash.

De herstelde implementatie krijgt de badge CURRENT. De implementatie waarvan u bent teruggegaan behoudt zijn plaats in de geschiedenis met de status Rolled back.

Terugdraaien is niet destructief en hoeft niet ongedaan te worden gemaakt. Niets wordt verwijderd, geen geschiedenis wordt herschreven, en uw repository blijft onaangetast. Uw volgende succesvolle push naar de productiebranch wordt op de normale manier simpelweg de nieuwe live-versie.

De juiste implementatie identificeren

Elke rij op het tabblad Deployments toont het commit-bericht en korte hash, de branch, de status, wanneer deze is geïmplementeerd, en wie dit heeft gepusht. De live versie draagt de badge CURRENT.

Meestal wilt u de implementatie onmiddellijk vóór degene die het probleem veroorzaakte. Twee dingen helpen u zeker te zijn:

Vergelijken. Open de verdachte implementatie en klik Compare om een diff te maken tegen de vorige: buildtijd, artefactgrootte, cachestatus, framework, en het artefactverschil op bestandsniveau.
Implementatienotities. Elke implementatie kan een notitie van tot 500 tekens dragen. Het toevoegen van "hotfix for payment bug" of "feature flag X on" op het moment kost niets en maakt de geschiedenis maanden later leesbaar, wat precies het moment is waarop u het nodig hebt.

Terugdraaien naar een artefact rolt niet uw omgevingsvariabelen, omleidingsregels of response-headers terug. Deze worden op het moment van het verzoek of de build gelezen, niet in het artefact ingebakken. Als het incident werd veroorzaakt door een configuratiewijziging in plaats van een codewijziging, zal het terugdraaien van de code dit niet oplossen. De pagina met implementatiedetails laat de variabelen zien die op buildtijd waren geïnjecteerd versus uw huidige configuratie, wat de snelste manier is om de twee uit elkaar te halen.

Automatisch terugdraaien

Orbit kan dit voor u doen voordat u het zelfs hebt opgemerkt. Alle drie de instellingen bevinden zich in Settings.

Auto-Rollback bij fout

Onder Runtime, schakel Auto-rollback on failure in. Als een productiebuild mislukt, wordt de laatste gezonde implementatie automatisch hersteld en zien bezoekers geen uitval. Staging heeft een eigen gelijkwaardige schakelaar.

Gezondheidcheck

Onder Health check, stel een Health check path in, bijvoorbeeld / of /api/health. Na elke productiebuild haalt Orbit dat pad op. Als het niet binnen 15 seconden een 2xx-antwoord retourneert, wordt de vorige gezonde implementatie hersteld.

Smoke Tests

Onder Smoke tests vermeldt u tot 10 kommagescheiden paden, bijvoorbeeld /,/blog,/api/health. Na elke succesvolle build stuurt Orbit een GET naar elk pad en registreert pass of fail. Als er een mislukt en auto-rollback is ingeschakeld, wordt de vorige implementatie hersteld. Het resultaat verschijnt op de implementatiepagina als Smoke tests passed of een faaltellingen, en zegt Triggered rollback als het er een veroorzaakte.

Een gezondheidcheck op een route die werkelijk uw database gebruikt, is veel meer waard dan een op de startpagina. Een verbroken deploy die nog steeds een cachedstartpagina serveert, slaagt voor een /-check en mislukt voor een echte.

Terugdraaien versus Deploy Lock

Als u nog niet klaar bent om terug te draaien maar niets nieuws live wilt laten gaan terwijl u onderzoekt, vergrendel implementaties in plaats daarvan:

Open het project.
Klik Lock deploys.
Voeg een reden toe, bijvoorbeeld "investigating production issue".

Push-geactiveerde implementaties worden dan stilzwijgend overgeslagen, en een banner leest Production deploys are locked met uw reden. Handmatige implementaties werken nog steeds, wat opzettelijk is: de vergrendeling stopt onbedoelde implementaties, niet de fix die u verzendt. Klik Unlock deploys om dit op te heffen.

Een vergrendeling en een terugdraaiing werken goed samen. Draai eerst terug om service te herstellen, vergrendel vervolgens zodat niemand's routine merge het ongedaan maakt terwijl u aan het diagnosticeren bent.

Staging naar productie promoveren

Als u een staging-omgeving hebt, kunt u een geteste staging-build in productie zetten zonder iets te pushen.

Open het projectoverzicht en zoek de sectie Staging.
Als staging vóór productie ligt, verschijnt Promote to production.
Klik erop en bevestig.

Lees de bevestiging zorgvuldig, want er zijn twee verschillende promotiegedragingen in Orbit en deze zijn niet uitwisselbaar. Promotie vanaf het projectoverzicht activeert een verse productiebuild op dezelfde commit, met behulp van productiomgevingsvariabelen en productiebuilopdrachten. Het staging-artefact wordt niet opnieuw gebruikt. Het promoveren van een specifieke staging-implementatie vanaf de detailpagina ervan stelt duidelijk dat de staging-build onmiddellijk live gaat zonder herbouw. Als uw staging- en productiomgevingsvariabelen verschillen, levert het eerste pad een ander artefact op dan degene die u hebt getest.

Orbit kan ook voor u promoveren. Auto-promote staging in Settings bevordert staging naar productie na een aantal uren gezonde staging met rook-tests die voorbijgaan, gecontroleerd elke 15 minuten.

Na een terugdraaiing

Repareer het onderliggende probleem in uw repository en push een nieuwe commit. Dit activeert een normale build die de nieuwe live-versie wordt. Als u implementaties hebt vergrendeld, ontgrendel deze eerst, anders wordt de push overgeslagen.

Het projecttabblad Activity registreert de terugdraaiing samen met alles anders wat gebeurde, dus er is een audittrail van wie wat en wanneer heeft teruggedraaid.

Wat beperkt hoe ver terug u kunt gaan

Terugdraaien vereist dat het artefact nog bestaat. Twee instellingen controleren dat:

Het implementatiegeschiedenisvenster van uw plan: 7 dagen op Launch, 30 op Liftoff, 90 op Apex.
De Artifact retention instelling van het project, die een aantal succesvolle artefacten per omgeving bewaart, van 10 tot 500, standaard 50.

Het artefact van de momenteel live implementatie wordt altijd behouden, ongeacht beide.

Als u veel keer per dag implementeert, is de artefactentelling de limiet die u eerst raakt, niet de dagentelling. Vijftig implementaties kunnen een enkele week zijn. Verhoog Artifact retention in plaats van het plafond te ontdekken tijdens een incident.