CI ย่อมาจากคำภาษาอังกฤษว่า "Continuous Integration" แปลเป็นภาษาไทยอย่างตรงตัวได้ว่า "การบูรณาการอย่างต่อเนื่อง" หลายคนอ่านคำแปลแล้วก็ยังคงงงต่อไป เนื่องจากมันไม่ได้ตอบคำถามว่า CI คืออะไร
ก่อนจะพูดถึง CI เราลองมานึกถึงการทำซอฟต์แวร์แบบเก่าๆ กันก่อน
เมื่อพูดถึงกระบวนการพัฒนาซอฟต์แวร์ ทุกตำราต้องกล่าวถึงตำนานอันยิ่งใหญ่ของ Waterfall Model อย่างขาดไม่ได้ ขั้นตอนต่างๆ ของ Waterfall Model ประกอบไปด้วย
ผมเคยเจอข้อสอบถามประมาณว่า ทำไมการเจอข้อผิดพลาดในการทำงานของซอฟต์แวร์ก่อน จึงเสียค่าใช้จ่ายในการแก้ไขน้อยกว่าการเจอภายหลัง ผมแทบตอบไม่ถูกเลย เพราะมันเป็นสามัญสำนึกอยู่แล้ว ไม่คิดว่าจะต้องมีการอธิบายเหตุผลให้ยืดยาว
ใช่ครับ การเจอข้อผิดพลาดให้เร็วที่สุด จะช่วยลดค่าใช้จ่ายต่างๆ ที่จะตามมาได้ เราสามารถแก้ไขปัญหานั้นได้อย่างรวดเร็ว ยิ่งเจอตอนระบบยังไม่ซับซ้อน การแก้ไขก็ทำได้ง่าย การเจอหลังๆ อาจทำให้ต้องรื้อระบบใหม่เลยทีเดียว
เมื่อเรารู้แล้วว่าการรอให้ต่างคนต่างพัฒนา แล้วค่อยมารวมกันทีหลัง จะทำให้เกิดปัญหาแล้ว วิธีแก้คืออะไรครับ? ผู้อ่านลองช่วยกันคิดในใจดู
ไม่รู้ว่าทุกคนคิดเหมือนกันรึเปล่า วิธีแก้ปัญหาคือการรวม code กันให้บ่อยที่สุดที่จะเป็นไปได้ นั่นจึงเป็นที่มาของ Continuous Integration หรือเรียกย่อๆ ว่า CI
Continuous Integration คือ หลักปฏิบัติในการพัฒนาซอฟต์แวร์ หนึ่งใน Extreme Programming (XP, เป็นหนึ่งในของ Agile อีกที) ซึ่งสมาชิกในทีมจะรวบรวมงานเข้าด้วยกันบ่อยๆ วันละครั้งเป็นอย่างน้อย ไปจนถึงหลายๆ ครั้งต่อวัน ไม่เพียงแต่นำโค้ดของแต่ละคนมารวมกันเท่านั้น ยังต้องมีการทดสอบด้วยว่า ระบบที่ได้นั้นใช้การได้จริงหรือไม่ ด้วยการทำ automated test ตรงนี้จะช่วยให้เราเจอข้อผิดพลาดของระบบได้เร็วที่สุดที่จะเป็นไปได้
หลายทีมพบว่ากระบวนการนี้ช่วยลดปัญหาที่จะเกิดขึ้นเมื่อรวมระบบ และยังข่วยให้การพัฒนาเร็วขึ้นอีกด้วย
หลายทีมนี่มีใครบ้าง? อันนี้เป็นคำถามที่ยากครับ ผมคงไม่สามารถนั่งไล่ได้ว่ามีใครใช้หรือไม่ใช้บ้าง แต่จะลองยกตัวอย่างที่ดังๆ ให้แล้วกันครับ
ท่านทั้งหลายที่คร่ำหวอดในการพัฒนาซอฟต์แวร์ ต้องเคยได้ยินคำว่า nightly build อย่างแน่นอน ทำไมถึงเรียก nightly? เพราะมัน build ทุกคืนยังไงล่ะครับ นั่นแปลว่าทีมที่ทำซอฟต์แวร์ตัวนั้นมีการทำรวมระบบและทดสอบอัตโนมัติทุกวันเป็นอย่างน้อย ตัวอย่างที่เป็นที่รู้จักกันดีก็เช่น Firefox, CyanogenMod, Chromium เป็นต้น ซอฟต์แวร์ที่ยกตัวอย่างมานี้เปิดให้ผู้ใช้ดาวน์โหลด nightly build ไปลองใช้งานกันดู แต่ก็จะออกตัวกันไว้ก่อนว่ายังไม่สมบูรณ์ เพราะยังไม่ได้ทำการทดสอบอย่างจริงจังนั่นเอง
นอกจากนี้ยังมีอีกหลายบริษัทที่นำกระบวนการ CI ไปใช้งาน แต่ไม่ได้เปิดให้ผู้ใช้อย่างเราเข้าถึง build นั้น
วันนี้พอแค่นี้ก่อนแล้วกันครับ เริ่มจะยาวเกินไปแล้ว เชื่อว่าผู้อ่านคงต้องขี้เกียจอ่านกันเป็นแน่แท้ คราวหน้ามาต่อกันด้วยวิธีการทำ CI ดีกว่าครับ
ก่อนจะพูดถึง CI เราลองมานึกถึงการทำซอฟต์แวร์แบบเก่าๆ กันก่อน
เมื่อพูดถึงกระบวนการพัฒนาซอฟต์แวร์ ทุกตำราต้องกล่าวถึงตำนานอันยิ่งใหญ่ของ Waterfall Model อย่างขาดไม่ได้ ขั้นตอนต่างๆ ของ Waterfall Model ประกอบไปด้วย
- การเก็บความต้องการของผู้ใช้
- นำความต้องการที่ได้มาออกแบบให้เป็นระบบ
- ลงมือพัฒนาระบบ
- นำทุกระบบมารวมกัน
- ทดสอบ และแก้ไขข้อผิดพลาดจากการทำงาน
- นำระบบไปติดตั้ง ใช้งานจริง
- บำรุงรักษาระบบ
ผมเคยเจอข้อสอบถามประมาณว่า ทำไมการเจอข้อผิดพลาดในการทำงานของซอฟต์แวร์ก่อน จึงเสียค่าใช้จ่ายในการแก้ไขน้อยกว่าการเจอภายหลัง ผมแทบตอบไม่ถูกเลย เพราะมันเป็นสามัญสำนึกอยู่แล้ว ไม่คิดว่าจะต้องมีการอธิบายเหตุผลให้ยืดยาว
ใช่ครับ การเจอข้อผิดพลาดให้เร็วที่สุด จะช่วยลดค่าใช้จ่ายต่างๆ ที่จะตามมาได้ เราสามารถแก้ไขปัญหานั้นได้อย่างรวดเร็ว ยิ่งเจอตอนระบบยังไม่ซับซ้อน การแก้ไขก็ทำได้ง่าย การเจอหลังๆ อาจทำให้ต้องรื้อระบบใหม่เลยทีเดียว
เมื่อเรารู้แล้วว่าการรอให้ต่างคนต่างพัฒนา แล้วค่อยมารวมกันทีหลัง จะทำให้เกิดปัญหาแล้ว วิธีแก้คืออะไรครับ? ผู้อ่านลองช่วยกันคิดในใจดู
ไม่รู้ว่าทุกคนคิดเหมือนกันรึเปล่า วิธีแก้ปัญหาคือการรวม code กันให้บ่อยที่สุดที่จะเป็นไปได้ นั่นจึงเป็นที่มาของ Continuous Integration หรือเรียกย่อๆ ว่า CI
Continuous Integration คือ หลักปฏิบัติในการพัฒนาซอฟต์แวร์ หนึ่งใน Extreme Programming (XP, เป็นหนึ่งในของ Agile อีกที) ซึ่งสมาชิกในทีมจะรวบรวมงานเข้าด้วยกันบ่อยๆ วันละครั้งเป็นอย่างน้อย ไปจนถึงหลายๆ ครั้งต่อวัน ไม่เพียงแต่นำโค้ดของแต่ละคนมารวมกันเท่านั้น ยังต้องมีการทดสอบด้วยว่า ระบบที่ได้นั้นใช้การได้จริงหรือไม่ ด้วยการทำ automated test ตรงนี้จะช่วยให้เราเจอข้อผิดพลาดของระบบได้เร็วที่สุดที่จะเป็นไปได้
หลายทีมพบว่ากระบวนการนี้ช่วยลดปัญหาที่จะเกิดขึ้นเมื่อรวมระบบ และยังข่วยให้การพัฒนาเร็วขึ้นอีกด้วย
หลายทีมนี่มีใครบ้าง? อันนี้เป็นคำถามที่ยากครับ ผมคงไม่สามารถนั่งไล่ได้ว่ามีใครใช้หรือไม่ใช้บ้าง แต่จะลองยกตัวอย่างที่ดังๆ ให้แล้วกันครับ
ท่านทั้งหลายที่คร่ำหวอดในการพัฒนาซอฟต์แวร์ ต้องเคยได้ยินคำว่า nightly build อย่างแน่นอน ทำไมถึงเรียก nightly? เพราะมัน build ทุกคืนยังไงล่ะครับ นั่นแปลว่าทีมที่ทำซอฟต์แวร์ตัวนั้นมีการทำรวมระบบและทดสอบอัตโนมัติทุกวันเป็นอย่างน้อย ตัวอย่างที่เป็นที่รู้จักกันดีก็เช่น Firefox, CyanogenMod, Chromium เป็นต้น ซอฟต์แวร์ที่ยกตัวอย่างมานี้เปิดให้ผู้ใช้ดาวน์โหลด nightly build ไปลองใช้งานกันดู แต่ก็จะออกตัวกันไว้ก่อนว่ายังไม่สมบูรณ์ เพราะยังไม่ได้ทำการทดสอบอย่างจริงจังนั่นเอง
นอกจากนี้ยังมีอีกหลายบริษัทที่นำกระบวนการ CI ไปใช้งาน แต่ไม่ได้เปิดให้ผู้ใช้อย่างเราเข้าถึง build นั้น
วันนี้พอแค่นี้ก่อนแล้วกันครับ เริ่มจะยาวเกินไปแล้ว เชื่อว่าผู้อ่านคงต้องขี้เกียจอ่านกันเป็นแน่แท้ คราวหน้ามาต่อกันด้วยวิธีการทำ CI ดีกว่าครับ
Comments