Blog ตอนนี้ เขียนตอนเกือบครบ 1 ปี หลังจากได้ย้าย SVN > GIT LAB โดยได้มีกำหนดข้อตกลง และขั้นตอนต่างๆ เพื่อให้ทุกคน ทุกทีมที่เกี่ยวข้องสามารถใช้งานกันได้อย่างมีประสิทธิภาพมากที่สุดครับ
ผมได้เลือกใช้ Pattern Git Flow และมาปรับใช้นิดหน่อย เพื่อให้เข้ากับการทำงานเดิมครับ
SVN การทำงานเดิม
- Code หลักอยู่ที่ Trunk โดย DEV
- แตก Branch แยกไป DEV เองได้
- หรือ จะ Dev ที่ Trunk เลยก็ได้
- การ Build เพื่อส่งลูกค้า มี Build ทุก Week โดยจะ Build จาก Trunk และมีการแบ่ง VERSION
- Internal Version : สำหรับทดสอบ QA นับจาก X.Y.Z.0 - X.Y.Z.2
- Customer Version : สำหรับส่งลูกค้าทางการสำหรับ UAT หรือ เอาขึ้น Production ส่วนใหญ่จะลงที่ X.Y.Z.3 หรือ X.Y.Z.4 แล้วแต่ว่าในรอบเดือนมีกี่สัปดาห์
- Hot Fixed Version : สำหรับแก้เคสด่วน หรือใช้งานช่วง UAT จน Go-Live
- การ Merge Code เข้ามา ถ้ามี Feature ใหญ่ ให้ Merge กรณีที่เป็น Version X.Y.Z.0 เท่านั้น
- ปัญหาของเดิม
- คุมการ Merge ได้ยาก เพราะ ทุกคนอาจจะมี Feature ด่วน แล้ว Merge เข้ามาใน Version ที่ไม่ใช่ X.Y.Z.0
- ระบบไม่เอื้อกับการทำ Code Review เท่าไหร่
GIT LAB การทำงานใหม่
- ผมอ้างอิงมาจาก Git Flow และมาปรับใช้กับรอบ Build และการจัดการเวอร์ชันแบบเดิม โดยแบ่ง Branch 5 กลุ่ม
- Branch develop : จุดเริ่มต้น โดย Branch นี้มี Code ทุกอย่างที่เกือบ Stable แล้ว
- Branch feature_{YOU_WORK} : แตกมาจาก Branch develop เพื่อมาทำงานต่างๆ ที่ได้รับมอบหมายครับ
- Branch release_X.Y.Z : ตั้งต้นมาจาก develop โดยเป็น Branch ที่เตรียมไว้สำหรับ Internal Test เวลา Build จะเป็น Internal Version
- Branch master : เป็น Branch หลัก ที่ใช้ Build ส่งลูกค้า Customer Version โดยเอา Branch RELEASE_X.Y.Z ที่ผ่านการ Internal Test และ Merge Code เข้ามาที่ MASTER
- Branch hotfixed_X.Y.Z : แตกมาจาก Tag ของ Customer Version ใช้ใน
- กรณีที่เกิดปัญหาด่วนที่ Site ลูกค้า เพื่อทำ Hot Fixed
- กรณีที่แผนของ PM / MKT ไม่สอดคล้องกับรอบ Build ของทาง DEVELOP เพื่อให้ไม่มี Code แปลกๆไปที่ ลูกค้าในระหว่างที่ UAT
- ใช้ระบบ Merge Request ที่มากับ Git Lab มาใช้ช่วยการ Review Source Code มันจะช่วยแก้ปัญหาเดิมใน SVN
- การส่ง Code Feature ด่วน แล้ว Merge เข้ามาใน Version ที่ไม่ใช่ X.Y.Z.0 มี Flow ดักไว้ไม่ให้ Merge แต่เรื่องนี้ทำ PM / MKT หัวร้อนเหมือนกัน เพราะจะเอาด่วนๆ รับปากลูกค้าไปแล้ว แต่ก็ช่างมัน 55
- Code Review สามารถทำได้แล้ว มี Comment การแก้ไข เพื่อเกิดการเรียนรู้ ปรับปรุงคุณภาพ Code รวมถึงหลังๆ จะเป็นกึ่งๆการสร้าง Coding Standard ไปในตัวด้วย
- VERSION จากเดิมที่กล่าวไปข้างต้น ว่ามี 2 กลุ่ม Internal Version / Customer Version / Hot Fixed Version มีเพิ่มอีกกลุ่มนึงขึ้นมา
- Feature Version ใช้สำหรับช่วงพัฒนา Feature ที่ Branch feature_{YOU_WORK} เพื่อที่จะทดสอบย่อยก่อนที่จะนำไปรวมที่ develop > release_X.Y.Z ต่อไป
- หลังจากใช้ไป 6-7 เดือนมี แนวคิด แยก Sub-Module ขึ้นมาครับ เนื่องจากระบบที่ทำอยู่มีงานอยู่ 2 ฝั่ง ที่ได้ Windows App / Web API ที่มี Core Service ใช้งานร่วมกันครับ โดยสามารถแบ่งได้ ดังรูป
วันนี้น่าจะสรุป Git Flow ที่ได้ใช้งานกันจริงๆแล้ว Blog ตอนต่อไปเป็นการบันทึกว่า หลังจากใช้มาเกือบๆ 1 ปี พบปัญหาอะไรกันบ้างครับ
Reference
Discover more from naiwaen@DebuggingSoft
Subscribe to get the latest posts sent to your email.
