[The Next Gen Navy Ep.24/80] GitHub / GitLab: “ไทม์แมชชีน” แห่งโลกโค้ด…หยุดวิกฤต “ใครเซฟทับงานใคร?” ด้วยระบบควบคุมเวอร์ชันอัจฉริยะ

Spread the love
5/5 - (3 votes)

รายงานตัวประจำวันอาทิตย์ที่ 4 มกราคม 2569 ครับ เดินทางมาถึง ตอนที่ 24 ซึ่งเป็นตอนสุดท้ายของ บทที่ 3 กันแล้วนะครับ! หลังจากที่เราวางแผนกันมาดิบดี ทั้งกระจายงานให้ทำ (Decentralized), ตั้งทีม Avengers (Cross-Functional), และกำหนดมาตรฐานกลาง (Standard Framework)

แต่ในภาคปฏิบัติ… เมื่อคนเก่งหลายคนมารุมทำไฟล์เดียวกัน ปัญหาโลกแตกที่ต้องเจอแน่ๆ คือ “อ้าว! พี่เซฟทับงานผมทำไม?” หรือ “โค้ดเมื่อวานดีกว่า วันนี้แก้แล้วพัง จะย้อนกลับยังไง?” วันนี้ จะพาท่านมารู้จักกับ GitHub หรือ GitLab เครื่องมือที่เปรียบเสมือน “ไทม์แมชชีน” และ “หอสมุดกลาง” ที่จะช่วยบันทึกทุกการเปลี่ยนแปลง และป้องกันหายนะทางข้อมูลได้อย่างชะงัดนักครับ!


ส่วนที่ 3: ยุทธศาสตร์การพัฒนาแบบมีส่วนร่วม (Co-Creation Strategy)

จุดประสงค์: แก้ปัญหา Bias และดึงเจ้าของงาน (Users) มาเป็นผู้ร่วมสร้าง

ตอนที่ 24/80: GitHub / GitLab สำหรับ ทร.: การจัดการ Version Control ร่วมกันทั้งกองทัพ

ในโลกของการพัฒนาซอฟต์แวร์ เราจะไม่ส่งไฟล์โค้ดหากันทาง Flash Drive หรือ LINE ครับ แต่เราจะใช้ระบบที่เรียกว่า Version Control System (Git) โดยมี GitLab (หรือ GitHub) เป็นศูนย์บัญชาการกลาง เพื่อแก้ปัญหาดังนี้:

1. ไทม์แมชชีนย้อนเวลา (History & Rollback)

  • ปัญหา: พัฒนา Module มา 3 เดือน จู่ๆ วันนี้ระบบล่มเพราะแก้โค้ดผิด แต่จำไม่ได้ว่าแก้อะไรไปบ้าง
  • ทางแก้: ระบบ Git จะทำหน้าที่เหมือน Checkpoint ในเกมครับ ทุกครั้งที่เราบันทึก (Commit) มันจะจำไว้หมดว่า “ใครแก้? แก้บรรทัดไหน? แก้เมื่อไหร่?”
  • ผลลัพธ์: เราสามารถกดปุ่มเดียว เพื่อย้อนเวลาระบบกลับไปสู่สภาพเมื่อวาน หรือเมื่อเดือนที่แล้วได้ทันที (Rollback) โดยไม่ต้องมานั่งงมหาไฟล์ backup เก่าๆ

2. โลกคู่ขนาน (Branching Strategy)

  • ปัญหา: ทีม A อยากลองฟีเจอร์ใหม่ แต่กลัวทำระบบหลักพัง
  • ทางแก้: สร้าง “โลกคู่ขนาน” (Branch) ครับ
    • Main Branch: คือโลกจริงที่ระบบทำงานอยู่ (ห้ามแตะต้อง)
    • Develop Branch: คือโลกทดลอง ให้ทีม A เอาโค้ดไปยำได้เต็มที่ ถ้าพังก็พังแค่ในโลกทดลอง
  • ผลลัพธ์: เมื่อทีม A ทดลองจนมั่นใจแล้ว ค่อยส่งเรื่องขอรวมจักรวาล (Merge Request) กลับมาที่โลกจริง ซึ่งต้องผ่านการตรวจสอบจาก สสท.ทร. (Regulator) ก่อน

