Hotfix Branch: วิธีการสร้างและประยุกต์ใช้ในการพัฒนาแอปมือถือ

Hotfix Branch คืออะไร?

Hotfix Branch คือ Branch ชั่วคราวใน Git ที่สร้างขึ้นเพื่อแก้ไขข้อบกพร่องร้ายแรงในระบบ Production ที่กำลังทำงานอยู่ แตกต่างจาก feature branch ที่แตกแขนงจาก develop และมีอายุหลายวันหรือหลายสัปดาห์ hotfix ถูกสร้างจาก main/master และมีอยู่ตราบเท่าที่จำเป็นในการแก้ไขบั๊กเท่านั้น

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

ตาม Google Play Console เวลาตรวจสอบอัปเดตโดยเฉลี่ยใน Google Play คือ 2 ถึง 24 ชั่วโมง สำหรับ App Store การตรวจสอบแบบเร่งด่วนอาจใช้เวลา 1 ถึง 4 ชั่วโมง Hotfix branch ช่วยให้เตรียมการแก้ไขก่อนที่การตรวจสอบจะเสร็จสิ้นและปล่อยทันทีหลังจากการอนุมัติ

Hotfix ทำงานอย่างไร

กระบวนการ hotfix ประกอบด้วยสามขั้นตอน: การสร้าง Branch จาก main, การแก้ไข และการ Merge กลับไปยัง main และ develop ความแตกต่างหลักจากการแก้ไขทั่วไปคือ hotfix จะถูก Merge ไปยังทั้งสอง Branch เสมอ เพื่อให้การแก้ไขไม่สูญหายในการปล่อยเวอร์ชันครั้งถัดไป

ทีมไม่ควรนำ ฟังก์ชันใหม่ หรือการปรับโครงสร้างโค้ดเข้าไปใน hotfix มีเพียงการแก้ไขตามเป้าหมายเท่านั้น ซึ่งจำเป็นน้อยที่สุดในการแก้ไขปัญหาที่ร้ายแรง การเบี่ยงเบนจากกฎนี้จะเพิ่มความเสี่ยงของการถดถอยและทำให้การปล่อยแพตช์ล่าช้า

เมื่อใดที่จำเป็นต้องใช้ Hotfix

Hotfix จำเป็นในสามสถานการณ์: บัคร้ายแรงบล็อกผู้ใช้ ( Crash, สูญเสียข้อมูล), ช่องโหว่ด้านความปลอดภัยที่ต้องปิดทันที หรือตรรกะทางธุรกิจที่สำคัญเสียหาย (การชำระเงิน, การยืนยันตัวตน) หากบั๊กไม่ร้ายแรง ก็สามารถแก้ไขได้ในวงจรการปล่อยเวอร์ชันปกติผ่าน develop

สำหรับแอปพลิเคชันมือถือ hotfix ยังสามารถรวม การเปลี่ยนแปลงฝั่งเซิร์ฟเวอร์ ได้หากสถาปัตยกรรมอนุญาตให้สลับฟีเจอร์จากระยะไกล (feature flags) ในกรณีนี้ hotfix branch อาจน้อยมากหรือไม่จำเป็นเลยหากสามารถแก้ไขได้ในฝั่งเซิร์ฟเวอร์

โมเดล Branching และตำแหน่งของ Hotfix

ไม่ใช่ทุก โมเดล Branching ที่รองรับ hotfix branch Git Flow แบบดั้งเดิมรวม hotfix เป็น Branch ชนิดหนึ่งที่สมบูรณ์ ในขณะที่แนวทางที่ทันสมัยกว่า (GitHub Flow, Trunk-based) จัดการกับการแก้ไขฉุกเฉินแตกต่างกัน

Git Flow และ Hotfix

Git Flow เป็นโมเดลเดียวที่ hotfix เป็น Branch ชนิดในตัวควบคู่ไปกับ feature และ release ใน Git Flow hotfix ถูกสร้างจาก main และเมื่อเสร็จสมบูรณ์จะถูก Merge ไปยังทั้ง main (พร้อมแท็กเวอร์ชัน) และ develop ซึ่งรับประกันว่าการแก้ไขจะไม่สูญหายในการปล่อยเวอร์ชันครั้งถัดไป

GitHub Flow และ Trunk-based

GitHub Flow ไม่ได้ใช้ Branch ชนิดแยกต่างหากสำหรับ hotfix แต่ผู้พัฒนาจะสร้าง feature branch ปกติจาก main ทำการแก้ไขและเปิด Pull Request หลังจากการตรวจสอบและการตรวจสอบ CI Branch จะถูก Merge ไปยัง main และ Deploy ทันที ข้อดีคือความเรียบง่าย ข้อเสียคือการไม่มีช่องทางเฉพาะสำหรับการแก้ไขเร่งด่วน

