กำหนด Label ใน Git ง่ายๆ ด้วย TIPS

Arnon Kijlerdphon -

ถ้าใครใช้ Gitlab หรือ Github หรือ Git repository เจ้าอื่นๆ ก็คงเคยเจอเวลาเราสร้าง Issue แล้วจะมีให้เราสามารถกำหนด Label ลงไปได้

เมื่อจำนวน Issue หรือ Merge requests เพิ่มขึ้นมากมายใน GitLab การติดตามรายการเหล่านั้นก็ยิ่งท้าทายมากขึ้น เราสามารถใช้ Label จัดระเบียบและติดตามรายการงานที่เราสนใจได้ง่ายขึ้น นั้นละหน้าที่ของ Label

หลายคนอาจสงสัยว่า แล้วเราจะตั้งชื่อ Label และนำไปใช้ยังไงดี? ถ้าหลงเข้ามาอ่านถึงตรงนี้แล้ว ผมจะมาแนะนำวิธีการที่ผมใช้อยู่ในปัจจุบันตามนี้...

วิธีการตั้งชื่อ Labels

เราจะตั้งชื่อ Label ให้เป็นในรูปแบบหมวดหมู่การใช้งาน

<CATEGORY-NAME>:<CATEGORY-VALUE>

เช่น type:bug หรือ type:enhancement หรือ priority:medium เป็นต้น ซึ่งผมจะใช้วิธีการแบ่งหมวดหมู่ที่เรียกว่า TIPS

TIPS เป็นตัวย่อของ Type, Impact, Priority และ Status หมายความว่าแต่ละ Issue ควรมี Label ที่อธิบายถึง Type, Impact และอื่นๆ ให้ครบ 4 หมวด

แต่ละคำเหล่านั้นหมายความว่าอย่างไร? มาดูกัน

Type:

Issue นี้อยู่ในประเภทไหน จะมีค่าดังนี้

  • Deployment: ไว้สำหรับ deploy
  • Bug: ระบุว่ามันคือข้อผิดพลาด
  • Documentation: ระบุว่าเกี่ยวกับเอกสาร
  • Enhancement: มีการใช้งานเพิ่มขึ้นหรือ Features ใหม่เข้ามา
  • Security: เกี่ยวกับ OWASP หรือความปลอดภัยอื่นๆ
  • Performance: ปรับปรุงให้ดีขึ้น เร็วขึ้น
  • Refactoring: ปรับปรุง code ให้มันอ่านได้ง่ายขึ้น ลดการซับซ้อนของ code เดิมลง แต่การทำงานยังถูกต้องเหมือนเดิม

Impact:

ใครได้รับผลกระทบจาก Issue นี้บ้าง? ลูกค้า? ทีมพัฒนา? ทีมการตลาดและลูกค้า? จะมีค่าดังนี้

  • Internal: Issue ที่เกิดผลกระทบภายในบริษัทเท่านั้น
  • External: Issue ที่เกิดผลกระทบต่อบุคคลอื่นภายนอกบริษัท

Priority:

ระดับความสำคัญของ Issue จะมีค่าดังนี้

  • Critical: ทิ้งทุกอย่างแล้วมาทำมันซะ
  • High: ควรรีบมาจัดการ
  • Medium: ยังอยู่ในแผนงาน
  • Low: ทำมันเมื่อเราไม่มีอะไรให้ทำมากกว่านี้

Status:

เป็นการบอกสถานะปัจจุบันของ Issue จะมีค่าดังนี้

  • Backlog: เป็น Issue ที่ถูกสร้างขึ้นมาแต่ยังไม่ต้องจัดการในตอนนี้
  • In progress: เรากำลังดำเนินการ
  • Completed: เสร็จแล้ว
  • Investigating: ค้นหาข้อมูลเพิ่มเติมก่อนดำเนินการ
  • Testing: ทดสอบก่อนที่จะ Completed
  • Code review: อยู่ในช่วงตรวจสอบ Code

ตัวอย่างที่ผมใช้ใน Gitlab

เพิ่มเติม

ในบ้าง Repo หรือโปรเจ็คอาจกำหนด Label เพิ่มเติมนอกเหนือจาก TIPS ก็ได้ โดยของผมจะมีประมาณนี้

  • Component: ผมเอาไว้ระบุว่า issue นี้เกี่ยวข้องกับ feature หรือ module ไหนของโปรเจ็ค เช่น Component:User หรือ Component:Vote หรือ Component:Dashboard เป็นต้น
  • DevOps: ไว้ระบุว่ามันคือหน้าที่ของ DevOps ในการจัดการ เช่น Devops:Create หรือ Devops:Release เป็นต้น
  • Uxui: เพื่อบอกว่าจัดการในส่วนของ design หรือ responsive เช่น uxui:design หรือ uxui:respnsive เป็นต้น

อย่าลบ Label ที่เราจะยกเลิกการใช้งาน

การลบ Label ที่คิดว่าจะไม่ใช้งานมันอีกต่อไปแล้ว มันจะไปกระทบต่อ Issue หรือ Merge requset ที่เกี่ยวข้องทั้งหมด สิ่งที่ควรทำคือ

  1. เติมคำว่า DEPRECATE_ นำหน้าชื่อ Label เช่น pMm เราแก้ไขเป็น DEPRECATE_pMm
  2. บอกให้ทุกคนในทีมทราบเรื่องที่เราจะยกเลิกการใช้งาน Label นี้
  3. รอหนึ่งเดือนแล้วค่อยกลับมาลบ เพื่อที่คนอื่นๆ จะได้ไม่มีใครนำไปใช้งาน

วิธีนำไปใช้

ในทุกครั้งตอนเราสร้าง Issue ให้นึกถึงคำว่า "TIPS" ขึ้นมาเลย แล้วระบุ Label ตามไปเลย Type > Impact > Priority > Status และ Label อื่นๆ ที่อยากเพิ่ม

จะเห็นว่าในการสร้าง Issue แต่ละครั้งของเราต่อไปก็จะไม่มี Issue ไหนที่ไม่มี Label แล้ว และทุกๆ Issue ก็จะต้องมี TIPS เข้าไปด้วยเสมอ

ลองนำไปปรับใช้ตามกันนะครับ ไม่จำเป็นต้องเหมือนของผมทั้งหมด หรือใครแชร์วิธีกำหนด Label ของตัวเองก็บอกกันมาได้นะ...

ข้อมูลเพิ่มเติม:

  • https://seantrane.com/posts/logical-colorful-github-labels-18230/
  • https://about.gitlab.com/handbook/marketing/project-management-guidelines/labels/
  • https://www.fat.codes/articles/tips-issue-labeling-system/