คำสามคำที่ได้รับความสนใจมากในปัจจุบันก็คือ Agile, Devops และ Automation
ดังนั้น เรามาดูกันหน่อยว่า มันเกี่ยวข้องกันอย่างไร
และมีอะไรที่เราต้องเรียนรู้และศึกษากันบ้าง

ธุรกิจในปัจจุบัน
ต้องสามารถขับเคลื่อนบนการเปลี่ยนแปลงที่รวดเร็วได้
ต้องสามารถทำได้ดีกว่า ด้วยการลงทุนหรือการลงแรงที่น้อยกว่า
ต้องสามารถผลิตของที่มีคุณภาพออกมาได้อย่างรวดเร็ว
ต้องการเป็นผู้นำ และ ประสบความสำเร็จ มากกว่า

แน่นอนว่าเมื่อคู่แข่งทำการปล่อยของที่มีความสามารถใกล้เคียงกับสิ่งที่คุณมีอยู่
หรือมีความสามารถที่เหนือและดีกว่า
โอกาสที่จะสูญเสียลูกค้า ก็มีสูงเช่นกัน

ดังนั้น สิ่งที่คุณต้องการ คือ วิธีการที่จะทำให้คุณสามารถปรับตัว
และรองรับกับการเปลี่ยนแปลงได้อย่างรวดเร็ว
และต้องมาพร้อมกับคุณภาพที่ยอดเยี่ยมด้วย
ดังนั้น คำว่า Agile จึงเริ่มถูกพูดถึง หรือ นำมาใช้งานกันมากขึ้น

ในปัจจุบัน คุณไม่สามารถรอครึ่งปี เพื่อรอให้ถึงเวลาการ release ของทั้งหมดได้
เนื่องจากการทำงานของคุณไม่สามารถแบ่งออกมาได้ … Waterfall
ดังนั้นทางฝ่าย IT หรือส่วนที่เกี่ยวข้องหลักกับการพัฒนา Software จึงได้คิด Agile ขึ้นมา

Devops นั้นเกิดมาเพื่อพยายามเชื่อมโยงระหว่างทีมพัฒนา กับ ทีม operation
เพื่อให้ทำงานสอดคล้องกันได้อย่างดี

ดังนั้นเมื่อต้องการรีดประสิทธิภาพของ Agile และ Devops ออกมาแล้วนั้น
จำเป็นต้องการให้ process ต่างๆ ทำงานแบบอัตโนมัติ ( Automation )

แต่ถ้าคุณยังทำการ deployment และ release แบบ manual อยู่แล้วล่ะก็
แน่นอนว่าคุณจะเจอการทำงานตามขั้นตอนแบบเดิมๆ
การทำผิดซ้ำๆ แบบเดิม
ความผิดพลาดต่างๆ ที่เกิดขึ้นอย่างมากมายล้วนมาจาก มนุษย์
รวมทั้ง ไม่สามารถรองรับการทำงานซ้ำบ่อยๆ ได้

ดังนั้นแนวปฎิบัติเหล่านี้ จึงถูกคิดขึ้นมาตามลำดับ คือ

  1. Continuous Integration
  2. Continuous Delivery
  3. Continuous Deployment

เป็นแนวปฎิบัติพื้นฐาน ที่จะขาดไปไม่ได้เลยสำหรับการทำงานแบบอัตโนมัติ (Automation)
โดยเริ่มต้องแต่วินัยในการพัฒนา คือ build -> test -> release

แนวคิดเหล่านี้ไม่ได้ใหม่เลย แต่ถูกทำให้เห็นภาพชัดขึ้น
หรือประโยชน์ที่ชัดขึ้นมา เมื่อคำว่า Agile เริ่มเป็นที่นิยมแพร่หลาย

แต่พวก Continuous Integration, Continuous Delivery และ Continuous Deployment นั้น
ก็ไม่สามารถนำไปใช้ได้กับทุกๆ ที่ หรือเหมือนกันในทุกๆ ที่
เนื่องจากจะต้องทำความเข้าใจก่อนว่า process และ culture ของแต่ละที่เป็นอย่างไร
แล้วจึงนำไปประยุกต์ใช้งาน
ดังนั้นจะไม่มีคำว่า How คือ ทำอย่างไร
แต่จะมีเพียงคำว่า What คือ อะไร เท่านั้น

ดังนั้นเรามาดูว่า แต่ละอย่างมันคืออะไรกัน

1. Continuous Integration (  CI )

3Fig2

ถูกสร้างขึ้นมาเพื่อลดความเจ็บปวดจากปัญหาการรวมส่วนต่างๆ ของระบบ เพื่อทำงานร่วมกัน ( integration )
โดยในโลกของการพัฒนานั้น มักใช้ Build server มาช่วยเพื่อให้เป้าหมายที่ตั้งไว้สำเร็จ
กล่าวคือ จะเริ่มทำการ integration กันตั้งแต่เมื่อมีการเปลี่ยนแปลง sourcecode ที่ repository กลาง
ระบบจะทำการตรวจสอบ code หลังจากการเปลี่ยนแปลงว่าทำงานร่วมกันได้หรือไม่
ตั้งแต่ compile, testing โดยการ testing จะเริ่มตั้งแต่ unit testing
ซึ่งสร้างจากทีมพัฒนา และเป็นส่วนจะใช้ตรวจสอบว่าสิ่งที่ทีมพัฒนายังทำงานถูกต้อง
และที่สำคัญจะมีเวลาการทำงานสั้น นั่นหมายถึงทีมพัฒนาจะได้ feedback กลับไปอย่างรวดเร็ว

