Topic 19 Version Control

ความก้าวหน้าไม่ได้อยู่ที่การเปลี่ยนแปลง แต่อยู่ที่ความสามารถในการจดจำต่างหาก ผู้ที่ไม่สามารถจดจำอดีตได้ มีแต่จะต้องย้อนกลับไปเผชิญกับมันซ้ำอีกครั้ง

George Santayana , Life of Reason

หนึ่งในสิ่งสำคัญที่เรามองหาใน User Interface คือปุ่ม Undo —ปุ่มเดียวที่ให้อภัยความผิดพลาดของเราได้ ยิ่งดีไปอีกถ้า Environment รองรับ Undo และ Redo หลายระดับ เพื่อให้คุณย้อนกลับไปกู้คืนสิ่งที่เกิดขึ้นเมื่อสองสามนาทีก่อนได้

แต่ถ้าความผิดพลาดนั้นเกิดขึ้นตั้งแต่สัปดาห์ที่แล้ว แถมคุณยังเปิดปิดคอมพิวเตอร์ไปแล้วสิบรอบตั้งแต่นั้นล่ะ? นี่แหละคือหนึ่งในประโยชน์มากมายของการใช้ Version Control System (VCS): มันเป็นเหมือนปุ่ม Undo ขนาดยักษ์—เป็น Time Machine ของทั้งโปรเจกต์ที่พาคุณย้อนกลับไปยังวันเวลาอันแสนสงบสุขของสัปดาห์ที่แล้ว ตอนที่โค้ด Compile และรันได้จริง ๆ

สำหรับหลายคน นั่นคือขอบเขตการใช้งาน VCS ของพวกเขาแล้ว ซึ่งพวกเขากำลังพลาดโลกอันกว้างใหญ่ของการทำงานร่วมกัน Deployment Pipeline การติดตาม Issue และปฏิสัมพันธ์ต่าง ๆ ภายในทีมไปอย่างน่าเสียดาย

ดังนั้นมาดู VCS กันครับ ก่อนอื่นในฐานะที่เป็น Repository เก็บการเปลี่ยนแปลงต่าง ๆ แล้วจากนั้นในฐานะจุดนัดพบกลางของทีมคุณและโค้ดของพวกเขา

Shared Directories Are NOT Version Control (การแชร์ Directory ธรรมดาไม่ใช่ Version Control)

เรายังคงเจอทีมบางทีมที่แชร์ไฟล์ Source ของโปรเจกต์ผ่าน Network กันอยู่เป็นครั้งคราว ไม่ว่าจะเป็นภายในองค์กรเอง หรือผ่าน Cloud Storage บางรูปแบบ

วิธีนี้ใช้ไม่ได้ผลครับ

ทีมที่ทำแบบนี้มักจะทำงานของกันและกันพังอยู่เรื่อย ๆ ทำการเปลี่ยนแปลงหายไป ทำ Build พัง แถมยังลงเอยด้วยการทะเลาะวิวาทกันในลานจอดรถ มันก็เหมือนกับการเขียน Concurrent Code ที่ใช้ Shared Data โดยไม่มี Synchronization Mechanism เลยนั่นแหละ ใช้ Version Control ซะเถอะครับ

แต่ยังไม่หมดแค่นั้น! บางทีมก็ ใช้ Version Control จริง ๆ แต่ดันเก็บ Repository หลักไว้บน Network หรือ Cloud Drive พวกเขาให้เหตุผลว่ามันคือทางเลือกที่ดีที่สุดของทั้งสองโลก: ไฟล์เข้าถึงได้จากทุกที่ และ (ในกรณีของ Cloud Storage) ก็มีการสำรองข้อมูลนอกสถานที่ให้ด้วย

แต่ที่จริงแล้วมันแย่ยิ่งกว่าเดิมอีก และคุณเสี่ยงที่จะสูญเสียทุกอย่างไปเลย ซอฟต์แวร์ Version Control ทำงานด้วยชุดไฟล์และ Directory ที่ทำงานเชื่อมโยงกันอยู่ ถ้ามีสอง Instance เปลี่ยนแปลงข้อมูลพร้อมกัน สถานะโดยรวมอาจเสียหายได้ และไม่มีใครรู้ได้เลยว่าความเสียหายจะมากแค่ไหน และไม่มีใครอยากเห็น Developer ร้องไห้หรอกครับ

It Starts at the Source (เริ่มต้นที่ Source)

