Feature freeze และ code freeze ในการพัฒนาแอปพลิเคชัน: สาระสำคัญ ความแตกต่าง และบทบาท

Feature freeze คืออะไร?

Feature freeze คือการห้ามชั่วคราวในการเพิ่มฟังก์ชันการทำงานใหม่ลงในฐานโค้ด ซึ่งนำมาใช้ก่อนการเผยแพร่ตามแผน ทีมหยุดรวมฟีเจอร์และหันไปแก้ไขข้อบกพร่อง ปรับปรุงประสิทธิภาพ และขัดเกลาโค้ดที่มีอยู่ นักพัฒนาทำฟีเจอร์ที่ไม่สมบูรณ์ให้เสร็จเฉพาะในขอบเขตของการแก้ไขข้อบกพร่องเท่านั้น โดยไม่ขยายขอบเขต

Feature freeze แก้ปัญหาฟีเจอร์ที่กำลังดำเนินการ (work-in-progress) ซึ่งไม่ทันการเผยแพร่แต่ได้ถูกรวมเข้ากับสาขาหลักบางส่วนแล้ว หากยังคงรวมฟีเจอร์ใหม่ต่อไป ความเสี่ยงของการถดถอยจะเพิ่มขึ้น: การรวมแต่ละครั้งจำเป็นต้องทดสอบโมดูลที่เสร็จแล้วซ้ำ Feature freeze กำหนดขอบเขตของการเผยแพร่ เปลี่ยนจากเป้าหมายที่เคลื่อนที่ไปเป็นชุดฟังก์ชันการทำงานที่เสถียร

คำชี้แจงที่สำคัญ: feature freeze ≠ code freeze ระหว่าง feature freeze อนุญาตให้แก้ไขข้อบกพร่อง ปรับโครงสร้าง อัปเดต dependencies และเอกสารประกอบ ห้ามเฉพาะฟีเจอร์ใหม่ที่ผู้ใช้มองเห็นเท่านั้น — โค้ดใดๆ ที่เปลี่ยนพฤติกรรมของแอปพลิเคชันจากมุมมองของผู้ใช้ การตรวจสอบในการตรวจสอบโค้ด: หาก 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 และ feature flags อาจต้องการเพียง code freeze 24 ชั่วโมง ในขณะที่ทีมที่เผยแพร่รายเดือนมักใช้การแช่แข็งทั้งสองแบบตามลำดับ

ประเภทของการแช่แข็ง: เต็มรูปแบบ บางส่วน และ BAU-freeze

นอกจากการแช่แข็งฟีเจอร์เต็มรูปแบบและ code freeze แล้ว ยังมีตัวเลือกที่ยืดหยุ่นกว่า การแช่แข็งบางส่วน ปิดกั้นฟังก์ชันการทำงานใหม่เฉพาะในโมดูลที่กำหนด — ตัวอย่างเช่น ในโมดูลการชำระเงินหรือโมดูลการอนุญาต โดยปล่อยให้ส่วนประกอบอื่นๆ เปิดให้เปลี่ยนแปลง

BAU-freeze (business as usual freeze) เป็นตัวเลือกประนีประนอมซึ่งห้ามเฉพาะฟีเจอร์ใหญ่ที่มีปริมาณการเปลี่ยนแปลงเกินเกณฑ์ที่กำหนด (เช่น 500 บรรทัดของโค้ด) การปรับปรุงเล็กน้อย การปรับแต่ง UI และการแก้ไขข้อบกพร่องยังคงถูกรวมต่อไป BAU-freeze สะดวกสำหรับโครงการที่มีการส่งมอบอย่างต่อเนื่อง ซึ่งการหยุดพัฒนาเต็มรูปแบบเป็นเวลาหนึ่งสัปดาห์ไม่คุ้มค่าทางเศรษฐกิจ

นอกจากนี้ยังมีแนวคิดของการแช่แข็งการปรับใช้ (deployment freeze) — การหยุดการปรับใช้ทั้งหมดไปยังระบบจริงโดยสมบูรณ์ ซึ่งเป็นลักษณะเฉพาะของช่วงเทศกาล (วันหยุดคริสต์มาส, Black Friday) ในช่วงเวลานี้ แม้แต่ hotfixes ก็ถูกปิดกั้นเว้นแต่เกี่ยวข้องกับความปลอดภัย การแช่แข็งการปรับใช้มักกินเวลา 1-2 สัปดาห์และประสานงานในระดับบริษัท

เมื่อใดควรเริ่มการแช่แข็งและนานเท่าใด

เวลาที่เหมาะสมที่สุดในการเริ่ม feature freeze คือหลังจากโค้ดเสร็จสมบูรณ์ เมื่อฟีเจอร์ที่วางแผนไว้ทั้งหมดถูกรวมและอยู่ระหว่างการประกันคุณภาพ เวลาที่แน่นอนขึ้นอยู่กับรอบการเผยแพร่: สำหรับ sprint สองสัปดาห์ feature freeze จะเริ่ม 3-4 วันก่อนวันที่เผยแพร่; สำหรับการเผยแพร่รายเดือน 7-10 วันก่อน Code freeze จะเริ่ม 24-48 ชั่วโมงก่อนเวลาสร้างบิลด์สำหรับเผยแพร่ตามแผน

