Development Workflow สไตล์ CU Get Reg ฉบับคนไม่ค่อยว่าง

จากตอนก่อนหน้านี้ที่เราเล่าเรื่อง

• เบื้องหลังของ CU Get Reg เราทำอะไร? และเราทำยังไง?
• Architecture ของ CU Get Reg ฉบับ Q1 ปี 2022

วันนี้เราจะมาเล่าเรื่อง Development Workflow และเรื่องอื่น ๆ ที่เกี่ยวข้องกับการพัฒนา CU Get Reg กัน (ที่จริงคืออยากเขียนเก็บตกหลาย ๆ เรื่องที่ไม่รู้จะไปเขียนที่ไหนดี เป็น document เฉย ๆ 🤭) เชิญรับชมกันได้เลยครับ

Development Workflow คืออะไร?

มันคือ Process ที่ใช้ในการ Develop ตัว Software ขึ้นมาซึ่งจะเป็นอย่างไรนั้นก็ขึ้นอยู่กับวัฒนธรรมองค์กร ซึ่ง Development Workflow สำคัญมาก เพราะมันจะส่งผลถึงประสิทธิภาพของทีมและคุณภาพของ Product

สำหรับสถานะปัจจุบันของ CU Get Reg คือพวกเราได้ Release Product ออกไปแล้ว แต่ยังมีอีกหลาย Feature ที่เพิ่มได้ และ UX ที่ยังต้องแก้ไขอีกมาก แต่ทางทีมงานก็ไม่ค่อยว่างแก้ไขกันเท่าไร เพราะพวกเราก็ยังเป็นนิสิตกันอยู่ ดังนั้นสิ่งที่เราเลือกที่จะทำเพื่อให้งานสามารถเดินต่อไปได้มีดังนี้

1. สร้างระบบ User Report —จริง ๆ มันเป็นแค่ Form ที่เอาไว้รับปัญหาหรือข้อแนะนำจาก User ซึ่งก็มีประโยชน์พอสมควร เพราะบางอย่างพวกเราก็มองข้ามไปจริง ๆ ซึ่งสิ่งนี้เราสามารถนำมาสร้าง Backlog แล้ว assign ให้คนที่อยากทำไปทำได้
2. กำหนด Deadline — กำหนด Deadline ไปเลยว่าอยากได้ Feature นี้ภายในวันไหน แต่ก็ต้องดูความเป็นไปได้ด้วยว่าสามารถทำได้จริงหรือไม่

Backlog คืออะไร?

Backlog เป็น list ของ task ที่เกี่ยวข้องกับการปรับปรุงและพัฒนาระบบ ซึ่งเมื่อก่อนเราสร้าง Backlog กันบน Airtable แต่เนื่องจากว่าเราต้องการจะขยายขอบเขตของ CU Get Reg ให้กลายเป็น Open Source ดังนั้นถ้า Backlog อยู่ใน Airtable เหมือนเดิมจะทำให้ Outside collaborators ทำงานกันได้ไม่สะดวก ดังนั้นเราจึงย้าย Backlog ให้มาอยู่ใน Github Project แทน เราเปิดเป็น public อยู่ สามารถดูได้ทางนี้เลย

Build software better, together

อันนี้คือรูปตอนเพิ่งย้าย ยังมี task ไม่ค่อยเยอะ 😅

(หากท่านใดที่กำลังอ่านบทความนี้อยู่อยากมาจอยกับเรา สามารถติดต่อได้ที่ dev@cugetreg.com ได้ตลอดเวลา!)

หากต้องการจะเพิ่ม Task ใน Backlog สามารถเพิ่มได้เลยที่ Github Project ได้เลยหรือจะใช้วิธีสร้าง Issue แล้ว Link ไปยัง Project ก็ได้ (แนะนำวิธีนี้มากกว่า)

ตัวอย่างการเพิ่ม Task ใน Backlog ด้วย issue

สำหรับ Developer ที่อยู่ใน Project นี้ สามารถ Assign ตัวเองได้เลยว่าจะทำ Task ไหน และเมื่อเปิด Pull Reqest อย่าลืมเขียน Fix #<issue no.>หรือ Close #<issue no.> (เพื่อสั่งปิด Issue เมื่อ Pull request ถูก merged) จากนั้น Github Project จะย้ายสถานะ Task ให้อัตโนมัติ

ตัวอย่างการปิด issue ผ่าน pull request

Gitflow