Version Control System จะติดตามทุกการเปลี่ยนแปลงที่คุณทำกับ Source Code และเอกสารของคุณ เมื่อตั้งค่า Source Code Control System อย่างถูกต้องแล้ว คุณสามารถย้อนกลับไปยังเวอร์ชันก่อนหน้าของซอฟต์แวร์คุณได้เสมอ

แต่ Version Control System ทำได้มากกว่าแค่ Undo ความผิดพลาด VCS ที่ดีจะช่วยให้คุณติดตามการเปลี่ยนแปลง และตอบคำถามอย่างเช่น: ใครเป็นคนแก้บรรทัดโค้ดนี้? เวอร์ชันปัจจุบันต่างจากเวอร์ชันสัปดาห์ที่แล้วตรงไหนบ้าง? Release นี้เราเปลี่ยนโค้ดไปกี่บรรทัด? ไฟล์ไหนถูกแก้บ่อยที่สุด? ข้อมูลแบบนี้มีค่าอย่างมากสำหรับการตามหา Bug การ Audit ประสิทธิภาพ และคุณภาพของงาน

VCS ยังช่วยให้คุณระบุ Release ต่าง ๆ ของซอฟต์แวร์ได้ด้วย เมื่อระบุไว้แล้ว คุณจะสามารถย้อนกลับไปสร้าง Release นั้นขึ้นมาใหม่ได้เสมอ ไม่ว่าจะมีการเปลี่ยนแปลงอะไรเกิดขึ้นภายหลังก็ตาม

Version Control System อาจเก็บไฟล์ที่มันดูแลไว้ใน Repository กลาง ซึ่งเหมาะมากสำหรับการทำ Archive

สุดท้ายนี้ Version Control System ยังเปิดให้ผู้ใช้ตั้งแต่สองคนขึ้นไปทำงานพร้อมกันบนไฟล์ชุดเดียวกันได้ แม้กระทั่งแก้ไขไฟล์เดียวกันพร้อม ๆ กัน ระบบจะจัดการ Merge การเปลี่ยนแปลงเหล่านี้เมื่อไฟล์ถูกส่งกลับเข้า Repository แม้จะดูเสี่ยงอยู่บ้าง แต่ระบบแบบนี้ก็ทำงานได้ดีในทางปฏิบัติกับโปรเจกต์ทุกขนาด

Tip 28 ใช้ Version Control เสมอ

เสมอ ไม่ว่าจะเป็นทีมคนเดียวทำโปรเจกต์แค่หนึ่งสัปดาห์ก็ตาม ไม่ว่าจะเป็น Prototype แบบ “ใช้แล้วทิ้ง” ก็ตาม หรือแม้แต่สิ่งที่คุณกำลังทำอยู่จะไม่ใช่ Source Code เลยก็ตาม ให้แน่ใจว่า ทุกอย่าง อยู่ภายใต้ Version Control: เอกสาร รายชื่อเบอร์โทรศัพท์ บันทึกถึง Vendor Makefile ขั้นตอน Build และ Release Shell Script เล็ก ๆ ที่ใช้จัดระเบียบ Log File—ทุกอย่างเลยครับ เราใช้ Version Control กับแทบทุกอย่างที่เราพิมพ์เป็นประจำ (รวมถึงเนื้อหาของหนังสือเล่มนี้ด้วย) แม้ในตอนที่เราไม่ได้ทำโปรเจกต์อะไรอยู่ งานประจำวันของเราก็ยังถูกเก็บไว้อย่างปลอดภัยใน Repository

Branching Out (การแตกกิ่งก้าน)

Version Control System ไม่ได้แค่เก็บประวัติเดียวของโปรเจกต์คุณเท่านั้น หนึ่งใน Feature ที่ทรงพลังและมีประโยชน์ที่สุดคือการที่มันให้คุณแยกเกาะของการพัฒนาออกมาเป็นสิ่งที่เรียกว่า Branch คุณสามารถสร้าง Branch ได้ทุกจุดในประวัติของโปรเจกต์ และงานทุกอย่างที่คุณทำใน Branch นั้นจะถูกแยกออกจาก Branch อื่น ๆ ทั้งหมด แล้วในอนาคตคุณก็สามารถ Merge Branch ที่คุณกำลังทำงานอยู่กลับเข้าไปยัง Branch อื่นได้ ทำให้ Branch เป้าหมายมีการเปลี่ยนแปลงที่คุณทำใน Branch ของคุณรวมอยู่ด้วย แถมยังมีหลายคนทำงานบน Branch เดียวกันได้อีกด้วย ในแง่หนึ่ง Branch ก็เหมือนโปรเจกต์ Clone ย่อม ๆ นั่นเอง

