เค้าวางโครงสร้างกันยังไงนะ
Story by nattapadtanasak kongpetsak
ต้องบอกก่อนว่าเรื่อง Git น่าเป็นเรื่องที่ทุกคนน่าจะรู้จักกันอยู่แล้วในสายงานโปรแกรมเมอร์ แต่ยิ่งถ้าต้องทำงานร่วมกันหลายคนต่อโปรเจคแล้ว ยิ่งต้องวางกรอบการทำงานร่วมกันให้ออกมาเป็นระบบให้มากขึ้น
ก่อนจะเข้าเรื่อง Git flow ที่นี่ เรามาดูกันก่อนว่า Branch Model & Branch Strategy ทั้งหมดของที่นี่นั้น มีอะไรบ้าง
Master
- คอยระบุสิ่งของที่ขึ้น production ไปแล้ว
- จะ relate กับ release branch เป็นหลัก ยอมรับการ merge จาก release branch เท่านั้น
- ของที่จะนำขึ้น production จะใช้ branch นี้ในการ deploy
- เราสามารถมี pipelines สำหรับ branch นี้ในการนำขึ้น server production
Release
- แหล่งพักรวมสิ่งของที่จะนำขึ้น production ใน version ถัดไป หรือ hotfix
- รวบรวมสิ่งของที่การันตีว่า test ผ่านแล้ว
Hotfix
- แตกมาจากจุดที่ level เดียวกับ master
- ไว้แก้ไขงานประเภทเร่งด่วนและต้องการนำงานขึ้นทันทีวันนั้น
- งานประเภทนี้ควรนำเข้า staging branch ด้วย เพื่อผ่านการ test
Staging
- เราสามารถเรียกอีกชื่อนึงคือ test branch แหล่งรวบรวบสิ่งของที่ต้องการส่งเทส
- ของทุกอย่างที่อยู่ใน staging ควรผ่านการ merge จาก pull request
- ของที่นำขึ้น server staging (test) จะใช้ branch นี้ในการ deploy
- เราสามารถมี pipelines สำหรับ branch นี้ในการนำขึ้น server sandbox
Develop
- เราสามารถเรียกอีกชื่อนึงคือ dev branch จุดกำเนินของการเริ่มต้นการแตก branch เพื่อทำงาน
- develop branch ควรอยู่ level เดียวกับ master & release เสมอ ทุกครั้งที่ master ถูก deploy
- ใช้ในการสื่อสารว่าทุกคนที่ทำงานในโปรเจคนี้ร่วมกัน ควรจะเริ่มต้น dev จากจุดไหน
Feature
- branch ที่แตกออกมาจากจุด develop เท่านั้น
- ไว้เพื่อระบุถึง feature ใหม่หรืองานที่ต้องไปเพิ่มเติมของจากระบบเดิม
- เป็น branch ที่ต้องเปิด Pull Request ทุกครั้ง
Bugfix
- branch ที่แตกออกมาจากจุด develop เท่านั้น
- ไว้แก้ไขงานประเภท bug ของระบบ
- เป็น branch ที่ต้องเปิด Pull Request ทุกครั้ง
ทีนี้เรามาดูกันว่า Flow ของที่นี่เค้าวางการทำงานกันไว้ยังไงนะ
อธิบายภาพจากล่างขึ้นบน
1. ทุกๆ main branch ควรถูกแตกออกมาจาก master branch ใน level เดียวกันก่อนได้แก่ release, staging & develop
2. เริ่มต้นทำงานที่ develop branch ทุกครั้งและควรจะแตกออกมาเป็น feature หรือ bugfix ขึ้นอยู่กับงานที่ถือ
หาก feature หรือ bugfix มีการ commit มากกว่า 1 แนะนำให้รวม commit ด้วยการ git rebase -i เพื่อกำจัด commit ที่เป็นขยะ
3. เมื่อดำเนินการทำ feature หรือ bugfix ใดเสร็จแล้ว ดำเนินการ push origin ขึ้นไปยัง Bitbucket เพื่อทำการขอ Pull Request ต่อไป
4. ในกรณีผู้ Review กด Approve แล้วกด merge ให้ Source Code จะถูก merge เข้า staging branch ให้ด้วยการ git merge — squash
** merge — squash คือการนำ source code จาก commit ต้นจนถึงปลายทางมายัดลง branch ที่ต้องการจะ to merge โดยที่เส้นจะไม่ผสานเข้าหากัน
5. เมื่อของถูกนำเข้า staging branch ทุกครั้ง ให้ดำเนินการ deploy ได้ทันที เพื่อส่งเทสกับทีม QA บน Server Sandbox
6. เมื่อ feature/bugfix ไหนพร้อมขึ้นแล้ว ดำเนินการนำเข้าสู่ release branch ได้เลยด้วยการ git merge — no-ff หากมีหลาย feature/bugfix branch ที่จะ release อย่าลืมทำการอัพเดทของ feature/bugfix ตามด้วยการ git rebase release ทุกครั้งก่อนจะ merge
7. ดำเนินการ Tag Version แล้วเข้าสู่กระบวนการ Deploy ขึ้น Production ต่อไป ด้วยการอัพเดท master branch ให้เทียบเท่ากับ release branch โดยการ git rebase release จึงจะสามารถดำเนินการ Deploy งานจาก master branch ได้
8. เมื่อใดก็ตามที่ master branch มีการอัพเดทของแล้วนำขึ้น server production แล้ว ให้ทุก branch ที่อยู่ level ต่ำกว่า master branch ทำการอัพเดทความสามารถตาม master branch ทันที ด้วยการใช้คำสั่ง git rebase master ทั้ง staging, develop, feature, bugfix
9. ในกรณี hotfix คุณสามารถแตก branch จาก level เดียวกับ master branch ได้เลย หากดำเนินการแก้ไขเสร็จสามารถเปิด pull request เพื่อร้องขอ merge เข้า staging ในการส่งเทส แล้วถ้าเทสผ่านดำเนินการ merge — no-ff เข้า master branch ได้ทันที หลังจากนั้นทุก branch จะต้องอัพเดทของตาม master branch ด้วย
ข้อดีที่เจอใน Flow นี้
- สามารถแบ่งแยกงานที่ตัวเองทำได้ชัดเจนจาก feature | bugfix
- สามารถแยก feature | bugfix ที่ยังไม่ได้ release ได้ชัดเจน
- สามารถตรวจสอบ conflict ระหว่างทางของ feature | bugfix ได้ กันการแก้ไข code ซ้อนกัน
- ช่วง release งาน สามารถระบุงานที่จะต้องขึ้นได้ง่าย รวมถึงระบุงานที่ยังไม่ release ได้ง่าย
- ไม่เกิด commit ขยะเกินไป
- ux / ui ดี เพราะไม่เกิดเส้น git แบบขนานกันหลายเส้น
ข้อเสีย
- ระบุ conflict ที่เกิดขึ้น ว่ามาจาก branch กับ branch ไหนได้ยาก
- ใช้คำสั่ง git ค่อนข้างเยอะ learning curve ค่อนข้างสูง
ขอจบด้วยการอธิบายภาพการใช้งานจริงที่ผ่านมานะครับ
ทั้งนี้เราหวังว่าบทความนี้จะเป็นประโยชน์กับทุกคนที่เข้ามาอ่านกันนะครับ
ขอบคุณที่อ่านกันถึงตอนจบครับ 🙂
