Blue-green skifter typisk al trafik mellem to miljøer. Canary sender først en mindre andel til den nye version. Metoderne kan kombineres.
Begreb
Blue-green deployment
•
2 min
•
Grundlæggende
Blue-green deployment er en release-strategi med to tilsvarende produktionsmiljøer. Blue kører den nuværende version, mens green klargøres og testes med den nye.
Derefter flyttes trafikken til green. Blue bevares midlertidigt til hurtig rollback.
Hvorfor er begrebet vigtigt?
Den nye version kan startes og testes, før brugerne flyttes. Rollback kan ske ved et nyt trafikskift i stedet for en ny deployment.
Overlapperioden kræver ekstra kapacitet, ensartet konfiguration og styr på data, sessioner og integrationer.
Typisk misforståelse
Blue-green deployment garanterer ikke nul nedetid. Forbindelser, cache, DNS, køer og delte databaser kan stadig give afbrydelser.
En databaseændring kan gøre den gamle applikation inkompatibel. Derfor skal ændringer ofte være bagudkompatible, indtil blue ikke længere skal bruges.
Eksempel
En fiktiv webshop kører version 3 i blue. Version 4 deployes til green bag samme load balancer og testes med syntetiske køb. Databaseskemaet udvides uden at fjerne felter, som version 3 bruger.
Trafikken skiftes til green. Stiger fejlprocenten, sendes nye forbindelser tilbage til blue.
Best practice
Opret begge miljøer fra samme kode og konfiguration.
Hold tilstand uden for miljøerne, og planlæg bagudkompatible datamigrationer.
Automatisér health checks, smoke tests, trafikskift og rollback.
Dræn forbindelser og køer kontrolleret før et miljø lukkes.
Overvåg fejlrate, svartid og kritiske transaktioner efter skiftet.
Bevar blue, indtil green er verificeret, men ikke længere end nødvendigt.
Frequently asked questions
Rolling deployment erstatter instanser gradvist i samme miljø. Blue-green holder versionerne adskilt under skiftet.
Ja, men begge applikationsversioner skal kunne arbejde sikkert med samme data og skema. Irreversible ændringer kan gøre rollback umulig.