ปรับปรุงคุณภาพของ Software ด้วย Continuous Integration Process กันนะ

วันนี้มีโอกาสได้แบ่งปันความรู้เรื่อง Continuous Integration (CI) สำหรับปรับปรุงคุณภาพของการพัฒนา Software ให้ดีขึ้น โดยหัวใจของ CI นั้นประกอบไปด้วย 2 คำคือ

1. Continuous หรือ Frequent คือ ทำบ่อย ๆ อย่างต่อเนื่อง
2. Integrate หรือ Merge คือ การรวมกันของสิ่งต่าง ๆ ในระบบ

รวมกันก็หมายความว่า ให้ทำการรวมกันบ่อย ๆ อย่างต่อเนื่อง มีคำถามที่น่าสนใจคือ

• อะไรที่ต้องนำมารวมกันบ้าง ?
• ทำการรวมกันที่ไหน ?

ตอบได้ง่าย ๆ คือ

• source code ไงล่ะ
• รวมกันที่ Version Control System หรือ Repository ไงละ

ดังนั้น CI เป็นกระบวนการที่นำการเปลี่ยนแปลงต่าง ๆ ของ source code ไปรวมกันไว้ที่ Version Control System บ่อย ๆ และ อย่างต่อเนื่อง

ปล. ถ้าใครไม่ใช้งาน Version Control System เช่น Git, SVN เป็นต้น ก็น่าจะบาปอย่างแรงส์ !!

สิ่งที่ขาดไม่ได้เลยในกระบวนการของ CI คือ คำว่าคุณภาพ

เราจะรู้ได้อย่างไรว่า แต่ละการเปลี่ยนแปลงนั้น

• ระบบยังสามารถทำงานได้อย่างถูกต้องหรือไม่ ?
• ระบบยังสามารถทำงานได้ตามความคาดหวังหรือไม่ ?

ขอเน้นย้ำว่าทุกการเปลี่ยนแปลงนะ หนึ่งในนั้นคือ การทดสอบนั่นเอง แน่นอนว่า ต้องเป็นการทดสอบแบบอัตโนมัติอย่างแน่นอน (Automated testing) ไม่ว่าจะเป็น Unit testing, Integration testing และ Functional testing ส่งผลให้สามารถทดสอบได้บ่อย ๆ ส่งผลให้สามารถรู้สถานะของระบบได้ตลอดเวลา ส่งผลให้ได้ feedback ของระบบอยู่อย่างเสมอ ไม่ว่าจะดีหรือร้าย ทำให้ทุกคนเห็นความคืบหน้าของการพัฒนา

มาดูกันหน่อยว่าขั้นตอนใน CI ควรเป็นอย่างไรบ้าง ?

อาจจะเรียกว่า Continuous Integration Process หรือบางคนอาจจะเรียกว่า Build pipeline ซึ่งผมขออธิบายตั้งแต่เรื่องพัฒนาของ Developer แต่ละคนกันเลย มีขั้นตอนดังนี้

1. Developer แต่ละคนต้องสามารถ build, test และ run ระบบที่เครื่องตัวเองได้
2. เมื่อทำการพัฒนา feature เสร็จ แน่นอนว่าต้องมีชุดการทดสอบแบบอัตโนมัติด้วยเสมอ
3. Developer ต้องทำการ build, test และ run บนเครื่องของตัวเอง เพื่อทำให้แน่ใจว่าระบบทำงานได้ถูกต้อง
4. Developer ต้องทำการ build, test และ run บนเครื่องของตัวเอง เพื่อทำให้แน่ใจว่าสิ่งที่เปลี่ยนแปลงไม่กระทบส่วนอื่น ๆ
5. ให้ทำการดึง source code ล่าสุดจาก Repository ของระบบ เพื่อตรวจสอบว่ามีการเปลี่ยนแปลงหรือไม่
6. ถ้ามีการเปลี่ยนแปลงก็ให้ทำการรวม หรือ merge ที่เครื่องของ Devleoper ก่อน จากนั้นจึงทำการ build, test และ run อีกรอบ
7. แต่ถ้าเกิดปัญหา หรือ ข้อขัดแย้งต่าง ๆ ก็ให้ทำการแก้ไขที่เครื่อง Developer ก่อนเสมอ
8. เมื่อทุกอย่างผ่านทั้งหมด ให้ทำการส่งการเปลี่ยนแปลงไปยัง Repository กลาง
9. เมื่อ Repository กลางมีการเปลี่ยนแปลง จะต้องมีระบบ CI ทำการ build, test และ run อีก เพื่อทำให้มั่นใจต่อระบบ
10. แต่ถ้าเกิดความผิดพลาดบนระบบ CI จะทำการแจ้งไปยังทีมพัฒนา เพื่อให้ทุกคนหยุด เพื่อทำการแก้ไขให้ผ่าน
11. เมื่อทุกอย่างบนระบบ CI ทำงานเรียบร้อยก็สามารถส่งผลลัพธ์ไปยังส่วนการทำงานอื่นต่อไป เช่น การทดสอบ และ การ deploy หรือส่งต่อไปยังระบบ Continuous Delivery เป็นต้น

โดยกระบวนการต่าง ๆ เหล่านี้ น่าจะทำให้เรา ทีม และ คนอื่น ๆ มีความเชื่อมั่นต่อระบบมากขึ้น บางครั้งอาจจะช่วยลดคำพูดต่าง ๆ ลงไปเยอะ เช่น

• ระบบจะไม่พังจริง ๆ หรอ ?
• สิ่งที่แก้ไขจะไม่กระทบส่วนอื่น ๆ จริงหรอ ?
• เสร็จจริง ๆ หรอ ?
• .....

มาดูประโยชน์ของ Continuous Integration กันบ้าง

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

ถ้าอยากรู้ว่าจริงหรือไม่ ก็ให้ลงมือทำด้วยมือของตัวเองสิ

ปล. การทดสอบแบบอัตโนมัตินั้น ควรครอบคลุมทั้ง Functional และ Non-functional requirement

โดย Continuous Integration (CI) นั้น

เป็นพื้นฐานที่สำคัญอย่างยิ่งของ Continuous Delivery และ Continuous Deployment ทำให้เราพร้อมที่จะ deploy และ release ระบบงานได้ตามที่ต้องการ โดยเรื่องคุณภาพนั้นมันไม่สามารถต่อรองได้เลย ต้อง Build-in อยู่ในทุกขั้นตอนของการพัฒนา สามารถอ่านเรื่อง 10 แนวปฏิบัติที่ดีของ Continuous Integration ได้ ปิดท้ายด้วยเรื่องของเครื่องมือสำหรับระบบ CI ก็ลองไปดูเพิ่มเติ่มได้ที่ List of CI Tools

แต่เหนือสิ่งอื่นใดทุกสิ่งทุกอย่างมันถูกสร้างมาจากคน ดังนั้นเรื่องคุณภาพของคนจึงสำคัญอย่างมาก