Deployment strategy — yangi dastur versiyasini hisoblash muhitiga qanday joylashtirish, foydalanuvchi trafikini qanday o‘tkazish va xatoni qanday cheklashni belgilaydigan yondashuvdir. Tanlov mavjudlik talabi, infratuzilma sig‘imi, state, database mosligi, release tezligi va qabul qilinadigan riskga bog‘liq.
Asosiy strategiyalar
Recreate eski instancelarni to‘xtatib, keyin yangi versiyani ishga tushiradi. U sodda va kam resurs talab qiladi, ammo downtime beradi. Rolling deployment instancelarni guruhma-guruh almashtiradi. Blue-green parallel yangi muhit tayyorlab, trafikni bir marta switch qiladi.
Canary yangi versiyaga kichik trafik ulushini beradi va metric asosida kengayadi. Progressive delivery canary, cohort, feature flag va avtomatik analysisni kengroq jarayonga birlashtiradi. A/B testing release xavfsizligidan tashqari mahsulot gipotezasini taqqoslashga qaratilgan.
Tanlash mezonlari
Stateless HTTP xizmat rolling yoki canaryga qulay. Uzoq session, WebSocket yoki local state drain va affinity talab qiladi. Stateful database clusterida replica order, leader election va data format muhim. Har komponent uchun bir xil strategiyani qo‘llash shart emas.
Blue-green deyarli ikki barobar qisqa muddatli capacity talab qiladi. Rolling kamroq surge bilan ishlashi mumkin, lekin mixed-version moslik kerak. Recreate test yoki ichki past-muhim xizmat uchun maqbul bo‘lishi mumkin. Narx va operatsion murakkablik availability bilan muvozanatlanadi.
Ma’lumotlar bazasi
Application rollout va schema migration alohida bosqichlarga ajratiladi. Backward-compatible migration avval, yangi kod keyin, destructive cleanup esa barcha eski instance yo‘qolgach bajariladi. Migrationni applicationning har replica startida parallel bajarish lock va race keltirishi mumkin.
Data backfill uzoq davom etsa alohida job sifatida kuzatiladi. Yangi kod backfill tugamagan yozuvlarni qayta ishlay olishi kerak. Rollback uchun eski schema va yangi yozilgan data mosligi sinovdan o‘tadi.
Trafik va sog‘lomlik
Load balancer faqat readinessdan o‘tgan instancega trafik beradi. Readiness real dependency va critical pathni tekshiradi, ammo tashqi servisdagi kichik tebranish barcha instanceni birdan chiqarib yubormasligi kerak. Graceful shutdown faol requestlarni yakunlaydi.
Canary va traffic splittingda version label metric, log va tracega qo‘shiladi. Error, latency va business outcome stable baseline bilan solishtiriladi. Sample size va observation window oldindan belgilanadi.
Qaytarish va audit
Har strategiya pause, abort va rollback mexanizmiga ega bo‘ladi. Rollback eski imagega qaytishdan tashqari config, flag, database va message compatibilityni hisobga oladi. Yuqori riskli release oldidan runbook va authority belgilanadi.
Artifact digest, deploy vaqti, operator yoki automation, metric qarori va yakuniy status saqlanadi. Deployment muvaffaqiyati faqat pipeline yashil bo‘lishi emas, foydalanuvchi uchun xizmatning kutilgan holatda qolishidir.
Strategiyani tanlash mezonlari
Tanlov servisning stateful yoki statelessligi, trafikni bo‘lish imkoniyati, qo‘shimcha capacity va ruxsat etilgan uzilish vaqtiga bog‘liq. Monolit database migration bilan birga chiqsa oddiy canary faqat application xavfini kamaytiradi, umumiy schema xavfini emas. Mobil client darhol yangilanmagani uchun server bir nechta client versiyasini qo‘llashi mumkin. Strategiya nomini tanlashdan ko‘ra, mixed-version davri, rollback oynasi, kuzatiladigan metric va trafik boshqaruvchisi aniq yozilishi muhim.
Xarajat ham texnik mezon sifatida qayd etiladi.
Bog‘liq tushunchalar
Rolling deployment, Blue-green deployment, Canary deployment, Recreate deployment, Progressive delivery, Rollback, Traffic splitting