บทความ IT เจ๋งๆ

ปัจจุบัน Git ดูเหมือนจะเป็นสิ่งที่จำเป็นในการทำงานของ Developer ไปเสียแล้ว และในบทความนี้ จะมาแนะนำ Git Branching Strategy ที่มีประสิทธิภาพ ที่ Developer ควรรู้จักไว้

Branching Strategy คืออะไร

• คุณควรแตก Feature Branch ของคุณ จาก Branch ใด
• หลังจากเขียน Code เสร็จแล้ว คุณควรเพิ่ม MR(Merge Request) / PR(Pull Request) ใน Branch ใด เพื่อการ Review และการ Test Code
• หลังจากเสร็จสิ้นการ Test และการ Review แล้ว Feature Branch นั้นควรถูก Merge เข้ากับ Branch ใด

ทำไมมันถึงได้มีความสำคัญ

• Branch ที่คุณกำลังแตกออกจาก Feature Branch ของคุณ ควรมีความเสถียรในส่วนของ Production
• คุณไม่ควร Merge Code ที่มี Bug หรือ Code ที่ยังไม่ได้ Test เข้ากับ Production Branch (ที่จะ Go Live)
• ในขณะที่กำลัง Merge Code ของคุณไปยัง Production คุณควรพบ Conflicts ในการ Merge ให้น้อยที่สุดหรือไม่พบเลย

จุดประสงค์ของ Branching Strategy ก็เพื่อเพิ่มความเสถียรของ Code, ประสิทธิภาพการทำงานของ Developer และหลีกเลี่ยง Conflicts ที่ไม่จำเป็น

ในบทความนี้จะไม่กล่าวถึง Branching Strategy ทุกประเภท แต่จะแสดง Strategy ที่ดีที่สุดและมีการใช้มากที่สุด

และ Master, Develop รวมทั้ง Feature Branch จะถูกใช้ในกรณีนี้

Master

• เราสามารถเรียกมันว่า Production Branch ก็ได้ โดย Code ที่ผ่านการ Test และมีความเสถียรดีแล้วจะอยู่ที่นี่
• Release ล่าสุด ควรจะออกไปจาก Branch นี้ และ Release ถัดไปควรจะเข้ามาที่นี่
• เราสามารถมี Pipelines สำหรับการ Release Branch นี้ (เช่น เมื่อใดก็ตามที่ Branch นี้ พบการ Merge ใหม่ ที่ Pipelines จะทำการ Build และ Roll Out Software ไปยัง Production Servers ของเราโดยอัตโนมัติ)
• มันควรยอมรับเฉพาะการ Merge จาก Develop Branch เท่านั้น

Develop

• Branch ที่อยู่ใน Level ที่ต่ำกว่า Master (แตกออกจาก Master)
• Developer ที่เริ่มทำงานเกี่ยวกับ Feature ก็จะแตก Branch ใหม่ ออกจาก Branch นี้
• หลังการ Develop / Test / Review Code เสร็จแล้ว ก็จะทำการ MR ไปยัง Branch เดียวกัน เนื่องจากมันเป็น Branch ที่กำลังจะถูก Release ในการ Release ครั้งถัดไป
• และในช่วงเวลาของการ Release นั้น การ Merge จาก Branch นี้จะไปยัง Master Branch และ Master ก็เป็น Branch หนึ่งที่ถูก Release

Feature

• Branch ที่ถูกแตกออกจาก Develop Branch โดยมีการทำงานที่เกี่ยวกับ Feature ซึ่งถูกวางแผนไว้ในการ Release ครั้งถัดไป
• โดยทั่วไปจะมี Developer คนเดียว ที่ทำงานใน Feature Branch

การมี Branch ทั้ง 3 ประเภทนี้ จะช่วยหลีกเลี่ยง Conflicts ที่ไม่จำเป็น และช่วยเพิ่ม Productivity ของทีมอีกด้วย

QA Testing

คำถามที่น่าสนใจก็คือ QA Testing ควรจะทำใน Branch ใด? กล่าวอีกนัยหนึ่งคือ Branch ใด ที่ควรถูก Deploy ไปยัง QA Environment

แนวทางที่ง่ายที่สุด ก็คือ การมี QA Environment จาก Develop Branch (เช่น QA Server จะถูก Deploy ด้วย Trigger ที่สร้างขึ้นจาก Develop Branch) และหลังจากมีการยืนยันเกี่ยวกับ QA เสร็จเรียบร้อยแล้ว ถึงจะสามารถทำการ MR / PR ไปยัง Master Branch ได้

Two-branch strategy

ข้อดี

• ก่อนที่จะ Release ทุก ๆ การเปลี่ยนแปลงสามารถถูก Test ได้ผ่านการ Build /การ Deploy เพียงครั้งเดียว (เช่น การ Test  Feature แต่ละรายการ สามารถทำได้ในคราวเดียวสำหรับ Features ทั้งหมด)
• หลังจากการ Test Feature แล้ว Branch นี้ จะเป็น Branch ที่ดีที่สุดที่จะมี Regression Test เนื่องจากการเปลี่ยนแปลงใน Branch นี้ ได้ถูกวางแผนสำหรับการ Release ครั้งถัดไป

ข้อเสีย

• หากมี Bug เกิดขึ้นในการเปลี่ยนแปลงของหนึ่งใน Feature Branch จากนั้น QA Testing จะถูก Block และจะทำให้ Bandwidth โดยรวมของทีม เสียไป

Solutions

Solution ที่ 1:

รอให้เจ้าของ Feature แก้ไขปัญหาก่อน แล้วค่อย Merge มันเข้ากับ Develop Branch จากนั้น Deploy มันไปยัง QA อีกครั้ง แล้วดำเนินการ Test ต่อไป แต่วิธีนี้อาจไม่สามารถทำได้ เนื่องจากเราไม่แน่ใจเกี่ยวกับเวลาที่จะใช้ในการแก้ไข Bug ที่เกิดขึ้น

