• รูปแบบ Versioning ที่เลือกใช้
• กำหนดการใช้งานและจัดการ versioning ของ tag
• ข้อดีและข้อเสียของการจัดการ verioning ที่เลือกใช้
• สรุปจำนวนครั้งในการ build แบบอัตโนมัติของทุกวันในสัปดาห์นี้

---

• Frontend : http://159.65.12.177:6480
• Backend : http://159.223.45.216:6481/bedsdealing

รูปแบบ Versioning ที่เลือกใช้ : Semantic Versioning
Versioning หรือเลขเวอร์ชั่น เป็นส่วนที่ใช้บอกถึง อดีต ปัจจุบัน และอนาคต ของเครื่องมือนั้น ๆ ซึ่งประกอบไปด้วยตัวเลข 3 ส่วน

• ตัวเลข Patch (ตัวเลขหลักที่ 3)
  • สำหรับ patch มันคือการแก้ไขข้อผิดพลาดของระบบ, ซอฟต์แวร์, หรือแอพพลิเคชั่นนั้น ๆ เรียกได้ว่าเป็นตัวเลขที่ใช้บ่งบอกถึงการแก้ไขบั๊กต่าง ๆ
  • อาจเป็นการแก้ไขความผิดพลาด หรือการเปลี่ยนแปลงเล็ก ๆ น้อย ๆ ที่ทำให้ผู้ใช้สามารถพิจารณาอัพเดตได้อย่างสบายใจ
  • ถ้า Framework หรือระบบมีข้อผิดพลาด การแก้ไขในแต่ละรอบ จะกลายมาเป็นตัวเลขที่เพิ่มขึ้นในส่วนของ patch นั่นเอง
• ตัวเลข Minor (ตัวเลขหลักที่ 2)
  • ตัวเลข Minor มักมาพร้อมกับความสามารถใหม่ๆ (Feature) ที่มาพร้อมกับตัว Framwork หรือซอฟต์แวร์ และเป็นการอัพเดตที่ไม่ทำให้เกิด Major change หรือการเปลี่ยนแปลงสำคัญ
  • ซึ่งหลาย ๆครั้ง Feature ใหม่ ๆพวกนี้ มักมาจากความต้องการของทางผู้ใช้ หรือชุมชนนักพัฒนา
  • ดังนั้น Minor เราสามารถเรียกเป็น medium risk หรือเวอร์ชั่นที่มีความเสี่ยงปานกลาง ในกรณีที่มีปัญหาเกิดขึ้นจาก Minor ใหม่ ๆนี้ ก็มักจะมี Patch ตามมา
• ตัวเลข Major (ตัวเลขหลักที่ 1)
  • ตัวเลข Major มักมาพร้อมกับความเปลี่ยนแปลงที่ค่อนข้างใหญ่ อาจเป็นการเพิ่มความสามารถชุดใหญ่ หรือกระทั่งเปลี่ยนแปลงแนวคิดของเครื่องมือ อย่างเช่น การเปลี่ยนจาก AngularJS ไปเป็น Angular 2
  • จึงทำให้ตัวเลข Major ถูกจัดอยู่ในระดับ High risk (มีความเสี่ยงสูงต่อโปรเจค)
  • ดังนั้นการเปลี่ยน Major version มักจะมีการห้อยท้ายว่า “RC” (Release Candidate) หรือ Preview หรือ Beta เพื่อรับฟังปัญหา และข้อเสนอแนะจากผู้ใช้ หรือชุมชนนักพัฒนา เป็นระยะเวลาหนึ่ง

ตัวอย่าง versioning ในรูปแบบ semantic versioning

Major . Minor . Patch (x.x.x)

การจัดการตัวเลข versioning ของกลุ่มเรานั้น จะอยู่ในรูปแบบของ Semantic Versioning ดังที่ได้อธิบายไปในหัวข้อก่อนหน้านี้ โดยที่เราจะทำการ update ตัวเลข versioning แบบ manual โดยมีหลักการในการ update ตัวเลขตามรูปแบบ versioning ที่ได้เลือกไว้ ดังนี้

Frontend

1. major ตัวเลขในตำแหน่งนี้ จะเริ่มต้นที่ 1 และจะนับเพิ่มขึ้นไปเรื่อยๆทีละ 1 เมื่อมีการ update ของ code ในระดับที่ส่งผลเป็นอย่างมากมากต่อตัว project เช่น การเปลี่ยนเทคโนโลยีที่ใช้ในตัว project การเปลี่ยนแปลงรูปแบบ feature หลักของตัว project หรือการเพิ่มของ feature ที่ส่งผลต่อตัว project โดยตรง เป็นต้น
2. minor ตัวเลขในตำแหน่งนี้ จะเริ่มต้นที่ 0 และจะนับเพิ่มขึ้นไปเรื่อยๆทีละ 1 เมื่อมีการ update ของ code ในระดับที่ส่งผลต่อ project ในระดับนึง เช่น การเพิ่ม feature ทั่วๆไป เป็นต้น โดยตัวเลข minor ต้อง reset กลับไปเป็น 0 เมื่อมีการ update version ในระดับ major เกิดขึ้น
3. patch ตัวเลขในตำแหน่งนี้ จะเริ่มต้นที่ 0 และจะนับเพิ่มขึ้นไปเรื่อยๆทีละ 1 เมื่อมีการ update ของ code เกิดขึ้น ไม่ว่าการเปลี่ยนแปลงนั้นจะเป็นระดับ major หรือ minor

