Ficha-friz va kod-friz ilova ishlanmasida: mohiyati, farqlari va qo'llanilishi

Ficha-friz nima?

Feature freeze — bu rejalashtirilgan reliz oldidan kod bazasiga yangi funksional qo'shishni vaqtinchalik taqiqlashdir. Jamoa xususiyatlarni merge qilishni to'xtatib, xatolarni tuzatish, optimallashtirish va mavjud kodni sayqallashga o'tadi. Ishlab chiquvchilar tugallanmagan xususiyatlarni faqat xato tuzatish doirasida yakunlaydilar, ko'lamni kengaytirmasdan.

Ficha-friz relizga ulgurmaydigan, lekin asosiy branchga qisman merge qilingan tugallanmagan xususiyatlar (work-in-progress) muammosini hal qiladi. Agar yangi xususiyatlarni qo'shish davom ettirilsa, regressiya xavfi ortadi: har bir yangi integratsiya tayyor modullarni qayta sinovdan o'tkazishni talab qiladi. Feature freeze reliz ko'lamini belgilab, uni harakatlanuvchi nishondan barqaror funksional to'plamiga aylantiradi.

Muhim eslatma: feature freeze ≠ code freeze. Ficha-frizda xato tuzatishlar, refaktoring, bog'liqliklarni yangilash va hujjatlashtirish ruxsat etiladi. Faqat yangi user-facing xususiyatlar, ya'ni ilova xatti-harakatini foydalanuvchi nuqtai nazaridan o'zgartiradigan har qanday kod taqiqlanadi. Code review tekshiruvi: agar PR yangi ekran, tugma yoki API metod qo'shsa — u friz olib tashlanmaguncha rad etiladi.

Kod-friz nima va u ficha-frizdan qanday farq qiladi

Code freeze (kod-friz) — qattiqroq amaliyot bo'lib, unda koddagi har qanday o'zgarishlar to'liq taqiqlanadi. Hatto xato tuzatishlar ham kritik bo'lmasa ruxsat etilmaydi. Kod-friz qisqa muddatga (odatda 24-48 soat) joriy etiladi va reliz bildining belgilangan commitlar to'plamidan yig'ilishini kafolatlaydi.

Ficha-friz va kod-friz o'rtasidagi farq nazorat darajasidadir. Ficha-friz ko'lamni boshqaradi: relizga aynan nima kiradi. Kod-friz sifatni boshqaradi: relizdan bir kun oldin yangi xato kiritish xavfi bartaraf etiladi. Amalda ko'plab jamoalar ikki bosqichli modeldan foydalanadilar: relizdan 1-2 hafta oldin — feature freeze, 24-48 soat — code freeze. Code freeze mobil ilovalar uchun ayniqsa muhim, chunki bildni rejalashtirilgan reliz sanasidan bir necha kun oldin do'konga yuklash kerak.

Kod-frizdan istisno — kritik zaifliklarning (CVE 9+ ball) xavfsizlik tuzatishlari. Bunday o'zgarishlar tezkor code review va jamoa xabarnomasi bilan favqulodda jarayon orqali amalga oshiriladi. Boshqa barcha o'zgarishlar keyingi reliz siklini kutadi.

Feature freeze vs code freeze: taqqoslash

Ficha-friz va kod-friz o'rtasidagi tanlov jamoaning yetukligi va reliz chastotasiga bog'liq. CI/CD va feature flags dan foydalanadigan jamoalar faqat 24 soatlik code freeze bilan cheklanishi mumkin, oylik relizli jamoalar esa odatda ikkala frizni ketma-ket qo'llaydilar.

Friz turlari: to'liq, qisman va BAU-freeze

To'liq ficha-friz va kod-frizdan tashqari, yanada moslashuvchan variantlar mavjud. Partial feature freeze (qisman friz) yangi funksionalni faqat ma'lum modullarda bloklaydi — masalan, to'lov moduli yoki autentifikatsiya modulida, qolgan komponentlarni o'zgarishlar uchun ochiq qoldirib.

BAU-freeze (business as usual freeze) — kelishuv varianti bo'lib, unda faqat ma'lum chegaradan (masalan, 500 qator kod) ko'p o'zgarish hajmiga ega yirik xususiyatlar taqiqlanadi. Kichik yaxshilanishlar, UI tuzatishlar va xato tuzatishlar davom etadi. BAU-freeze continuous delivery bilan ishlaydigan loyihalar uchun qulay, chunki bir haftaga ishlanmani to'liq to'xtatish iqtisodiy jihatdan foydasiz.