จากบทความก่อนเรื่อง Architecture ของ CU Get Reg ฉบับ Q1 ปี 2022 เราได้เล่าไปแล้วว่าเรามี Environments ทั้งหมด 3 อย่าง นั่นก็คือ

1. Production — เป็น Environment ที่ชาวจุฬาฯ ใช้กันจริง ๆ
2. Beta — เป็นบ่อพักเพื่อที่จะรอปล่อยทุก Feature / Bug fixที่ทำรอไว้ทีเดียว
3. Dev — ที่ไว้ลองนู้นนี่ สามารถเอาไว้ Deploy ขึ้น Server เล่น ๆ ได้

ดังนั้น Gitflow ของเราจะเป็นประมาณนี้

Gitflow ฉบับมี 3 Environments

Master Branch

สำหรับ Master branch อันนี้ก็เป็นอันที่เข้าใจกันว่า มันคือ Production Environment นั่นเอง เราจะไม่ค่อยได้ไปยุ่งอะไรกับ Branch นี้เว้นเสียแต่ว่าจะมี Bug รุนแรงที่ต้องแก้ไขเดี๋ยวนี้ เราก็จแยก Branch ออกมาเป็น Hotfix branch เมื่อแก้ไขเสร็จแล้วค่อยทำการ Pull Request ไปที่ Master Branch อีกที

Beta Branch

สำหรับ Beta branch จะเป็น Branch ที่แยกออกมาจาก Master และจะเป็น Branch ที่เราจะใช้ค่อนข้างบ่อย อีกทั้งยังเป็นบ่อพัก Feature และ Bug fix ต่าง ๆ กัน Merge เข้า Master branch อีกทั้งเรายังใช้ Branch นี้สำหรับการทำ E2E Test ด้วย (ตอนนี้ยังไม่มีและยังไม่มีแพลนจะทำ แต่ถ้าจะทำเราจะมาทำใน Branch นี้)

Dev Branch

เป็น Branch ที่แยกออกมาจาก Beta อีกที มีความไม่เสถียรสูง เพราะจะมีการ Merge อยู่บ่อย ๆ จาก Developer หลาย ๆ คน อีกทั้งยังเป็นที่ที่เราได้ลอง Build และ Deploy ขึ้น Server จริง ๆ เพื่อเอาไว้ใช้ทดลองอะไรหลาย ๆ อย่าง เช่นการทดลอง Google Optimize ว่าใช้งานได้จริงไหม การเก็บ Analytic Log ว่าเก็บได้จริงหรือเปล่า และอื่น ๆ ที่มีความจำเป็นต้องลองทำบน Built-app และที่สำคัญที่สุดคือเราเอา Branch นี้เป็นตัวที่เอาไว้ Demo ตอน Pull request

Feature / Bug fix Branch

เป็น Branch ที่พวกเรา Developer ทำงานกัน ซึ่งมันจะแยกออกมาจาก Beta branch เมื่อทำไปได้สักประมาณหนึ่งแล้ว เราค่อย Merge เข้า Dev branch เมื่อลองทำสอบแล้วว่า Feature / Bug fix ที่เราทำมันใช้งานได้ เราจะ Pull request เข้าไปยัง Beta Branch จากนั้นรอ Code review จาก Developer คนอื่น หากได้รับการ Approve แล้วก็ Merge ได้เลย!

สรุป Flow การทำงานของ Developer

จากเรื่อง Gitflow เมื่อครู่ อาจจะยังงง ๆ อยู่ว่าสรุปแล้ว Developer ต้องเริ่มทำงานจากตรงไหน เดี๋ยวเราจะสรุปให้ฟังเป็นลำดับดังนี้

1. แตก Branch ออกจากมา Beta จากนั้นตั้งชื่อว่า <username>/<action>/<do-something>(ในส่วนของ action จะมี fix, hotfix, feat) ปล.ที่ให้ระบุชื่อด้วยเพราะจะได้หา Branch ตัวเองได้ง่าย และเพื่อให้คนอื่นรู้ด้วยว่าเราทำอะไรอยู่
2. เขียน Code ใน Branch นั้นไปเรื่อย ๆ เสร็จเมื่อไรค่อย Merge เข้า Dev branch
3. เมื่อทดสอบใน Dev Branch แล้วไม่มีปัญหา ให้เปิด Pull Request จาก <username>/<action>/<do-something>Branch เข้า Beta branch พร้อมแปะลิงก์ Dev environment สำหรับให้ Code Reviewer ดูด้วยว่าเราทำอะไรไปบ้าง
4. Reviewer เราจะเลือกใครก็ได้ และต้องมีอย่างน้อง 1 Approve ถึงจะ Merge เข้า Beta branch ได้
5. จากนั้นรอรอบในการ Deploy (อยู่ Section ด้านล่าง)

