Agile Sixty-Six Rotating Header Image

Continuous integration คืออะไร

ผมลอง search ดูแล้ว ยังไม่มีใครเขียนถึง CI แบบจริงจัง เลยเอาจากที่ blog ส่วนตัวมาลงตรงนี้ด้วยนะครับ

 

เรื่องนี้ไม่ใช่เรื่องใหม่ครับ แต่ผมลอง search google ด้วย ประโยคเหมือนชื่อโพสแล้วไม่มีผลลัพธ์ดีๆ ภาษาไทยใน 2 หน้าแรกเลย ก็เลยมาเขียนให้อ่านกัน

เนื้อหาในโพสนี้ เขียนจากประสบการณ์ส่วนตัว ประกอบกับ แปลและสรุปจาก Continuous Integration ครับ

ใครอ่านตรงไหนไม่รู้เรื่องแล้วอยากให้อธิบายเพิ่มเติมก็ถามมาได้นะครับ

ปัญหา

  1. การ merge code ระหว่าง dev ยาก ใช้เวลานาน
  2. Dev พัฒนาอยู่บน code ส่วนที่ถูกคนอื่นลบหรือเลิกใช้ไปแล้ว
  3. Dev ไม่กล้าแก้ code มากนัก เพราะกลัวจะกระทบคนอื่นและกลัว bug ส่งผลให้ code เน่าง่าย
  4. เมื่อมีคนมาถามถึงความเสถียรของโปรแกรม ตอบได้แค่ว่า “น่าจะใช้งานได้”
  5. ผลจากความผิดพลาดของการ merge ถูกพบเมื่อ code ขึ้นไปอยู่บน production แล้ว
  6. Code บน dev environment ไม่สามารถ deploy บน production environment ได้ หรือได้แต่ใช้เวลานาน
  7. Regression test ใช้เวลานาน และนานขึ้นเรื่อยๆ ตามความแก่ของโปรเจ็ค
  8. Management รู้ความก้าวหน้าของโปรเจ็คได้แค่จากปากคำของ Dev
  9. เมื่อเจอ bug ในระบบเวอร์ชั่นเก่ากว่าที่พัฒนาอยู่ ใช้เวลา setup เครื่องเพื่อทดสอบ bug นาน

วิธีแก้ไข

0. Dev ทุกคนเขียน unit test และมี acceptance test คลุมฟังก์ชัน

  1. ทำงานชิ้นเล็กๆ merge บ่อยๆ ทำเสร็จชิ้นนึง merge ทันที
  2. พัฒนาบน branch เดียวกันทุกคนในโปรเจ็ค
  3. ตรวจสอบว่า test รันผ่านก่อน commit/push ขึ้น repository กลาง
  4. มีระบบ automate สำหรับดึง source code มา build , นำลงเครื่องที่เหมือนเครื่อง production ที่สุด และรัน test ใหม่อีกรอบ ทุกครั้งที่ source code มีการเปลี่ยนแปลง แจ้งผลลัพธ์อย่างชัดเจน ทันที
  5. ทำ versioning ไฟล์ build
  6. แก้ test ที่พังอย่างรวดเร็ว ให้ความสำคัญการแก้ test ที่พังเป็นอันดับต้นๆ

ผลลัพธ์

  1. merge code กันเครียดน้อยลง
  2. ได้ code ที่พร้อมใช้งานตลอดเวลา regression test time เข้าใกล้ 0
  3. ไม่เสียแรงเปล่าไปทำงานบนส่วนที่เลิกใช้ไปแล้ว
  4. ได้ code ที่ไม่มี bug ที่เคยแก้ไปแล้วเกิดซ้ำ
  5. พบ bug ได้เร็วขึ้น ทำให้หาสาเหตุได้ง่ายขึ้น
  6. Dev กล้าที่จะ refactor code มาขึ้น
  7. โปรแกรม version ใหม่ๆ ออกเร็วขึ้น
  8. ไม่ต้องมาเครียดในการ deploy ขึ้น production โดยเฉพาะอย่างยิ่งวันท้ายๆ กำหนด release
  9. Dev เครียดน้อยลง รู้สึกว่าทำงานแล้ว “เสร็จ” จริงๆ
  10. Management เห็นความก้าวหน้าการทำงานของ dev ในแต่ละวันด้วยผลลัพธ์การ test ที่เพิ่มขึ้นทุกวันๆ
  11. สามารถ build ระบบขึ้นจาก version ใดก็ได้อย่างรวดเร็ว

สิ่งที่จำเป็น

  1. วินัยของ Dev
  2. การตัดแบ่งงานเป็นชิ้นเล็กๆ ต้องใช้ความสามารถในด้านการเขียนโปรแกรมให้เป็น modular และ refactoring
  3. เทคนิคการเขียน test ทำให้เทสได้เร็ว ครอบคลุม
  4. การทำระบบ build ให้ทำงานได้อย่างรวดเร็ว

เพิ่มเติม

บางบริษัทไปไกลถึงขั้นหลังจาก build และ test แล้ว นำขึ้น deploy บน production เลย ตามอ่านได้จาก keyword Continuous Deployment, Continuous Delivery ครับ

ของแถม

Tools for Continuous Integration at Google Scale ด้านเทคนิคเค้าไปไกลกว่าที่ผมเขียนมามากครับ

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Plugin from the creators of Brindes :: More at Plulz Wordpress Plugins