3. การทำงานพร้อมกัน (Collaboration without Conflict)

  • สถานการณ์: จ่าเอก ก. แก้หน้าจอ “ใบลา” และ จ่าเอก ข. ก็แก้หน้าจอ “ใบลา” เหมือนกัน ในเวลาเดียวกัน
  • ระบบทั่วไป: คนที่เซฟทีหลัง จะทับงานคนแรกหายไปเลย
  • GitLab: ระบบจะแจ้งเตือนว่า “Conflict!” (มีการชนกัน) และจะโชว์โค้ดของทั้งสองคนขึ้นมาเทียบกันบรรทัดต่อบรรทัด ให้เราเลือกว่าจะเก็บของใครไว้ หรือจะผสมผสานกัน ไม่มีการทับกันมั่วซั่ว

4. ข้อจำกัดและอุปสรรค (The Constraints)

  • ต้องเรียนรู้ใหม่: การใช้คำสั่ง Git (เช่น Push, Pull, Merge) เป็นเรื่องใหม่และยากสำหรับเจ้าหน้าที่ที่ไม่ใช่สายไอทีโดยตรง ต้องมีการอบรมเข้มข้น
  • ความลับทางทหาร: การเอาโค้ดของกองทัพไปฝากไว้บน Cloud สาธารณะ (เช่น GitHub ฟรี) อาจเสี่ยงต่อความมั่นคง

5. ข้อแนะนำและข้อเสนอแนะ (Recommendations)

  • Self-Hosted GitLab: กองทัพเรือควรตั้ง Server GitLab (Enterprise Edition) ขึ้นมาเองภายในเครือข่ายของกองทัพ (Intranet) เพื่อเก็บ Source Code ทั้งหมดไว้ในบ้านเราเอง ปลอดภัยที่สุด
  • Permission Management: กำหนดสิทธิ์ให้ชัดเจน เช่น “นายเรือฝึกหัด” มีสิทธิ์แค่อ่านโค้ด (Read) แต่ “หัวหน้าโครงการ” มีสิทธิ์อนุมัติโค้ด (Maintainer)

บทสรุป

การนำ GitLab มาใช้ ไม่ใช่แค่เรื่องของโปรแกรมเมอร์ แต่คือการสร้าง “วินัยในการทำงานร่วมกัน” ของทั้งกองทัพ

ระบบนี้จะเปลี่ยนจากวัฒนธรรม “ไฟล์ใครไฟล์มัน” มาเป็น “ทรัพย์สินร่วมกัน” (Collective Asset) ที่ทุกคนช่วยกันดูแล ตรวจสอบ และพัฒนาต่อยอดได้ โดยไม่ต้องกลัวว่างานจะหายหรือถูกทำลาย นี่คือจิ๊กซอว์ชิ้นสุดท้ายของบทที่ 3 ที่จะทำให้ยุทธศาสตร์การพัฒนาแบบมีส่วนร่วมของเรา แข็งแกร่งและยั่งยืนครับ

(อ้างอิง: Git SCM Documentation และ GitLab for Enterprise)


คำถามชวนคิด (เพื่อการมีส่วนร่วม)

  • ท่านเคยตั้งชื่อไฟล์งานแบบนี้ไหมครับ? Report_Final.doc, Report_Final_JingJing.doc, Report_Final_Last_V2.doc? (Git จะทำให้ท่านเลิกทำแบบนี้ครับ)
  • ท่านเคยทำงานกลุ่มแล้วเพื่อนลบย่อหน้าที่ท่านเขียนทิ้งไปโดยไม่บอกไหมครับ?
  • ท่านรู้สึกปลอดภัยขึ้นไหม? ถ้ารู้ว่าทุกตัวอักษรที่ท่านเขียนโค้ดลงไป ถูกบันทึกประวัติไว้หมด และกู้คืนได้เสมอ?

ติดตามตอนต่อไป

จบ ส่วนที่ 3 แล้วครับ! ตอนนี้เรามีทีม มีเครื่องมือ มีมาตรฐาน และมีระบบจัดการโค้ดพร้อมรบแล้ว! ในบทต่อไป บทที่ 4: เจาะลึก Module 1 – การบริหารกำลังพล (HR Transformation) เราจะเริ่มเจาะลึกที่ “คน” เป็นอันดับแรก พบกันใน Ep.25/80 “ผ่าตัดระบบ HRMISS เดิม: อะไรคือข้อจำกัดที่ต้องเร่งแก้ไข” มาร่วมกันชำแหละแผลเก่า เพื่อสร้างเนื้อเยื่อใหม่ที่ดีกว่าเดิมครับ ห้ามพลาด!

Facebook Comments Box
Visited 28 times, 1 visit(s) today

Leave a Comment