Feature freeze और Code freeze एप्लिकेशन डेवलपमेंट में: सार, अंतर और भूमिका

Feature freeze क्या है?

Feature freeze नियोजित रिलीज़ से पहले कोडबेस में नई कार्यक्षमता जोड़ने पर एक अस्थायी प्रतिबंध है। टीम फ़ीचर मर्ज करना बंद कर देती है और बग फ़िक्स, ऑप्टिमाइज़ेशन और मौजूदा कोड को पॉलिश करने पर स्विच करती है। डेवलपर अधूरे फ़ीचर को केवल बगफ़िक्स के दायरे में पूरा करते हैं, स्कोप का विस्तार किए बिना।

Feature freeze कार्य-प्रगति (work-in-progress) फ़ीचर की समस्या को हल करता है जो रिलीज़ तक नहीं पहुँचते लेकिन पहले से ही मुख्य ब्रांच में आंशिक रूप से मर्ज हो चुके होते हैं। यदि नए फ़ीचर मर्ज होते रहते हैं, तो रिग्रेशन का जोखिम बढ़ता है: प्रत्येक नए इंटीग्रेशन में पहले से तैयार मॉड्यूल का पुनः परीक्षण आवश्यक होता है। Feature freeze रिलीज़ के स्कोप को फ़िक्स करता है, इसे एक चलते लक्ष्य से कार्यक्षमता के एक स्थिर सेट में बदल देता है।

एक महत्वपूर्ण स्पष्टीकरण: feature freeze ≠ code freeze। Feature freeze के दौरान, बग फ़िक्स, रिफ़ैक्टरिंग, डिपेंडेंसी अपडेट और डॉक्यूमेंटेशन की अनुमति है। केवल नई user-facing सुविधाएँ प्रतिबंधित हैं — कोई भी कोड जो उपयोगकर्ता के दृष्टिकोण से एप्लिकेशन के व्यवहार को बदलता है। कोड रिव्यू जाँच: यदि PR एक नई स्क्रीन, बटन या API विधि जोड़ता है — तो इसे फ़्रीज़ हटने तक अस्वीकार कर दिया जाता है।

Code freeze क्या है और यह feature freeze से कैसे अलग है

Code freeze एक अधिक सख्त प्रथा है जिसमें कोड में सभी बदलाव पूरी तरह से प्रतिबंधित होते हैं। बग फ़िक्स भी तब तक अनुमति नहीं है जब तक वे महत्वपूर्ण न हों। Code freeze एक छोटी अवधि (आमतौर पर 24-48 घंटे) के लिए लागू किया जाता है और गारंटी देता है कि रिलीज़ बिल्ड कमिट के एक निश्चित सेट से बनाया गया है।

Feature freeze और code freeze के बीच अंतर नियंत्रण के स्तर में है। Feature freeze स्कोप प्रबंधित करता है: रिलीज़ में वास्तव में क्या शामिल होगा। Code freeze गुणवत्ता प्रबंधित करता है: रिलीज़ से एक दिन पहले एक नया बग पेश करने के जोखिम को समाप्त करता है। व्यवहार में, कई टीमें दो-चरणीय मॉडल का उपयोग करती हैं: रिलीज़ से 1-2 सप्ताह पहले — feature freeze, 24-48 घंटे पहले — code freeze। Code freeze विशेष रूप से मोबाइल एप्लिकेशन के लिए प्रासंगिक है, जहाँ नियोजित रिलीज़ तिथि से कई दिन पहले बिल्ड को स्टोर पर अपलोड करना आवश्यक होता है।

Code freeze का अपवाद महत्वपूर्ण कमजोरियों (CVE स्कोर 9+) के लिए सुरक्षा फ़िक्स है। ऐसे बदलाव अनिवार्य फ़ास्ट-ट्रैक कोड रिव्यू और टीम सूचना के साथ आपातकालीन प्रक्रिया से गुजरते हैं। अन्य सभी बदलाव अगले रिलीज़ चक्र तक स्थगित कर दिए जाते हैं।

Feature freeze बनाम code freeze: तुलना

Feature freeze और code freeze के बीच चयन टीम की परिपक्वता और रिलीज़ आवृत्ति पर निर्भर करता है। CI/CD और फ़ीचर फ़्लैग वाली टीमों को केवल 24 घंटे के code freeze की आवश्यकता हो सकती है, जबकि मासिक रिलीज़ वाली टीमें अक्सर दोनों फ़्रीज़ का क्रमिक रूप से उपयोग करती हैं।