Git Convention

เนื่องด้วยความเป็น Open source ทำให้เราจำเป็นที่จะต้องมี Note บอกกับ User และ Developer หน่อยว่าตอนนี้เราเป็น Version อะไร และ Version นี้เราแก้หรือเพิ่มอะไรไปบ้าง เป็นประวัติศาสตร์ ซึ่งสิ่งนี้เรียกว่า Release note

ตัวอย่าง Release note

โดยใน CU Get Reg เราจะใช้ semantic-release เป็นตัวคอย Generate release note แบอัตโนมัติ โดยใช้ Commit message เป็นตัว generate นั่นเอง ซึ่งใน CU Get Reg ควรจะเขียน commit message ให้ไดตาม Pull Request #317 ซึ่งถ้าให้สรุปกันง่ายก็คือ

1)สำหรับการ commit ทั่วไป ไม่ต้องทำตาม Angular convention (เช่น feat: something อย่างงี้ไม่ต้อง) เราจะสนใจแค่ตอน merge pull request เท่านั้น

2)ตอนจะ merge PR ถ้าเราเลือก Create a Merge commit ให้เขียน description ด้วย Angular convention เช่น

การเขียน description ด้วย Angular convention

3)ตอนจะ merge PR ถ้าเราเลือก Squash and Merge ไม่ต้องทำอะไรเพิ่มเติมใด ๆ merge ได้เลย

squash merge ไม่ต้องทำอะไรเพิ่มเลย

การ Deploy

ในการ Deploy CU Get Reg จะมีกระบวนการดังนี้

1) เปิด Pull request จาก Beta branch เข้า Master branch โดยตั้งชื่อ PR ว่า Deploy to Production (Day Month Year)

2) จากนั้นรันคำสั่ง เพื่อดูว่าจาก tag ล่าสุดถึง beta มีอะไรถูก merge เข้ามาบ้าง

git fetch
git shortlog $(git describe --tags --abbrev=0)..origin/beta --oneline --merges --first-parent

3) จากนั้น Copy สิ่งที่ได้จากข้อที่แล้ว แล้วไปแจ้งใน Channel #cgr-frontend หรือ #cgr-backend (ใน Slack) ว่าเรากำลังจะ Deploy ตัวอย่างเช่น

ตัวอย่างของการแจ้งว่าเรากำลังจะ Deploy

4) รอทุกคนที่อยู่ในข้อที่ 2 ยืนยันว่าสิ่งที่ตัวเองทำไม่มีปัญหา โดยพิมพ์ไปใน Slack หรือไม่ก็ comment ใน Pull request ก็ได้

5) Merge pull request เข้า Master!

6) เนื่องจากเราป้องกันการ merge เข้า master โดยไม่ได้ตั้งใจ เราจะต้อง maully trigger Github Action เฉพาะ Master branch โดยกดที่ตรงนี้ ตามรูปเลย (ผู้กดจะต้องมีสิทธิ์ Editor ขึ้นไป)

กด run workflow ได้เลย!

7) เย้ เสร็จเรียบร้อยแล้ว!! 🌈 รอดูผลงานของตัวเองใน Production ได้เลย

ทิ้งท้ายเล็กน้อย

ขอบคุณที่อ่านมาถึงตรงนี้นะครับ ตอนนี้ CU Get Reg ยังต้องการคนมา Operate งานต่อ (เพราะตอนนี้หลาย ๆ อย่างก็ยังต้องใช้มนุษย์ในการดูแลอยู่) และอีกไม่กี่ปีข้างหน้าทีมงานชุดปัจจุบันก็จะจบการศึกษาและคงไม่ได้ดูแล Project นี้ต่อแล้ว เพราะต่างคนก็คงทำงานประจำของตัวเองไป เพราะฉะนั้นหากท่านผู้อ่านท่านใดสนใจที่จะมาช่วยสร้างคุณภาพชีวิตที่ดีขึ้นให้กับชาวจุฬาฯ สามารถ Email ได้ที่ dev@cugetreg.com