ในขั้นตอนต่อมาอาจจะทำการตรวจสอบคุณภาพของ sourcecode
ก่อนที่จะทำการทดสอบแบบ integration test, acceptance test
ซึ่งช่วยเหลือในการทำ regression test
โดยกระบวนการเหล่านี้ทำเพื่อตรวจสอบเรื่องของคุณภาพ
และต้องทำงานแบบอัตโนมัติอีกด้วย

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

2. Continuous Delivery ( CD )

หลังจาก Continuous Integration แล้วต่อมาก็คือ Continuous Delivery
คนเราแสวงหา คำว่า efficiency, lean และ Agile อยู่เสมอ
ดังนั้น จำเป็นต้องมีการวางแผนและสุมหัวหาทางกันว่า
จะทำอย่างไรดี เพื่อทำให้ทุกๆ การเปลี่ยนแปลงมันพร้อมที่จะ release ได้เสมอ
ซึ่งนั่นหมายถึงต้องผ่านกระบวนการต่างๆ มาด้วยคุณภาพที่สูง

ตัวอย่างภาพของขั้นตอนใน Continuous Delivery ซึ่งจะต้องทำการแบบอัตโนมัติ
และสุดท้ายต้องได้รับการ approve จากคนที่มีอำนาจในการ release
ในการ release นั้นมักจะเรียกว่า One Click to Release/Deploy ( Manual นั่นเอง )

Fig3-small

ดังนั้นถ้าคุณปฎิบัติตาม Continuous Delivery แล้วจะทำให้คุณมั่นใจได้ว่า
คุณสามารถ release ของได้ตลอดเวลา ตามความต้องการของทาง business
เพื่อทำให้สามารถแข่งขันกับชาวบ้านเขาได้

3. Continuous Deployment ( CD )

Fig4-small

จะเป็นสิ่งที่เป็นขั้นกว่าของ Continuous Delivery  เนื่องจากไม่มีการมา approve ด้วยคนอีกต่อไป
ซึ่งแน่นอนว่า นั่นคือ ความเสี่ยงแรกที่เรามองเห็นได้อย่างชัดเจน
และยิ่งที่ฝั่ง business เองก็ยิ่งไม่มองว่ามันไม่ make sense เลย
ตัวอย่างเช่นงานของระบบธนาคาร เมื่อ developer ทำการ push code ขึ้น repository แล้ว
ระบบจะทำการ build -> test -> deploy ขึ้น production server ทันที
โดยไม่ต้องผ่านการ approve ใดๆ ทั้งสิ้น

…. คุณคิดว่ามันเป็นไปได้ไหม ผมจิตนาการไม่ออกเลยว่าจะเป็นไปได้อย่างไร ….

แล้วในปัจจุบันใครบ้างล่ะที่ทำกันอยู่ เช่น Facebook, Amazon ไงล่ะ
แต่ไม่ใช้จะ deploy ขึ้นทีเดียวทั้งหมด แต่เข้าได้ใช้เทคนิคอื่นๆ เข้ามาช่วย
เช่นการทำ A/B testing บน production สำหรับความสามารถใหม่ๆ
เพื่อทำให้มั่นใจว่า การเปลี่ยนเปลงเหล่านั้นมีคุณภาพจริงๆ
ก่อนที่ละ release ให้กับทุกๆ คนหรือทั้งระบบใช้งาน
ดังนั้นมาถึงตรงนี้ deployment != release นะครับ

คำถามต่อมา แล้วเราจะวัดได้อย่างไรว่าเราประสบความสำเร็จในการสร้างขึ้นตอนทั้ง 3 แบบขึ้นมา ?

คำตอบนั้นง่ายๆ มาก ลองตรวจสอบว่าหลังจากที่ทำแล้ว มีคำตอบในหัวข้อต่างๆ อย่างไร ?

  1. การตอบรับกับการเปลี่ยนแปลงรวดเร็วขึ้นไหม
  2. แก้ไขระบบเพียงเล็กน้อย นั่นคือ คุณภาพของ code ดี และ สามารถ release งานได้รวดเร็ว
  3. จำนวนของ defect บน production น้อยลง ถ้ามีจำนวนน้อยแสดงว่า การ release นั้นมีความเสถียรและมีประสิทธิภาพ
  4. ระหว่างทีมพัฒนาและ operation มีการทำงานร่วมกันที่ดีขึ้น

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

สุดท้ายแล้ว
ลองจิตนาการดูว่า ถ้าเราสามารถ automate ได้ทุกๆ ขั้นตอน แล้ว
สินค้า service ของเราจะดูดีเพียงใด สามารถตอบรับกับความต้องการที่เปลี่ยนแปลงได้เร็วเพียงใด
ลูกค้า ผู้ใช้ จะมีความสุขขึ้นมาเพียงใด

แล้วปัจจุบัน คุณทำแบบไหนกันอยู่ ……