[แปล] Master Branch Must Be Read-Only

อ่านเจอบทความที่น่าสนเกี่ยวกับ Continuous Integration คือ Master Branch Must Be Read-Only

โดยผู้เขียนทำการอธิบายถึงปัญหาของ Continuous Integration ที่มักพบเจอ
รวมทั้งวิธีการแก้ไขปัญหา
ดังนั้น มาดูกันว่าเขาอธิบายว่าอย่างไรกันบ้าง
ซึ่งแปลตามความเข้าใจของผมนะครับ

เริ่มต้นด้วยความเข้าใจผิดๆ เกี่ยวกับ Continuous Integration

Continuous Integration มันง่ายมากเลยนะ เพียงแค่

• ทำการ download Jenkins มาติดตั้ง
• ทำการสร้าง job/item ด้วยการ cllick click click
• จากนั้นกำหนดขั้นตอนการ build (build pipeline)
• และคิดคำสวยๆ ใน email สำหรับส่ง email เมื่อการ build มันไม่ผ่าน
• จากนั้นทำการแก้ไขข้อผิดพลาดซะ

สุดท้ายทำการ tweet หรือ post ข้อความนี้
เพื่อบอกว่าทีมคุณใช้ หรือมี Continuous Integration แล้วนะ !!

แต่เมื่อเวลาผ่านไปไม่กี่วัน มักจะพบว่า

คุณและทีม เริ่มทำการกรอง email ที่มาจาก Jenkins ออกไป
เพราะว่ามันรบกวนคุณเหลือเกิน
ดังนั้นเอามันไปทิ้งซะ

มันบ่งบอกถึงอะไรล่ะ ?
มันบอกว่าทีมพัฒนาของคุณไม่สนใจในการ build การทดสอบนะสิ
ไม่สนใจมาแก้ไขให้มันทำงานถูกต้อง
เช่น การแก้ไข unit test, code เป็นต้น

สุดท้ายทีมคุณก็จะบอกว่า unit test มันไม่น่าจะเหมาะกับเรานะ
เอามันออกไปดีไหม ?

คำถาม
คุณคิดว่าสิ่งที่คุณทำอยู่มันถูกต้องแล้วหรือ สำหรับ Continuous Integration ?

คำตอบ
มันผิดเต็มประตูเลยนะ !!

ก่อนอื่นต้องรู้ก่อนว่า Continuous Integration มันคืออะไรล่ะ

ในปัจจุบันการพัฒนา software นั้นคำว่าพัฒนาเสร็จ (Done) นั้นมันหมายความว่า
เมื่อทำการพัฒนา feature หนึ่งๆ ขึ้นมา
แล้วทำการ merge และ commit มายัง master branch
หลังจากนั้นก็จะทำการ ทดสอบระบบงาน ทั้ง unit test, integration test
และการทดสอบอื่นๆ อยู่เสมอ
ซึ่งขั้นตอนเหล่านี้เราจะเรียกว่า Continuous Integration หรือ CI

ในบางครั้งอาจจะ build ไม่ผ่าน เช่นมีบางการทดสอบผิดพลาด
ซึ่งนั่นคือข้อดีของ Continuous Integration
ทำให้เราเห็นปัญหา เพื่อแก้ไขให้ถูกต้อง
มันคือการควบคุมคุณภาพของ software นั่นเอง

ซึ่งการแก้ไข หรือ การพัฒนา ควรที่จะ build บนเครื่องของนักพัฒนา
เพื่อไม่ให้มันผิดพลาด
จากนั้นทำการ merge และ commit code
ก่อนที่ระบบ Continuous Integration จะทำซ้ำในขั้นตอนที่คุณทำบนเครื่อง

ในปัจจุบันมีเครื่องมือ
สำหรับสร้างระบบ Continuous Integration มากมาย เช่น

• Jenkins
• Go
• Teamcity
• CruiseControl

และยังมี Cloud service อีก เช่น

• Travis
• Drone
• Wercker