Backend

1. major ตัวเลขในตำแหน่งนี้ จะเริ่มต้นที่ 1 และจะนับเพิ่มขึ้นไปเรื่อยๆทีละ 1 เมื่อมีการ update ของ code ในระดับที่ส่งผลเป็นอย่างมากมากต่อตัว project เช่น การเปลี่ยนแปลงเทคโนโลยีที่ใช้ในการจัดเก็บข้อมูล เป็นต้น
2. minor ตัวเลขในตำแหน่งนี้ จะเริ่มต้นที่ 1 และจะนับเพิ่มขึ้นไปเรื่อยๆทีละ 1 เมื่อมีการ update ของ code ในระดับที่ส่งผลต่อ project ในระดับนึง เช่น การเพิ่ม api ใหม่ในการเรียกใช้ข้อมูล เป็นต้น โดยตัวเลข minor ต้อง reset กลับไปเป็น 0 เมื่อมีการ update version ในระดับ major เกิดขึ้น
3. patch ตัวเลขในตำแหน่งนี้ จะเริ่มต้นที่ 1 และจะนับเพิ่มขึ้นไปเรื่อยๆทีละ 1 เมื่อมีการ update ของ code เกิดขึ้น ไม่ว่าการเปลี่ยนแปลงนั้นจะเป็นระดับ major หรือ minor

ข้อดี : เป็นการจัดการ versioning ที่เป็นแบบ manual ที่ได้รับความเห็นจากสมาชิกในทีมเท่านั้นทำให้เข้าใจร่วมกันถูกต้อง และมั่นใจได้เมื่อทำการ update version

ข้อเสีย : เนื่องจากเป็นแบบ manual อาจส่งผลให้ใส่เลขเวอร์ชั่นผิดในบางกรณี หรือไม่ก็ใส่เลขผิดตำแหน่งทำให้ไม่สอดคล้องกับสิ่งที่เปลี่ยนแปลงในการ Deploy ในบางครั้ง

วิธีการปรับปรุงและจัดการกับข้อเสียที่พบ

1. ในการ update version ของ project ทุกครั้ง สมาชิกภายในกลุ่มจะต้องช่วยกันเช็คก่อนทำการ update version เพื่อให้แน่ใจว่า version ที่อัปเดตไป สอดคล้องกับกฏที่ได้ตั้งไว้หรือไม่
2. ทำการเช็คเลข version ในปัจจุบัน ก่อนทำการ update version ใหม่ เพื่อให้ตัวเลข version มีความสอดคล้องกัน

Frontend

Date	Build	Build success	Build failure
2022/04/04	2	2	0
2022/04/05	1	1	0
2022/04/06	0	0	0
2022/04/07	0	0	0
2022/04/08	0	0	0
2022/04/09	1	1	0
2022/04/10	0	0	0
2022/04/11	0	0	0
2022/04/12	0	0	0

Backend

 

Date	Build	Build success	Build failure
2022/04/04	2	2	0
2022/04/05	1	1	0
2022/04/06	0	0	0
2022/04/07	0	0	0
2022/04/08	0	0	0
2022/04/09	1	1	0
2022/04/10	0	0	0
2022/04/11	0	0	0
2022/04/12	0	0	0

Line change and Number commit of Group (wiki)

Student No.	Name	Line Change (%)	No. of Commit (%)
62070112	นายปภัส  เงาธัมมะสกุล	14.39%	15%
62070113	นายประธาน นาเวียง	18.75%	8%
62070134	นายพลัฏฐ์  วงศ์สิทธิพรรุ่ง	16.73%	12%
62070139	นายพิชญะ  สิงห์มีศรี	17.17%	11%
62070168	นายวิชยุตม์  ทวิชัยยุทธ	16.61%	15%
62070215	นายอคิราภ์  สีแสนยง	16.35%	39%

Line change and Number commit of Group (code)

 

Student No.	Name	Line Change (%)	No. of Commit (%)
62070112	นายปภัส  เงาธัมมะสกุล	2.68%	12%
62070113	นายประธาน นาเวียง	4.15%	7%
62070134	นายพลัฏฐ์  วงศ์สิทธิพรรุ่ง	18.09%	12%
62070139	นายพิชญะ  สิงห์มีศรี	1.73%	8%
62070168	นายวิชยุตม์  ทวิชัยยุทธ	2.04%	14%
62070215	นายอคิราภ์  สีแสนยง	71.30%	41%