ประโยชน์อย่างหนึ่งของ Branch คือการแยกส่วนที่มันมอบให้คุณ ถ้าคุณพัฒนา Feature A อยู่ใน Branch หนึ่ง และเพื่อนร่วมทีมกำลังทำ Feature B อยู่อีก Branch หนึ่ง คุณทั้งสองก็จะไม่รบกวนการทำงานของกันและกัน

ประโยชน์ข้อที่สอง ซึ่งอาจทำให้คุณแปลกใจ คือ Branch มักจะเป็นหัวใจสำคัญของ Workflow โปรเจกต์ของทีม

และนี่คือจุดที่เรื่องราวเริ่มชวนงงเล็กน้อย Branch ใน Version Control กับการจัดระเบียบ Test มีจุดร่วมกันอย่างหนึ่ง นั่นคือทั้งคู่มีคนนับพันคนคอยบอกคุณว่าควรทำอย่างไร และคำแนะนำเหล่านั้นส่วนใหญ่ก็แทบไม่มีความหมายอะไรเลย เพราะสิ่งที่พวกเขากำลังพูดจริง ๆ ก็แค่ “นี่คือสิ่งที่เวิร์กสำหรับฉัน” เท่านั้นเอง

ดังนั้นใช้ Version Control ในโปรเจกต์ของคุณ แล้วถ้าเจอปัญหาเกี่ยวกับ Workflow ก็ลองค้นหาวิธีแก้ที่เป็นไปได้ดู และอย่าลืมทบทวนและปรับปรุงสิ่งที่คุณทำอยู่ตามประสบการณ์ที่สั่งสมมาด้วยครับ

A Thought Experiment (การทดลองทางความคิด)

ลองคว่ำชาทั้งถ้วย (English Breakfast ใส่นมนิดหน่อย) ลงบน Keyboard ของ Laptop คุณดูสิ เอาเครื่องไปที่ร้านซ่อมมือโปร ให้พวกเขาส่ายหน้าทำหน้าเบ้ใส่ ซื้อคอมพิวเตอร์เครื่องใหม่ แล้วเอากลับบ้าน

จะใช้เวลานานแค่ไหนกว่าจะทำให้เครื่องใหม่กลับไปอยู่ในสถานะเดิม (พร้อมทั้ง SSH Key, Configuration ของ Editor, การตั้งค่า Shell, Application ที่ติดตั้งไว้ และอื่น ๆ) เหมือนตอนที่คุณเพิ่งยกถ้วยชาถ้วยนั้นขึ้นมา? นี่คือปัญหาที่หนึ่งในพวกเราเพิ่งเจอมาไม่นานนี้เอง

แทบทุกอย่างที่กำหนด Configuration และการใช้งานของเครื่องเดิมถูกเก็บไว้ใน Version Control ทั้งหมด รวมถึง:

  • User Preference และ Dotfile ทั้งหมด
  • Configuration ของ Editor
  • รายการซอฟต์แวร์ที่ติดตั้งผ่าน Homebrew
  • Ansible Script ที่ใช้ตั้งค่า App ต่าง ๆ
  • โปรเจกต์ปัจจุบันทั้งหมด

เครื่องนี้ถูกกู้คืนสำเร็จภายในบ่ายวันนั้นเองครับ

Version Control as a Project Hub (Version Control ในฐานะ Hub ของโปรเจกต์)

แม้ Version Control จะมีประโยชน์อย่างมากกับโปรเจกต์ส่วนตัว แต่มันจะยิ่งแสดงศักยภาพเต็มที่เมื่อทำงานเป็นทีม และคุณค่าส่วนใหญ่นี้มาจากวิธีที่คุณ Host Repository ของคุณนั่นเอง

ทีนี้ Version Control System หลายตัวไม่จำเป็นต้องมี Hosting เลยด้วยซ้ำ เพราะมันเป็นแบบ Decentralized เต็มรูปแบบ ที่ Developer แต่ละคนทำงานร่วมกันแบบ Peer-to-Peer แต่ถึงจะใช้ระบบแบบนี้ ก็ยังคุ้มค่าที่จะมี Repository กลางไว้ เพราะเมื่อคุณมีแล้ว คุณจะได้ใช้ประโยชน์จาก Integration มากมายที่ช่วยให้โปรเจกต์ไหลลื่นขึ้น

