فریز ویژگی و فریز کد در توسعه اپلیکیشن: مفهوم، تفاوت‌ها و کاربرد

فریز ویژگی چیست؟

Feature freeze — ممنوعیت موقت افزودن قابلیت جدید به پایگاه کد است که قبل از انتشار برنامه‌ریزی‌شده اعمال می‌شود. تیم از merge کردن ویژگی‌ها دست می‌کشد و به رفع باگ، بهینه‌سازی و صیقل دادن کد موجود می‌پردازد. توسعه‌دهندگان ویژگی‌های ناتمام را تنها در چارچوب رفع باگ تکمیل می‌کنند، بدون گسترش دامنه.

فریز ویژگی مشکل ویژگی‌های ناتمام (work-in-progress) را حل می‌کند که به موقع برای انتشار آماده نمی‌شوند اما تا حدی در شاخه اصلی merge شده‌اند. اگر به اضافه کردن ویژگی‌های جدید ادامه دهید، خطر رگرسیون افزایش می‌یابد: هر یکپارچه‌سازی جدید نیاز به تست مجدد ماژول‌های آماده دارد. Feature freeze دامنه انتشار را ثابت کرده و آن را از یک هدف متحرک به مجموعه‌ای پایدار از قابلیت‌ها تبدیل می‌کند.

نکته مهم: feature freeze ≠ code freeze. در فریز ویژگی، رفع باگ، بازسازی کد، به‌روزرسانی وابستگی‌ها و مستندات مجاز است. فقط ویژگی‌های جدید کاربرپسند (user-facing features) ممنوع هستند، یعنی هر کدی که رفتار اپلیکیشن را از دید کاربر تغییر دهد. بررسی در code review: اگر PR یک صفحه، دکمه یا متد API جدید اضافه کند — تا برداشته شدن فریز رد می‌شود.

فریز کد چیست و چه تفاوتی با فریز ویژگی دارد

Code freeze (فریز کد) — روش سخت‌گیرانه‌تری است که در آن هرگونه تغییر در کد به طور کامل ممنوع است. حتی رفع باگ نیز مجاز نیست مگر اینکه بحرانی باشد. فریز کد برای مدت کوتاهی (معمولاً ۲۴-۴۸ ساعت) اعمال می‌شود و تضمین می‌کند که بیلد انتشار از مجموعه ثابتی از commitها ساخته شده است.

تفاوت بین فریز ویژگی و فریز کد در سطح کنترل است. فریز ویژگی دامنه را مدیریت می‌کند: دقیقاً چه چیزی وارد انتشار می‌شود. فریز کد کیفیت را مدیریت می‌کند: خطر ورود باگ جدید یک روز قبل از انتشار حذف می‌شود. در عمل بسیاری از تیم‌ها از مدل دو مرحله‌ای استفاده می‌کنند: ۱-۲ هفته قبل از انتشار — feature freeze، ۲۴-۴۸ ساعت — code freeze. Code freeze به ویژه برای اپلیکیشن‌های موبایل مهم است، جایی که بیلد باید چند روز قبل از تاریخ انتشار برنامه‌ریزی‌شده در فروشگاه بارگذاری شود.

استثنای فریز کد — رفع امنیتی آسیب‌پذیری‌های بحرانی (CVE با امتیاز ۹+). چنین تغییراتی از طریق فرآیند اضطراری با code review سریع و اطلاع‌رسانی به تیم انجام می‌شود. سایر تغییرات تا چرخه انتشار بعدی به تعویق می‌افتند.

Feature freeze در مقابل code freeze: مقایسه

انتخاب بین فریز ویژگی و فریز کد به بلوغ تیم و تعداد انتشارها بستگی دارد. تیم‌هایی که از CI/CD و feature flags استفاده می‌کنند می‌توانند تنها با code freeze به مدت ۲۴ ساعت کار کنند، در حالی که تیم‌هایی با انتشار ماهانه معمولاً از هر دو فریز به صورت متوالی استفاده می‌کنند.

انواع فریز: کامل، جزئی و فریز BAU

علاوه بر فریز کامل ویژگی و فریز کد، گزینه‌های انعطاف‌پذیرتری نیز وجود دارند. Partial feature freeze (فریز جزئی) قابلیت جدید را فقط در ماژول‌های خاص مسدود می‌کند — مثلاً در ماژول پرداخت یا ماژول احراز هویت، و سایر اجزا را برای تغییرات باز می‌گذارد.

فریز BAU (business as usual freeze) — گزینه مصالحه‌ای که در آن فقط ویژگی‌های بزرگ با حجم تغییر بیش از آستانه معین (مثلاً ۵۰۰ خط کد) ممنوع می‌شوند. بهبودهای کوچک، تنظیمات UI و رفع باگ همچنان ادامه می‌یابند. فریز BAU برای پروژه‌های با continuous delivery مناسب است، جایی که توقف کامل توسعه به مدت یک هفته از نظر اقتصادی مقرون به صرفه نیست.

همچنین مفهوم deployment freeze (فریز استقرار) وجود دارد — توقف کامل استقرار در محیط تولید که برای فصل تعطیلات (تعطیلات کریسمس، Black Friday) معمول است. در این دوره حتی هات‌فیکس‌ها نیز مسدود می‌شوند، مگر اینکه مربوط به امنیت باشند. فریز استقرار معمولاً ۱-۲ هفته طول می‌کشد و در سطح شرکت هماهنگ می‌شود.