การพัฒนาแบบ Trunk-based จัดการ hotfix ผ่าน Commit โดยตรงไปยัง main (สำหรับกรณีร้ายแรง) พร้อมการตรวจสอบภายหลังที่จำเป็น แนวทางนี้ต้องการวินัยของทีมสูงและการทดสอบอัตโนมัติที่เชื่อถือได้ เนื่องจากการเปลี่ยนแปลงจะเข้าสู่ระบบ Production ทันที

วิธีสร้าง Hotfix Branch

การสร้าง hotfix เริ่มต้นด้วยการสลับไปยัง Branch หลักและสร้าง Branch ใหม่ที่มีคำนำหน้า hotfix/ มาดูกระบวนการทีละขั้นตอนด้วยตัวอย่างการแก้ไขบัคร้ายแรงในแอปพลิเคชันมือถือ

การสร้าง Branch จาก main

ขั้นตอนแรก — สลับไปยัง main และตรวจสอบให้แน่ใจว่า Branch เป็นปัจจุบัน จากนั้นสร้าง hotfix branch ด้วยชื่อที่ชัดเจนซึ่งสะท้อนถึงลักษณะของการแก้ไข

# สลับไปยัง main และรับการเปลี่ยนแปลงล่าสุด
git checkout main
git pull origin main

# สร้าง hotfix branch
git checkout -b hotfix/crash-on-login

หลังจากสร้าง Branch แล้ว คุณสามารถดำเนินการ แก้ไข สิ่งสำคัญที่ต้องจำ: hotfix ควรมีการเปลี่ยนแปลงจำนวนน้อยที่สุด อย่าปรับโครงสร้างโค้ดหรือเพิ่มฟีเจอร์ใหม่ — มีเพียงการแก้ไขตามเป้าหมายที่แก้ปัญหา

การ Commit การแก้ไข

Commit ใน hotfix ควรมีข้อความที่ให้ข้อมูลซึ่งอธิบายปัญหาและแนวทางแก้ไขอย่างชัดเจน รูปแบบ: ประเภท(ขอบเขต): คำอธิบายสั้น + ลิงก์ไปยังงานใน Tracker

# เพิ่มไฟล์ที่เปลี่ยนแปลง
git add src/ui/login/LoginActivity.kt

# สร้าง commit พร้อมคำอธิบาย
git commit -m "fix(login): handle null intent on activity resume

Fixes CRASH-142: NullPointerException when LoginActivity
receives onNewIntent after being destroyed by system"

ข้อความ Commit ควรมี คำอธิบายปัญหา และลิงก์ไปยังงาน ซึ่งช่วยให้การค้นหาในประวัติง่ายขึ้นและช่วยให้เพื่อนร่วมงานเข้าใจสิ่งที่ได้รับการแก้ไขและเพราะเหตุใด สำหรับโครงการมือถือ มักจะรวมเวอร์ชันของแอปพลิเคชันที่พบบั๊กด้วย

การ Merge ไปยัง main และ develop

ขั้นตอนสุดท้าย คือการ Merge hotfix กลับไปยัง main (พร้อมแท็กเวอร์ชันแพตช์ใหม่) และ develop (เพื่อให้การแก้ไขคงอยู่ในการปล่อยเวอร์ชันครั้งถัดไป) ขั้นแรก Merge ใน main ด้วยแท็ก จากนั้น Merge ใน develop

# Merge ใน main และสร้างแท็ก
git checkout main
git merge --no-ff hotfix/crash-on-login
git tag -a v2.3.1 -m "Hotfix: crash on login"

# Merge ใน develop
git checkout develop
git merge --no-ff hotfix/crash-on-login

# ส่งการเปลี่ยนแปลงไปยังเซิร์ฟเวอร์
git push origin main --tags
git push origin develop

แฟล็ก --no-ff รับประกันว่าจะสร้าง Merge Commit แม้ว่า hotfix สามารถนำไปใช้ผ่าน Fast-Forward ได้ก็ตาม ซึ่งจะเก็บข้อมูลว่ามีการแก้ไขฉุกเฉินเกิดขึ้นและช่วยให้การวิเคราะห์ประวัติในอนาคตง่ายขึ้น

ความแตกต่างระหว่าง Hotfix, Feature และ Release