ระบบ Repository หลายตัวเป็น Open Source ดังนั้นคุณสามารถติดตั้งและรันมันในบริษัทของคุณเองได้ แต่นั่นไม่ใช่ธุรกิจหลักของคุณจริง ๆ ดังนั้นเราขอแนะนำให้คนส่วนใหญ่ใช้บริการ Host จาก Third Party แทน โดยมองหา Feature อย่างเช่น:

  • Security และ Access Control ที่ดี
  • UI ที่ใช้งานง่าย
  • ทำทุกอย่างผ่าน Command Line ได้ด้วย (เพราะบางทีคุณอาจต้อง Automate มัน)
  • Build และ Test แบบอัตโนมัติ
  • รองรับการ Merge Branch ได้ดี (บางครั้งเรียกว่า Pull Request)
  • การจัดการ Issue (ควร Integrate เข้ากับ Commit และ Merge เพื่อให้เก็บ Metric ได้)
  • Reporting ที่ดี (หน้าจอแสดงผลแบบ Kanban Board ของ Issue และ Task ที่ค้างอยู่มีประโยชน์มาก)
  • การสื่อสารในทีมที่ดี: อีเมลหรือ Notification อื่น ๆ เมื่อมีการเปลี่ยนแปลง Wiki และอื่น ๆ

หลายทีมตั้งค่า VCS ของตัวเองไว้ให้เมื่อ Push เข้าไปที่ Branch หนึ่ง ๆ ระบบจะ Build ระบบ รัน Test และถ้าสำเร็จก็จะ Deploy โค้ดใหม่ขึ้น Production โดยอัตโนมัติ

ฟังดูน่ากลัวไหมครับ? ไม่หรอก ถ้าคุณตระหนักว่าคุณกำลังใช้ Version Control อยู่ เพราะคุณสามารถ Roll Back กลับได้เสมอ

Related Sections Include (หัวข้อที่เกี่ยวข้อง)

  • Topic 11, ​ Reversibility ​
  • Topic 49, ​ Pragmatic Teams ​
  • Topic 51, ​ Pragmatic Starter Kit ​

Challenges (ความท้าทาย)

  • การรู้ว่าคุณสามารถ Roll Back กลับไปยังสถานะก่อนหน้าได้ด้วย VCS เป็นเรื่องหนึ่ง แต่คุณทำมันได้จริงหรือเปล่า? คุณรู้คำสั่งที่ใช้ทำแบบนั้นอย่างถูกต้องไหม? เรียนรู้มันไว้ตั้งแต่ตอนนี้เลย อย่ารอจนกว่าจะเกิดหายนะแล้วคุณกำลังตกอยู่ภายใต้แรงกดดันครับ

  • ลองใช้เวลาคิดดูว่าจะกู้คืน Environment บน Laptop ของคุณเองอย่างไรในกรณีที่เกิดหายนะ คุณต้องกู้คืนอะไรบ้าง? หลายอย่างที่คุณต้องการก็แค่ไฟล์ Text ธรรมดา ถ้ามันยังไม่อยู่ใน VCS (ที่ Host แยกออกจาก Laptop ของคุณ) ให้หาทางเพิ่มมันเข้าไป แล้วลองคิดถึงสิ่งอื่น ๆ ด้วย: Application ที่ติดตั้งไว้ Configuration ของระบบ และอื่น ๆ คุณจะแสดงสิ่งเหล่านั้นออกมาเป็นไฟล์ Text ได้อย่างไร เพื่อให้มันถูกบันทึกไว้ได้เช่นกัน?

    การทดลองที่น่าสนใจอย่างหนึ่ง เมื่อคุณมีความคืบหน้าบ้างแล้ว คือลองหาคอมพิวเตอร์เครื่องเก่าที่คุณไม่ได้ใช้แล้วมาดูว่าระบบใหม่ของคุณสามารถใช้ตั้งค่ามันได้หรือไม่

  • ตั้งใจสำรวจ Feature ของ VCS และผู้ให้บริการ Hosting ปัจจุบันของคุณที่คุณยังไม่ได้ใช้ดูบ้าง ถ้าทีมของคุณยังไม่ใช้ Feature Branch ลองทดลองนำมันเข้ามาใช้ดู เช่นเดียวกับ Pull/Merge Request, Continuous Integration, Build Pipeline หรือแม้แต่ Continuous Deployment ลองดูเครื่องมือสื่อสารในทีมด้วย: Wiki, Kanban Board และอื่น ๆ ทำนองนั้น

    คุณไม่จำเป็นต้องใช้มันเลยก็ได้ แต่คุณจำเป็นต้องรู้ว่ามันทำอะไรได้บ้าง เพื่อให้คุณตัดสินใจได้เองครับ

  • ใช้ Version Control กับเรื่องที่ไม่เกี่ยวกับโปรเจกต์ด้วยเช่นกันครับ