ในการพัฒนา software ได้นำเอาแนวคิด Continuous Integration(CI) เข้ามาใช้งาน ซึ่งผมคิดว่าเป็นสิ่งที่ขาดไม่ได้เลย เพื่อช่วยทำให้ทีมทำการ integrate บ่อย ๆ เพื่อช่วยทำให้ software ที่สร้างค่อย ๆ เติบโตอย่างยั่งยืน เพื่อช่วยทำให้ทีมได้รับ feedback กลับมาอย่างรวดเร็วทั้งดีและร้าย เพื่อจะได้แก้ไขและปรับปรุงได้อย่างทันท่วงที แต่สิ่งที่น่าแปลกใจก็คือ ไม่นำการทดสอบ (Testing) เข้ามาร่วมทำงานกับ Continuous Integration !!
เมื่อมีการพูดถึงคำว่า Continuous Integration (CI) และ Continuous Delivery (CD) แล้ว คนส่วนใหญ่มักจะคิดถึง หรือ พูดถึงเครื่องมือต่าง ๆ ก่อน ไม่ว่าจะเป็น Jenkins บ้างล่ะ ไม่ว่าจะเป็น Bamboo บ้างล่ะ ไม่ว่าจะเป็น Travis CI บ้างล่ะ ไม่ว่าจะเป็น Circle CI บ้างล่ะ ไม่ว่าจะเป็น Docker บ้างล่ะ ไม่ว่าจะเป็น Ansible บ้างล่ะ
เรามักจะได้ยินคำว่า Fail Fast Lea[r]n Fast ในการพัฒนา software แบบ incremental และ interactive นั้นเราต้องการ feedback ที่รวดเร็วที่สุดเท่าที่จะทำได้ เพื่อทำให้เรารู้ว่า สิ่งที่ทำอยู่นั้นมันถูกต้อง และ เป็นสิ่งที่ต้องการ ในการพัฒนา software เราต้องการรู้สิ่งต่าง ๆ เหล่านี้อย่างรวดเร็ว สิ่งที่เราสร้างทำงานได้อย่างถูกต้อง ? สิ่งที่คนอื่นสร้างทำงานได้อย่างถูกต้อง ? เมื่อ deploy ระบบงานแล้วยังทำงานได้ ? สิ่งที่พัฒนานั้นมันตรงกับความต้องการของลูกค้า ? ทำให้ business มันดีขึ้น ? ดังนั้นเรามาตอบคำถามต่าง ๆ เหล่านี้กันดีกว่า
วันนี้มีโอกาสได้แบ่งปันความรู้เรื่อง Continuous Integration (CI) สำหรับปรับปรุงคุณภาพของการพัฒนา Software ให้ดีขึ้น โดยหัวใจของ CI นั้นประกอบไปด้วย 2 คำคือ Continuous หรือ Frequent คือ ทำบ่อย ๆ อย่างต่อเนื่อง Integrate หรือ Merge คือ การรวมกันของสิ่งต่าง ๆ ในระบบ รวมกันก็หมายความว่า ให้ทำการรวมกันบ่อย ๆ อย่างต่อเนื่อง มีคำถามที่น่าสนใจคือ อะไรที่ต้องนำมารวมกันบ้าง ? ทำการรวมกันที่ไหน
ตอนนี้ Jenkins 2.0 Preview ถูกปล่อยออกมาเพื่อให้ทดสอบใช้งานกันแล้ว โดยใน version ใหม่นี้ทำการปรับปรุงความสามารถหลายอย่าง ทั้งเรื่องของ Delivery pipeline ซึ่งจัดการด้วย code กันเลย การติดตั้งแบบใหม่ มีให้เลือก plugin ก่อนด้วย ทำการปรับปรุง User Interface และ Usability ต่าง ๆ อีกด้วย ยังทำงานกับ version เก่า ๆ ได้ ดังนั้นมาดูรายละเอียดในแต่ละข้อกันดีกว่า
จากหนังสือ Beautiful Builds ทำการอธิบายเกี่ยวกับ Time to Main หรือ Time to Trunk ซึ่งเป็นสิ่งที่ใช้วัดเรื่อง Continuous Integration มาดูกันว่า Time to Main มันคืออะไร ? และมันใช้วัดอย่างไร เพื่ออะไร
จากบทความเรื่อง Model everything to fail fast ทำการอธิบายเกี่ยวกับ การออกแบบ workflow สำหรับ Fail Fast ได้อย่างน่าสนใจ ทุก ๆ ครั้งที่ทีมพัฒนาทำการแก้ไขสิ่งต่าง ๆ ไม่ว่าจะเป็น code ไม่ว่าจะเป็น database ไม่ว่าจะเป็น automated testing ไม่ว่าจะเป็น infrastructure ไม่ว่าจะเป็น deployment script ไม่ว่าจะเป็น configuration file เราต้องใช้เวลานานเท่าไร กว่าจะรู้ว่าสิ่งที่แก้ไขไปนั้นมันถูก หรือ ผิด
Stripe คือ payment service สำหรับระบบที่ต้องการจ่ายเงินผ่าน internet โดยทีมพัฒนาทำการเขียนบทความเรื่อง การลดเวลาทดสอบจาก 3 ชั่วโมงเหลือเพียง 3 นาที ซึ่งในบทความมีแนวคิดที่น่าสนใจมากมาย ดังนั้น เรามาดูกันหน่อยสิ ว่ามีวิธีการอย่างไรบ้าง
หนึ่งในแนวปฏิบัติของ Extreme Programming (XP) ที่ได้รับความนิยมอย่างสูงนั่นก็คือ Continuous Integration (CI) ซึ่งมันได้เข้ามาเป็นส่วนหนึ่งของการพัฒนา software ไปแล้ว ลองคิดดูสิว่า ถ้าคุณขาด CI ไปแล้ว คุณจะพัฒนา software ได้อย่างไร ? ในปัจจุบัน มีระบบ และ เครื่องมือ สำหรับการสร้างระบบ CI มากมาย ตั้งแต่ขั้นตอนการ build, test, deploy และ monitoring แต่แปลกนะ !! ปัญหาก็ยังเกิดขึ้นมากมาย แม้จะมีระบบ CI แล้วก็ตาม ดังนั้นลองมาตรวจสอบกันหน่อยสิว่า ระบบ CI ของคุณเป็นอย่างไรกันบ้าง ? เพื่อใช้เป็นแนวทางในการปรับปรุง และ ลดปัญหาต่าง ๆ ที่เกิดขึ้น
ทีมพัฒนาระบบ Payment ของ LinkedIn ทำการเขียนบทความอธิบายขั้นตอนการพัฒนาไว้ที่ Getting Code to Production With Less Friction and High Quality โดยหัวใจของบทความนี้คือ Release ระบบให้บ่อยๆ แต่ละ Release ต้องมีคุณภาพที่สูง ดังนั้น เรามาดูกันว่าเขาทำอย่างไรบ้าง