ผมทำการเขียน blog เกี่ยวกับ Continuous Integration ไว้เช่นกันลองอ่านเพิ่มเติมดูครับ

ทำไม Continuous Integration มันถึงไม่ค่อย work ล่ะ ?

Continuous Integration นั้นมันดีมาก
แต่เมื่อทีมพัฒนาใหญ่
มีความซับซ้อนสูง
มีการ build บ่อยๆ
และการ build ส่วนใหญ่มักจะเกิดข้อผิดพลาด
และการแก้ไขมักใช้เวลานานมากๆ
บางคนก็มักจะไม่สนใจ หรือ ignore ส่วนที่ผิดพลาดนั้นไป !!

หรือบางคนอาจจะบอกว่า ฉันไม่มีเวลามาแก้ไขหรอกนะ
เพราะว่ามีงานอื่นที่มีความสำคัญสูงกว่าต้องทำนะ

ซึ่งแน่นอนว่า Product Owner หรือเจ้าของ product
ไม่รู้หรอกว่า การ build ที่มันผ่านอยู่เสมอ (Clean build) มันมีความสำคัญอย่างไร
และไม่มีเวลาการแก้ไข unit test หรอกนะ

แต่ว่า code ของเรานั้นมันอยู่ใน master branch แล้วนะ !!
บ่อยครั้ง เรามักพบว่า code เหล่านี้
จะถูก deploy ขึ้นไปยัง production server
เพื่อให้ผู้ใช้งานเข้ามาใช้งาน
และก็มักจะเกิด Urgent bug/incident ให้แก้ไขอยู่อย่างสม่ำเสมอ
นี่หรือเรียกว่า การส่งมอบ product ที่มีคุณค่าทาง business ?

สุดท้าย ทีมพัฒนา
ก็ไม่ได้ให้ความสนใจ หรือ สำคัญ กับ Continuous Integration
ว่ามันจะทำงานผิดพลาดอย่างไร
มันกลายเป็นเหมือนแฟชั่น ที่ทุกทีมต้องมีเท่านั้นเอง
แต่ไม่ได้ให้ความสนใจใดๆ
ดังนั้นจะมีระบบ Continuous Integration ไปทำแมวอะไร !!

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

จะทำการแก้ไขปัญหานี้อย่างไรดีล่ะ ?

ทางผู้เขียนบทความนี้บอกไว้ว่า วิธีการเขียนไว้ใน paper
เรื่อง Prevent Conflicts in Distributed Agile PHP Projects 

ซึ่งอธิบายได้ง่ายๆ ดังนี้

ไม่อนุญาติให้ใครทำการ merge code มายัง master branch
นั่นคือ คุณไม่สามารถ push code มาได้นะ
แต่จะทำการสร้าง script เพื่อให้ทุกๆ คน run เมื่อต้องการจะ merge code
โดยที่ script นี้จะทำการ merge, test และ commit ให้
ถ้าเกิดข้อผิดพลาดขึ้นมาจะไม่ทำการ commit code มายัง master branch เลยเด็ดขาด
นั่นคือ เราสามารถรู้ปัญหาก่อนเสมอ
ดังนั้นปัญหามันจะลดลงไปได้เยอะเลย ใช่ไหม ?

แน่นอนว่า ในช่วงเริ่มต้นการใช้งานวิธีนี้

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

ส่วนวิธีการอื่นๆ เช่น Pull Request
แต่ผมคิดว่า มันจะกลายเป็นจุดที่เกิดปัญหาคอขวดได้นะ
แต่ก็สามารถลองใช้งานดูได้ครับ

ปล.
สังเกตได้ว่า ปัญหามันเกิดจากวินัย
และความเข้าใจต่อสิ่งที่กำลังทำ
ซึ่งจำเป็นต้องให้ทุกๆ คนที่เกี่ยวข้องเข้าใจ และ เห็นความสำคัญของมัน
ไม่เช่นนั้นก็เหมือนเป็นการบังคับ ที่ใครๆ ก็ไม่ต้องการมัน
ถึงแม้ว่า มันจะดีเพียงใดก็ตาม