Shuningdek deployment freeze (deploy-friz) tushunchasi mavjud — ishlab chiqarishga deploylarni to'liq to'xtatish, odatda dam olish mavsumi (Rojdestvo ta'tillari, Black Friday) uchun xos. Bu davrda hatto hotfixlar ham bloklanadi, agar ular xavfsizlik bilan bog'liq bo'lmasa. Deployment freeze odatda 1-2 hafta davom etadi va kompaniya darajasida kelishiladi.

Frizni qachon joriy etish va qancha davom etishi

Ficha-frizni joriy etishning optimal momenti — code complete dan so'ng, barcha rejalashtirilgan xususiyatlar merge qilingan va QA dan o'tayotganda. Aniq muddat reliz siklidan bog'liq: ikki haftalik sprint uchun ficha-friz reliz sanasidan 3-4 kun oldin, oylik reliz uchun — 7-10 kun oldin joriy etiladi. Code freeze reliz bildini yig'ish rejalashtirilgan vaqtdan 24-48 soat oldin joriy etiladi.

Friz davomiyligi kodni barqarorlashtirish uchun minimal yetarli bo'lishi kerak. Haddan tashqari uzoq friz (2 haftadan ko'p) jamoani demotivatsiya qiladi va merge qilinmagan xususiyatlarning to'planishiga olib keladi, ularning har biri friz olib tashlangandan keyin konfliktlar xavfini oshiradi. Haddan tashqari qisqa friz (ficha-friz uchun 24 soatdan kam) to'liq sinov va tuzatishlar uchun vaqt bermaydi.

Tavsiya etilgan amaliyot — frizni kalendar sanasi bo'yicha emas, balki kod bazasi holatiga qarab belgilash. Ficha-friz relizdagi ochiq buglar soni chegaradan (masalan, 10 kritik bug) oshganda joriy etiladi. Code freeze — bild smoke tests va regression suitelarni muvaffaqiyatli o'tkazganda. Time-based freeze (qat'iy sana) tartibga solinadigan sohalar (fintekh, medtekh) uchun standart bo'lib qolmoqda, bunda reliz sanasi nazoratchi tomonidan tasdiqlangan.

Frizlarni CI/CD va Git orqali avtomatlashtirish

Frizlarni qo'lda nazorat qilish — xatolar manbai: ishlab chiquvchi tasodifan friz olib tashlanishini kutishi kerak bo'lgan PRni merge qilishi mumkin. Avtomatlashtirish muammoni Git branch protection qoidalari va CI/CD pipeline'lari orqali hal qiladi. Git provayderida (GitHub, GitLab, Bitbucket) reliz branchiga maxsus tegsiz yoki reliz menejeri tasdiqlovsiz mergelarni bloklaydigan qoidalar o'rnatiladi.

CI/CD pipeline bildni yig'ishdan oldin friz holatini tekshiradi. Jenkins, GitLab CI yoki GitHub Actions da frizlar jadvali bilan konfiguratsiya faylini o'qiydigan va joriy sana friz davriga to'g'ri kelsa bildlarni rad etadigan qadam qo'shiladi. Muqobil — admin paneldagi ishlab chiqarishga deployni bloklaydigan feature flag.

# .github/workflows/check-freeze.yml
name: Check Freeze Status
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check-freeze:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check freeze status
        run: node .github/scripts/freeze-check.js
      - name: Block PR if frozen
        if: failure()
        run: echo "Feature freeze faol. PR bloklangan." && exit 1

freeze-check.js skriptining namunasi ombor ildizidan frizlar jadvali bilan JSONni o'qiydi. Agar joriy sana ko'rsatilgan branch uchun start_date va end_date orasiga to'g'ri kelsa — pipeline friz holati haqidagi xabar bilan muvaffaqiyatsiz tugaydi. Git branch protection ikkinchi to'siqni qo'shadi: pipeline ishlamagan taqdirda ham, qoidalar tasdiqlovsiz PRni merge qilishga ruxsat bermaydi.

Frizlarni joriy etishdagi odatdagi xatolar

Birinchi xato — frizni olib tashlashning aniq mezonisiz joriy etish. Jamoa kodni muzlatadi, lekin muzdan tushirish uchun qanday shartlar bajarilishi kerakligini aniqlamaydi: nol kritik bug, regression suitedan o'tish, product-menejerning tasdiqlovi. Mezonlarsiz friz haftalarga cho'zilishi mumkin. Definition of done friz uchun hujjatlashtirilgan va har bir ishlab chiquvchiga ma'lum bo'lishi kerak.

Ikkinchi xato — frizdan juda ko'p istisnolar. Har bir exception ("bu PR xususiyat emas, balki texnik qarz") friz chegarasini xiralashtiradi. Agar exceptions odatdagi PR oqimining 20% dan oshsa — friz ishlamaydi. Jamoa shunchaki blokirovkadan o'tish uchun xususiyatlarni xato tuzatishlarga nomini o'zgartiradi.

Uchinchi xato — release candidatelarni e'tiborsiz qoldirish. Agar jamoa release candidate bildlarni yig'masa va code freezedan so'ng darhol ishlab chiqarishga deploy qilsa, frizning ma'nosi yo'qoladi: xatolar foydalanuvchilar tomonidan topiladi. Release candidate code freezedan oldin yig'ilishi, QA va stagingda sinovdan o'tkazilishi va faqat sifat tasdiqlanganidan keyin code freeze joriy etilishi kerak.

To'rtinchi xato — qo'lda nazoratdagi inson omili. Ishlab chiquvchi merge qilishdan oldin friz holatini tekshirishni unutishi mumkin, reliz menejeri — xabarnomani o'tkazib yuborishi mumkin. Yagona ishonchli yechim — Git provider yoki CI/CD darajasida inson xatosini istisno qiladigan avtomatik bloklash.