چه زمانی فریز اعمال شود و چقدر طول بکشد

زمان مناسب برای اعمال فریز ویژگی — پس از تکمیل کد (code complete)، زمانی که تمام ویژگی‌های برنامه‌ریزی‌شده merge شده و در حال گذراندن QA هستند. مدت دقیق به چرخه انتشار بستگی دارد: برای sprint دو هفته‌ای، فریز ویژگی ۳-۴ روز قبل از تاریخ انتشار اعمال می‌شود، برای انتشار ماهانه — ۷-۱۰ روز قبل. Code freeze ۲۴-۴۸ ساعت قبل از زمان برنامه‌ریزی‌شده ساخت بیلد انتشار اعمال می‌شود.

مدت فریز باید حداقل لازم برای پایدارسازی کد باشد. فریز بیش از حد طولانی (بیش از ۲ هفته) تیم را بی‌انگیزه می‌کند و باعث انباشت ویژگی‌های merge نشده می‌شود که هر کدام پس از برداشته شدن فریز خطر تعارض را افزایش می‌دهند. فریز بیش از حد کوتاه (کمتر از ۲۴ ساعت برای فریز ویژگی) زمان کافی برای تست و رفع باگ نمی‌دهد.

روش توصیه‌شده — تعیین فریز نه بر اساس تاریخ تقویم، بلکه بر اساس وضعیت پایگاه کد. فریز ویژگی زمانی اعمال می‌شود که تعداد باگ‌های باز مربوط به انتشار از آستانه (threshold) فراتر رود (مثلاً ۱۰ باگ بحرانی). Code freeze — زمانی که بیلد با موفقیت smoke tests و regression suite را پشت سر بگذارد. Time-based freeze (تاریخ ثابت) همچنان استاندارد صنایع تنظیم‌شده (فین‌تک، مدتک) است، جایی که تاریخ انتشار توسط نهاد نظارتی تأیید شده است.

اتوماسیون فریزها از طریق CI/CD و Git

کنترل دستی فریزها منبع خطاست: توسعه‌دهنده ممکن است به طور تصادفی PR را merge کند که باید منتظر برداشتن فریز باشد. اتوماسیون این مشکل را از طریق قوانین محافظت از شاخه Git و pipelineهای CI/CD حل می‌کند. در ارائه‌دهنده Git (GitHub، GitLab، Bitbucket) قوانینی تنظیم می‌شوند که merge در شاخه انتشار را بدون برچسب خاص یا تأیید مدیر انتشار مسدود می‌کنند.

Pipeline CI/CD وضعیت فریز را قبل از ساخت بیلد بررسی می‌کند. در Jenkins، GitLab CI یا GitHub Actions مرحله‌ای اضافه می‌شود که فایل پیکربندی با زمان‌بندی فریزها را می‌خواند و در صورت قرار گرفتن تاریخ فعلی در دوره فریز، بیلدها را رد می‌کند. جایگزین — 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 "فریز ویژگی فعال است. PR مسدود شده است." && exit 1

نمونه اسکریپت freeze-check.js JSON با زمان‌بندی فریزها را از ریشه مخزن می‌خواند. اگر تاریخ فعلی در بازه بین start_date و end_date برای شاخه مشخص‌شده قرار گیرد — pipeline با پیام وضعیت فریز شکست می‌خورد. محافظت از شاخه Git یک مانع دوم اضافه می‌کند: حتی اگر pipeline کار نکند، قانون اجازه merge PR بدون تأیید را نمی‌دهد.

خطاهای رایج در پیاده‌سازی فریزها

اولین خطا — فریز بدون معیار روشن برای برداشتن. تیم کد را منجمد می‌کند اما مشخص نمی‌کند چه شرایطی باید برای رفع انجماد محقق شود: zero critical bugs، گذراندن regression suite، تأیید مدیر محصول. بدون معیار، فریز می‌تواند هفته‌ها طول بکشد. Definition of done برای فریز باید مستند شده و برای هر توسعه‌دهنده مشخص باشد.

دومین خطا — استثناهای زیاد از فریز. هر exception ("این PR یک ویژگی نیست، بلکه بدهی فنی است") مرز فریز را مخدوش می‌کند. اگر exceptions از ۲۰٪ جریان معمول PR فراتر رود — فریز کار نمی‌کند. تیم به سادگی ویژگی‌ها را به رفع باگ تغییر نام می‌دهد تا مسدودیت را دور بزند.

سومین خطا — نادیده گرفتن release candidateها. اگر تیم بیلدهای release candidate را نسازد و بلافاصله پس از code freeze در محیط تولید استقرار دهد، مفهوم فریز از بین می‌رود: باگ‌ها توسط کاربران کشف می‌شوند. Release candidate باید قبل از code freeze ساخته شود، توسط QA و در staging تست شود و تنها پس از تأیید کیفیت، code freeze اعمال شود.

چهارمین خطا — عامل انسانی در کنترل دستی. توسعه‌دهنده ممکن است فراموش کند وضعیت فریز را قبل از merge بررسی کند، مدیر انتشار — اعلان را نادیده بگیرد. تنها راه‌حل قابل اعتماد — مسدودسازی خودکار در سطح Git provider یا CI/CD که خطای انسانی را حذف می‌کند.