Blue-green deployment — applicationning eski va yangi versiyasi uchun ikkita parallel, imkon qadar bir xil production muhitini saqlab, foydalanuvchi trafikini biridan ikkinchisiga almashtirish strategiyasidir. Odatda active muhit blue, yangi tayyorlanayotgan muhit green deb ataladi; ranglarning o‘zi doimiy ma’noga ega emas.
Muhitlarni tayyorlash
Green muhit yangi artifact, konfiguratsiya va infratuzilma bilan yaratiladi. Production trafik olmasdan health, smoke va muhim integration testlardan o‘tadi. Blue bilan network, permission, dependency va observability pariteti tekshiriladi.
Infrastructure as Code ikki muhitni takrorlanuvchan yaratadi. Qo‘lda yillar davomida o‘zgargan blue va yangi green orasidagi drift switching paytida yashirin xato keltiradi. Config va secret qiymatlari environmentga xos bo‘lsa ham schema hamda scope bir xil bo‘ladi.
Traffic switch
Load balancer, reverse proxy, service mesh yoki DNS trafikni green tomonga o‘tkazadi. Proxy darajasidagi switch tez va nazoratli, DNS esa resolver cache va TTL sabab darhol barcha clientga ta’sir qilmasligi mumkin. Connection draining blue dagi faol so‘rovlarni tugatadi.
Switch bir martalik yoki avval kichik foiz bilan bajarilishi mumkin. Foizli usul blue-greenni canary tahlili bilan birlashtiradi. Version label metric va loglarda qaysi muhit trafik olganini ko‘rsatadi.
Database va state
Ko‘pincha blue va green bitta database ni bo‘lishadi. Yangi schema eski versiya bilan backward-compatible bo‘lishi kerak, chunki rollback bluega qaytishi mumkin. Destructive migration traffic switchdan oldin bajarilsa eski versiya ishlamay qoladi.
Alohida database ishlatilsa replication, cutover va write divergence muammosi paydo bo‘ladi. Switch paytida ikki tomonga write tushmasligi yoki conflict resolution aniq bo‘lishi kerak. Stateful queue consumerlar dublikat side effectga qarshi idempotent bo‘ladi.
Rollback
Green metriclari buzilsa trafik bluega qaytariladi. Blue muhit rollback oynasi davomida o‘chirilmaydi. Biroq green yangi formatdagi data yozgan bo‘lsa blue uni o‘qiy olishi kerak. External notification yoki paymentni traffic switch ortga qaytarmaydi.
Rollback oynasi tugagach eski muhit keyingi deployment uchun qayta qurilishi mumkin. “Blue doim eski” emas; rollar almashadi. Environment nomiga tayanish o‘rniga release versiyasi ko‘rsatiladi.
Xarajat va cheklov
Ikki to‘liq muhit vaqtinchalik compute, database connection va IP resursini ko‘paytiradi. Katta stateful tizimni parallel nusxalash qimmat. Serverless yoki immutable infrastructure bu xarajatni kamaytirishi mumkin, ammo quota va cold start hisobga olinadi.
Blue-green zero downtimega yordam beradi, lekin avtomatik kafolat bermaydi. DNS cache, schema, session, long-lived connection va dependency limit uzilish keltirishi mumkin. Switch va rollback muntazam sinovdan o‘tadi.
Data va sessiya holati
Blue va green bir vaqtda umumiy databasega murojaat qilsa schema ikkala versiyaga mos bo‘lishi kerak. Bir martalik destructive migration muhitni trafik bilan birga ortga almashtirish imkonini yo‘qotadi. Session server xotirasida saqlansa foydalanuvchi switchdan keyin login holatini yo‘qotishi mumkin; shared session store yoki mos cookie formati zarur. Background worker va schedulerlar ikki muhitda bir payt ishlasa duplicate side effect yuz beradi, shuning uchun ularning faolligi alohida leader yoki switch bilan boshqariladi.
Cache kalit formati ham versiyalar orasida mos saqlanadi.
Bog‘liq tushunchalar
Deployment strategy, Traffic switch, Zero-downtime deployment, Canary deployment, Rollback, Environment parity, Connection draining