Hotfix แตกต่างโดยพื้นฐานจาก feature และ release branch ในด้านวัตถุประสงค์ อายุการใช้งาน และกฎการ Merge การเข้าใจความแตกต่างเหล่านี้เป็นสิ่งสำคัญสำหรับการจัดระเบียบกระบวนการ Git ในทีมอย่างถูกต้อง

Feature branch มีไว้สำหรับ ฟังก์ชันใหม่ มีอายุตั้งแต่หลายวันถึงหลายสัปดาห์ สร้างจาก develop และ Merge กลับไปยัง develop Feature อาจมีหลาย Commit รวมถึงการทดลอง ซึ่งต่อมาถูกบีบอัดผ่าน Squash หรือ Rebase

Release branch เตรียม เวอร์ชันสำหรับการปรับใช้ มันถูกสร้างจาก develop แก้ไขบั๊กที่พบระหว่างการทำให้เสถียร และไม่รับฟังก์ชันใหม่ เมื่อเสร็จสมบูรณ์ release จะถูก Merge ไปยัง main (พร้อมแท็ก) และ develop

Hotfix ในทางกลับกัน ถูกสร้างและ Merge โดยตรงกับ main โดยข้าม develop (แม้ว่าหลังจากแก้ไขแล้วจะซิงค์กับ develop ด้วย) มีการเปลี่ยนแปลงจำนวนน้อยที่สุดและมีอายุน้อยที่สุด ในขณะที่ feature หรือ release branch สามารถเลื่อนไปยังรอบถัดไปได้ hotfix ไม่สามารถเลื่อนได้

สำหรับการพัฒนาแอปมือถือ ความแตกต่างนี้สำคัญเป็นพิเศษ: App Store และ Google Play อนุญาตให้ปล่อยเวอร์ชันแพตช์แยกต่างหากจากการปล่อยเวอร์ชันหลัก Hotfix branch รับประกันว่าการปล่อยแพตช์จะไม่ปะปนกับฟีเจอร์ที่ยังไม่เสร็จ

ข้อผิดพลาดทั่วไปเมื่อทำงานกับ Hotfix

ข้อผิดพลาด เมื่อทำงานกับ hotfix สามารถลบล้างข้อดีของการแก้ไขฉุกเฉินได้ มาดูปัญหาทั่วไปห้าประการที่เกิดขึ้นในทีมที่ใช้ Git Flow

• การสร้าง hotfix จาก develop — หาก hotfix ถูกสร้างจาก develop ฟีเจอร์ที่ยังไม่เสร็จอาจเข้าไปในแพตช์ Hotfix ควรสร้างจาก main เท่านั้นเพื่อรับประกันว่าเฉพาะโค้ดที่เสถียรเท่านั้นที่รวมอยู่ในการแก้ไข
• การแก้ไขหลายรายการใน hotfix เดียว — การแก้ไขแต่ละรายการควรอยู่ใน hotfix branch ของตนเอง การผสมบั๊กหลายตัวใน Branch เดียวทำให้การตรวจสอบโค้ดซับซ้อน เพิ่มความเสี่ยงของการถดถอย และทำให้การย้อนกลับทำได้ยากหากจำเป็น
• การข้าม Merge ไปยัง develop — หาก hotfix ไม่ได้ Merge ไปยัง develop การแก้ไขจะสูญหายในการปล่อยเวอร์ชันครั้งถัดไป ทีมจะพบว่าบั๊กเดียวกันปรากฏขึ้นอีกครั้งและจะต้องแก้ไขอีกครั้ง
• แท็กเวอร์ชันไม่ถูกต้อง — hotfix ควรได้รับการเพิ่มเวอร์ชันแบบแพตช์ (v2.3.0 → v2.3.1) ไม่ใช่แบบไมเนอร์ (v2.4.0) หรือเมเจอร์ (v3.0.0) การละเมิด Semantic Versioning จะทำให้ระบบ Build เสียหายและทำให้ผู้ใช้สับสน
• ขาดการตรวจสอบ CI — แม้แต่ hotfix ฉุกเฉินก็ต้องผ่านการทดสอบอัตโนมัติ การข้าม CI จะเพิ่มความเสี่ยงในการนำข้อผิดพลาดใหม่เข้ามา ขอแนะนำให้มี Pipeline แยกต่างหากสำหรับ hotfix branch พร้อมการตรวจสอบแบบเร่งด่วน

แต่ละ ข้อผิดพลาด เหล่านี้นำไปสู่ความล่าช้าในการปล่อยแพตช์หรือการเกิดปัญหาใหม่ในระบบ Production ทีมควรบันทึกกฎการทำงานกับ hotfix ใน CONTRIBUTING.md และทำให้เป็นอัตโนมัติผ่านการตรวจสอบ CI/CD