• นอกจากนี้ QA Bandwidth ก็กำลังจะสูญเสียไป
• Release Blocker ในกรณีที่ Release สามารถดำเนอนต่อไปได้แม้ไม่มี Feature นั้น
• ในกรณีที่ QA ยังคงพบ Bugs ใน Features ต่าง ๆ ก็สามารถทำซ้ำ ๆ ไปมาได้

Solution ที่ 2:

ยกเลิกการเปลี่ยนแปลงของ Feature นั้น แล้วทำการ Test ต่อไป วิธีนี้จะดีกว่าในแง่ของ Productivity โดยรวมของทีม แต่เจ้าของ Feature อาจลำบากมากขึ้น หากพวกเขายกเลิกการเปลี่ยนแปลง มันจะสร้าง Commit ใหม่โดยจะคืนค่าการเปลี่ยนแปลงทั้งหมดใน Branch นั้น และหากพวกเขาพยายามที่จะ Merge กลับเข้าด้วยกันหลังจากแก้ไขแล้ว Git ก็จะพิจารณาว่า เฉพาะ Commit ใหม่ที่ถูก Fix แล้วเท่านั้นถึงจะถูก Merge ไปยัง Develop เนื่องจาก Commit เก่าก่อนหน้านี้ มีอยู่แล้วใน Commit History ของ Develop Branch

ดังนั้น เพื่อแก้ปัญหานี้  Developer จำเป็นต้องยกเลิก Commit ที่ถูกยกเลิก

Solution ที่ 3:

วิธีที่ 3 และเป็นวิธีที่ง่ายที่สุด ก็คือ การ Force Push Master ไปยัง Develop จากนั้นให้ Merge Feature Branch อื่น ๆ ซ้ำเข้ามาใหม่ แล้วทำการ Deploy มันไปยัง QA อีกครั้ง

แต่ในกรณีนี้ขอแนะนำให้ใช้วิธีที่ 2 เนื่องจากเรากำลังพิจารณาถึง Productivity โดยรวมของทีม

แนวทางที่ดีที่สุด

เราสามารถแก้ปัญหานี้ได้ด้วยวิธีการต่อไปนี้: เราควรมีอีกหนึ่ง QA Branch เพื่อจุดประสงค์สำหรับการ Test ซึ่งตามหลักการแล้ว QA ควรจะถูก Update ด้วย Develop Branch

ดังนั้น จะมีขั้นตอนพิเศษเพิ่มเข้ามาในกรณีนั้น และ Life Cycle ทั้งหมด จะเป็นดังนี้:

• แตก Branch จาก Develop
• หลังการ Develop และ Test การ Develop แล้ว ให้ทำการ PR / MR ไปยัง QA สำหรับการ Review Code
• หลังการ Review Code แล้ว ให้ Merge มันเข้าไปใน QA Branch
• QA จะทำการ Test Feature และหลังจากทำเสร็จแล้ว คุณสามารถทำการ MR / PR ไปยัง Develop
• มีการ Review อีกครั้ง (เพื่อความสบายใจ) หรือ Merge Branch ของคุณไปยัง Develop โดยตรง เนื่องจากมันถูก Review และ Test แล้ว
• เมื่อใดก็ตามที่ Develop พร้อมสำหรับการใช้งาน (นั่นคือ Feature Branch ทั้งหมดถูก Merge) QA จะ Trigger Build เพื่อทำ Regression Testing ซึ่ง Build นี้สามารถ Run ได้ใน QA Environment ที่มีการ Config. ไว้แล้ว

Three-branch strategy

ประโยชน์ของแนวทางนี้

แม้ว่าแนวทางนี้ จะดูคล้ายกับวิธีการก่อนหน้านี้ และการเพิ่ม Branch เข้าไปอีก 1 Branch ดูเหมือนจะไม่มีประโยชน์อะไรนัก แต่มันจะช่วยเพิ่ม Productivity ได้ดังนี้

• คุณสามารถ Test Feature ได้จาก QA Branch และ Regression จาก Develop Branch ที่มีความเสถียร ภายหลังการ Merge Features ทั้งหมดที่ถูกวางแผนไว้ใน Release ปัจจุบัน
• Develop จะมีความเสถียรอยู่เสมอ และ Developer ทุกคน สามารถแตก Feature Branch ของพวกเขาได้ตลอดเวลา
• คุณจะไม่มีการ Spam Commit History ของ Develop Branch
• หาก QA ประสบปัญหาใน Feature Branch ใด ๆ คุณอาจจะแก้ไขมัน แล้ว Push โดยที่ไม่ต้องยกเลิกมัน หาก Feature นั้นไม่ขึ้นอยู่กับสิ่งอื่น ๆ
• Hotfix: ในกรณีที่มีปัญหาใด ๆ เกี่ยวกับ Production ให้แตก Branch จาก Master, แก้ไขมัน แล้วทำการ Release

ที่มา:  https://medium.com/

รับตำแหน่งงานไอทีใหม่ๆ ด้วยบริการ IT Job Alert

อัพเดทบทความจากคนวงในสายไอทีทาง LINE ก่อนใคร
อย่าลืมแอดไลน์ @techstarth เป็นเพื่อนนะคะ

บทความล่าสุด

• 9 CSS Tools ที่มีประโยชน์สำหรับ Web Developers 
• 12 เทคนิคและเคล็ดลับ ที่จะช่วยให้คุณเขียน Python Code ดีขึ้น 
• 10 Automation Test Tools ที่ช่วยทำให้ชีวิตของคุณง่ายขึ้น