ระยะเวลาของการแช่แข็งควรเป็นขั้นต่ำที่เพียงพอสำหรับการรักษาเสถียรภาพของโค้ด การแช่แข็งที่นานเกินไป (มากกว่า 2 สัปดาห์) ทำให้ทีมหมดกำลังใจและสร้างการสะสมของฟีเจอร์ที่ไม่ได้รวม ซึ่งแต่ละฟีเจอร์เพิ่มความเสี่ยงของความขัดแย้งหลังจากยกเลิกการแช่แข็ง การแช่แข็งที่สั้นเกินไป (น้อยกว่า 24 ชั่วโมงสำหรับ feature freeze) ไม่ให้เวลาเพียงพอสำหรับการทดสอบและการแก้ไขอย่างละเอียด

แนวปฏิบัติที่แนะนำคือกำหนดการแช่แข็งไม่ตามวันที่ในปฏิทินแต่ตามสถานะของฐานโค้ด Feature freeze จะเริ่มเมื่อจำนวนข้อบกพร่องที่เปิดสำหรับการเผยแพร่เกินเกณฑ์ (เช่น 10 ข้อบกพร่องสำคัญ) Code freeze — เมื่อบิลด์ผ่านการทดสอบ smoke tests และชุดการทดสอบการถดถอย การแช่แข็งตามเวลา (วันที่คงที่) ยังคงเป็นมาตรฐานสำหรับอุตสาหกรรมที่มีการควบคุม (ฟินเทค, เมดเทค) ที่วันที่เผยแพร่ได้รับการอนุมัติจากหน่วยงานกำกับดูแล

ระบบอัตโนมัติของการแช่แข็งผ่าน CI/CD และ Git

การควบคุมการแช่แข็งด้วยตนเองเป็นแหล่งของข้อผิดพลาด: นักพัฒนาอาจรวม PR โดยไม่ตั้งใจซึ่งควรรอจนกว่าจะยกเลิกการแช่แข็ง ระบบอัตโนมัติแก้ปัญหานี้ผ่านกฎการป้องกันสาขาของ Git และไปป์ไลน์ CI/CD ในผู้ให้บริการ Git (GitHub, GitLab, Bitbucket) มีการกำหนดกฎที่ปิดกั้นการรวมในสาขาเผยแพร่โดยไม่มีแท็กพิเศษหรือการอนุมัติจากผู้จัดการเผยแพร่

ไปป์ไลน์ 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 "Feature freeze is active. PR blocked." && exit 1

สคริปต์ตัวอย่าง freeze-check.js อ่าน JSON พร้อมตารางการแช่แข็งจากรากของที่เก็บ หากวันที่ปัจจุบันอยู่ในช่วงระหว่าง start_date และ end_date สำหรับสาขาที่ระบุ ไปป์ไลน์จะล้มเหลวพร้อมข้อความสถานะการแช่แข็ง การป้องกันสาขาของ Git เพิ่มสิ่งกีดขวางที่สอง: แม้ว่าไปป์ไลน์จะไม่ถูกเรียกใช้ กฎจะไม่อนุญาตให้รวม PR โดยไม่ได้รับการอนุมัติ

ข้อผิดพลาดทั่วไปเมื่อนำการแช่แข็งมาใช้

ข้อผิดพลาดแรกคือการแช่แข็งโดยไม่มีเกณฑ์การยกเลิกที่ชัดเจน ทีมแช่แข็งโค้ดแต่ไม่ได้กำหนดเงื่อนไขที่ต้องทำให้สำเร็จเพื่อยกเลิกการแช่แข็ง: ข้อบกพร่องสำคัญเป็นศูนย์, ชุดทดสอบการถดถอยผ่าน, การอนุมัติจากผู้จัดการผลิตภัณฑ์ หากไม่มีเกณฑ์ การแช่แข็งอาจยืดเยื้อเป็นสัปดาห์ คำจำกัดความของความสำเร็จ สำหรับการแช่แข็งควรได้รับการบันทึกและเป็นที่รู้จักของนักพัฒนาทุกคน

ข้อผิดพลาดที่สองคือข้อยกเว้นมากเกินไปจากการแช่แข็ง ข้อยกเว้นแต่ละครั้ง (“PR นี้ไม่ใช่ฟีเจอร์ แต่เป็นหนี้ทางเทคนิค”) ทำให้ขอบเขตของการแช่แข็งไม่ชัดเจน หากข้อยกเว้นเกิน 20% ของการไหลของ PR ปกติ การแช่แข็งจะไม่ทำงาน ทีมเพียงแค่เปลี่ยนชื่อฟีเจอร์เป็นการแก้ไขข้อบกพร่องเพื่อเลี่ยงการปิดกั้น

ข้อผิดพลาดที่สามคือการละเลยตัวเลือกรุ่นก่อนเผยแพร่ หากทีมไม่สร้างบิลด์ตัวเลือกรุ่นก่อนเผยแพร่และปรับใช้กับระบบจริงโดยตรงหลังจาก code freeze จุดประสงค์ของการแช่แข็งจะสูญหายไป: ผู้ใช้จะพบข้อบกพร่อง ตัวเลือกรุ่นก่อนเผยแพร่ ควรถูกสร้างขึ้นก่อน code freeze ทดสอบโดยฝ่ายประกันคุณภาพและบนระบบ staging และหลังจากยืนยันคุณภาพแล้วจึงค่อยเริ่ม code freeze

ข้อผิดพลาดที่สี่คือปัจจัยมนุษย์ในการควบคุมด้วยตนเอง นักพัฒนาอาจลืมตรวจสอบสถานะการแช่แข็งก่อนรวม ผู้จัดการเผยแพร่อาจพลาดการแจ้งเตือน วิธีแก้ปัญหาที่เชื่อถือได้เพียงอย่างเดียวคือการปิดกั้นอัตโนมัติในระดับผู้ให้บริการ Git หรือ CI/CD ซึ่งกำจัดข้อผิดพลาดของมนุษย์