กระบวนการพัฒนาซอฟต์แวร์แบบเดิมๆ นั้นหากมีการควบคุมคุณภาพ เราก็มักจะรวบรวมฟีเจอร์ต่างๆ จากทีมพัฒนาเข้ามารวมกันเป็นรอบๆ แล้วส่งทีมควบคุมคุณภาพเพื่อทดสอบและหาบั๊กในโค้ดที่กำลังพัฒนาต่อไป กระบวนการเช่นนี้ทำให้โปรแกรมเมอร์อาจจะต้องรอเป็นเวลานาน กว่าจะรับรู้ว่าฟีเจอร์ที่ตัวเองพัฒนาไปนั้นไปสร้างบั๊กให้กับโครงการโดยรวมในจุดอื่นๆ หรือไม่ ทำให้แนวทาง Continuous Integration (CI) ได้รับความสนใจขึ้นมามากในช่วงหลัง
แนวทาง CI คือการสร้างระบบที่รวบรวมโค้ดจากนักพัฒนาเข้ามาเป็นชุดเดียวกันอย่างต่อเนื่อง โดยไม่ปล่อยให้โค้ดที่อยู่ในมือนักพัฒนาแต่ละคนต่างกันนานเกินไป แนวทางนี้มักรวบเข้ากันกระบวนการทดสอบซอฟต์แวร์โดยอัตโนมัติ (automated test) ที่ทำให้โค้ดที่ถูกรวมเข้าไปถูกทดสอบว่าสามารถทำงานตามเงื่อนไขได้อย่างถูกต้อง
ซอฟต์แวร์ CI มักเชื่อมต่อกับระบบเก็บซอร์สโค้ด เมื่อมีการส่งโค้ดเข้าโครงการ เช่น นักพัฒนาคนหนึ่งส่ง pull request เข้ามาเพื่อส่งฟีเจอร์ใหม่ ระบบจะนำโค้ดนั้นไปคอมไพล์และรันทดสอบว่าผ่านดีหรือไม่โดยอัตโนมัติ ผู้ดูแลโครงการสามารถเห็นรายงานเบื้องต้นว่าคุณภาพโค้ดยอมรับได้ ตัวซอฟต์แวร์ที่ทำงานเช่นนี้มีหลายตัวในตลาด ระบบจัดเก็บซอร์สโค้ดอย่าง GitLab นั้นมีฟีเจอร์ CI ในตัว หรือบริการคลาวด์หลายตัวก็เริ่มให้บริการ CI บ้างแล้ว เช่น Azure Pipelines หรือแพลตฟอร์ม Kubernetes อย่าง OpenShift ก็มีฟีเจอร์ OpenShift Pipelines
การจัดหาซอฟต์แวร์ที่เหมาะสมก็เป็นความท้าทายอย่างหนึ่ง แต่การพัฒนาซอฟต์แวร์ที่จะใช้ประโยชน์จากแนวทาง CI ได้อาจจะต้องปรับตัวกันตั้งแต่กระบวนการออกแบบซอฟต์แวร์ที่เปิดให้สร้างระบบทดสอบอัตโนมัติได้โดยง่าย และหน้าที่ของคนในทีมที่ต้องทำงานโดยมองระบบอัตโนมัติเป็นสำคัญ
– – –
โดยคุณลิ่ว วสันต์ ลิ่วลมไพศาล
Chief Technology Officer, MFEC
