Deployment unit — build, versiyalash va ish muhitiga joylashtirish jarayonida bitta butun sifatida boshqariladigan dasturiy artefakt yoki komponentlar to‘plami. Executable fayl, JAR/WAR, container image, serverless function paketi yoki mobil ilova bitta deployment unit bo‘lishi mumkin. Uning chegarasi source-code moduliga aynan teng bo‘lishi shart emas; asosiy belgi — qismlar birgalikda release qilinadi.
Build va versiya
Deployment unit reproducible build orqali aniq source commit va dependencylardan yaratiladi. Artefaktga o‘zgarmas versiya yoki content digest beriladi. Bir xil artefakt test, staging va production muhitlari bo‘ylab ko‘chiriladi; har muhitda kodni qayta yig‘ish supply-chain va moslik xavfini oshiradi.
Konfiguratsiya ko‘pincha artefaktdan tashqarida, environment variable, secret store yoki config fayl orqali beriladi. Shunda bir image turli muhitda ishlaydi. Konfiguratsiya schema va defaultlari unit versiyasi bilan mos bo‘lishi kerak.
Arxitekturadagi chegarasi
Monolit ilovada ko‘plab biznes modul bitta deployment unitga kiradi. Bitta modul o‘zgarsa ham butun artefakt qayta release qilinadi. Microservice arxitekturasida har xizmat ko‘pincha alohida unit bo‘lib, mustaqil deploy qilinadi. Bu mustaqillik faqat alohida repository bilan emas, runtime va ma’lumot contractlari bilan ta’minlanadi.
Bir deployment unit ichidagi qismlar odatda bir process hayot siklini bo‘lishadi. Bitta qism crash qilsa process qayta ishga tushishi mumkin. Alohida unitlar esa tarmoq orqali muloqot qiladi va partial failure, timeout hamda version compatibility muammolarini keltiradi.
Release va rollback
Rolling deployment eski va yangi unit versiyalarini bir muddat parallel ishlatadi. API, database migration va xabar schema shu davrda backward-compatible bo‘ladi. Blue-green deployment yangi muhitni to‘liq tayyorlab, trafikni bir vaqtda o‘tkazadi. Canary release esa yangi unitni trafikning kichik qismida sinaydi.
Rollback avvalgi artefaktni qayta joylashtiradi, ammo o‘zgargan database yoki tashqi side effect avtomatik orqaga qaytmaydi. Expand-and-contract migration eski va yangi versiyaga mos schema bosqichlarini ajratadi. Unitning health va readiness tekshiruvlari trafik olishdan oldin dependencylar tayyorligini bildiradi.
Masshtablash va resurs
Deployment unit replica sifatida masshtablanadi. Unit ichidagi faqat bitta funksiya ko‘p CPU ishlatsa ham barcha kod nusxalanishi mumkin. Katta monolitda bu resurs samarasizligi, kichik tizimda esa operatsion soddalik bo‘lishi mumkin.
Container unit CPU va memory limit, port, volume va security context bilan ishga tushadi. Stateful unitning persistent ma’lumoti artefaktning ephemeral fayl tizimiga bog‘lanmaydi. Replica almashganda session yoki fayl yo‘qolmasligi uchun tashqi store ishlatiladi.
Kuzatuv va identifikatsiya
Log, metric va trace unit nomi, versiyasi, instance IDsi va environmentni saqlaydi. Xato faqat “service ishlamadi” emas, qaysi digest va konfiguratsiyada yuz bergani bilan aniqlanadi. SBOM unit ichidagi dependencylarni ko‘rsatib, zaif paket qaysi release’da borligini topishga yordam beradi.
Deployment unit chegarasi jamoa ownershipi va failure domain bilan mos bo‘lsa boshqarish osonlashadi. Juda mayda unitlar release, networking va observability sonini oshiradi; juda katta unitlar mustaqil o‘zgarish va masshtablashni cheklaydi.
Artefakt yaxlitligi
Registrydagi image yoki paket cryptographic digest bilan tekshiriladi. Imzolangan provenance uni qaysi build pipeline va source’dan chiqqanini ko‘rsatadi. Tag qayta ishlatilishi mumkin, digest esa contentga bog‘liq; production manifesti aniq digestni pin qilsa, keyinchalik o‘sha tag boshqa imagega ko‘chirilsa ham deploy o‘zgarmaydi.
Bog‘liq tushunchalar
Artifact, Container image, Release, Monolithic architecture, Microservice architecture, Rolling deployment