फ़्रीज़ के प्रकार: पूर्ण, आंशिक और BAU-फ़्रीज़

पूर्ण feature freeze और code freeze के अलावा, अधिक लचीले विकल्प मौजूद हैं। आंशिक feature freeze केवल कुछ मॉड्यूल में नई कार्यक्षमता को ब्लॉक करता है — उदाहरण के लिए, भुगतान मॉड्यूल या प्राधिकरण मॉड्यूल में, अन्य घटकों को बदलावों के लिए खुला छोड़ता है।

BAU-फ़्रीज़ (business as usual freeze) एक समझौता विकल्प है जिसमें केवल बड़े फ़ीचर जिनका परिवर्तन आकार एक निश्चित सीमा (जैसे, 500 कोड लाइन) से अधिक है, प्रतिबंधित होते हैं। छोटे सुधार, UI ट्वीक और बग फ़िक्स मर्ज होते रहते हैं। BAU-फ़्रीज़ निरंतर डिलीवरी वाली परियोजनाओं के लिए सुविधाजनक है, जहाँ एक सप्ताह का पूर्ण विकास ठहराव आर्थिक रूप से लाभदायक नहीं है।

डिप्लॉयमेंट फ़्रीज़ (deployment freeze) की भी अवधारणा है — प्रोडक्शन पर डिप्लॉयमेंट का पूर्ण ठहराव, जो छुट्टियों के मौसम (क्रिसमस छुट्टियाँ, ब्लैक फ़्राइडे) की विशेषता है। इस अवधि के दौरान, हॉटफ़िक्स भी तब तक ब्लॉक किए जाते हैं जब तक वे सुरक्षा से संबंधित न हों। डिप्लॉयमेंट फ़्रीज़ आमतौर पर 1-2 सप्ताह तक रहता है और कंपनी स्तर पर समन्वित होता है।

फ़्रीज़ कब शुरू करें और यह कितने समय तक चलता है

Feature freeze शुरू करने का इष्टतम समय कोड पूर्ण होने के बाद है, जब सभी नियोजित फ़ीचर मर्ज हो चुके हैं और QA से गुजर रहे हैं। सटीक समय रिलीज़ चक्र पर निर्भर करता है: दो-सप्ताह के स्प्रिंट के लिए, feature freeze रिलीज़ तिथि से 3-4 दिन पहले शुरू किया जाता है; मासिक रिलीज़ के लिए, 7-10 दिन पहले। Code freeze नियोजित रिलीज़ बिल्ड समय से 24-48 घंटे पहले शुरू किया जाता है।

फ़्रीज़ की अवधि कोड को स्थिर करने के लिए न्यूनतम पर्याप्त होनी चाहिए। बहुत लंबा फ़्रीज़ (2 सप्ताह से अधिक) टीम को हतोत्साहित करता है और अमर्जित फ़ीचर का संचय बनाता है, जिनमें से प्रत्येक फ़्रीज़ हटने के बाद विरोधों का जोखिम बढ़ाता है। बहुत छोटा फ़्रीज़ (feature freeze के लिए 24 घंटे से कम) पूरी तरह से परीक्षण और फ़िक्स के लिए पर्याप्त समय नहीं देता।

अनुशंसित प्रथा कैलेंडर तिथि के बजाय कोडबेस स्थिति द्वारा फ़्रीज़ सेट करना है। Feature freeze तब शुरू किया जाता है जब रिलीज़ के लिए खुले बगों की संख्या एक सीमा (जैसे, 10 महत्वपूर्ण बग) से अधिक हो जाती है। Code freeze — जब बिल्ड स्मोक टेस्ट और रिग्रेशन सूट को सफलतापूर्वक पार कर जाता है। समय-आधारित फ़्रीज़ (निश्चित तिथि) विनियमित उद्योगों (फ़िनटेक, मेडटेक) के लिए मानक बना हुआ है जहाँ रिलीज़ तिथि नियामक द्वारा अनुमोदित होती है।

CI/CD और Git के माध्यम से फ़्रीज़ का ऑटोमेशन

मैन्युअल फ़्रीज़ नियंत्रण त्रुटियों का स्रोत है: एक डेवलपर गलती से उस PR को मर्ज कर सकता है जिसे फ़्रीज़ हटने तक प्रतीक्षा करनी चाहिए। ऑटोमेशन Git ब्रांच प्रोटेक्शन नियमों और CI/CD पाइपलाइनों के माध्यम से इसे हल करता है। Git प्रदाता (GitHub, GitLab, Bitbucket) में, नियम कॉन्फ़िगर किए जाते हैं जो विशेष टैग या रिलीज़ मैनेजर की अनुमति के बिना रिलीज़ ब्रांच में मर्ज को ब्लॉक करते हैं।

CI/CD पाइपलाइन बिल्ड बनाने से पहले फ़्रीज़ स्थिति की जाँच करती है। Jenkins, GitLab CI या GitHub Actions में, एक स्टेप जोड़ा जाता है जो फ़्रीज़ शेड्यूल के साथ एक कॉन्फ़िगरेशन फ़ाइल पढ़ता है और यदि वर्तमान तिथि फ़्रीज़ अवधि में आती है तो बिल्ड को अस्वीकार करता है। एक विकल्प एडमिन पैनल में एक फ़ीचर फ़्लैग है जो प्रोडक्शन पर डिप्लॉयमेंट को ब्लॉक करता है।

# .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 is active. PR blocked." && exit 1

उदाहरण freeze-check.js स्क्रिप्ट रिपॉजिटरी रूट से फ़्रीज़ शेड्यूल के साथ एक JSON पढ़ती है। यदि वर्तमान तिथि निर्दिष्ट ब्रांच के लिए start_date और end_date के बीच आती है, तो पाइपलाइन फ़्रीज़ स्थिति संदेश के साथ विफल हो जाती है। Git ब्रांच प्रोटेक्शन एक दूसरी बाधा जोड़ता है: भले ही पाइपलाइन चालू न हुई हो, नियम अनुमति के बिना PR को मर्ज करने की अनुमति नहीं देगा।

फ़्रीज़ लागू करते समय सामान्य गलतियाँ

पहली गलती स्पष्ट हटाने के मानदंड के बिना फ़्रीज़ है। टीम कोड फ़्रीज़ करती है लेकिन यह परिभाषित नहीं करती कि अनफ़्रीज़ करने के लिए किन शर्तों को पूरा किया जाना चाहिए: शून्य महत्वपूर्ण बग, रिग्रेशन सूट पारित, उत्पाद प्रबंधक अनुमोदन। मानदंड के बिना, फ़्रीज़ हफ्तों तक चल सकता है। फ़्रीज़ के लिए पूर्णता की परिभाषा दस्तावेज़ीकृत और प्रत्येक डेवलपर को ज्ञात होनी चाहिए।

दूसरी गलती फ़्रीज़ में बहुत अधिक अपवाद हैं। प्रत्येक अपवाद (“यह PR कोई फ़ीचर नहीं है, यह तकनीकी ऋण है”) फ़्रीज़ की सीमा को धुंधला करता है। यदि अपवाद सामान्य PR प्रवाह के 20% से अधिक हैं, तो फ़्रीज़ काम नहीं करता। टीम ब्लॉक को बायपास करने के लिए फ़ीचर को बग फ़िक्स के रूप में पुनः नामित करती है।

तीसरी गलती रिलीज़ कैंडिडेट को अनदेखा करना है। यदि टीम रिलीज़ कैंडिडेट बिल्ड नहीं बनाती और code freeze के बाद सीधे प्रोडक्शन पर डिप्लॉय करती है, तो फ़्रीज़ का उद्देश्य खो जाता है: बग उपयोगकर्ताओं द्वारा खोजे जाते हैं। रिलीज़ कैंडिडेट को code freeze से पहले बनाया जाना चाहिए, QA और स्टेजिंग पर परीक्षण किया जाना चाहिए, और केवल गुणवत्ता की पुष्टि के बाद code freeze शुरू किया जाना चाहिए।

चौथी गलती मैन्युअल नियंत्रण में मानवीय कारक है। एक डेवलपर मर्ज से पहले फ़्रीज़ स्थिति की जाँच करना भूल सकता है, एक रिलीज़ मैनेजर सूचना से चूक सकता है। एकमात्र विश्वसनीय समाधान Git प्रदाता या CI/CD स्तर पर स्वचालित ब्लॉकिंग है, जो मानवीय त्रुटि को समाप्त करता है।