เมื่อต้นเดือนเมษายน ทาง Engineer ของ Instagram ได้เขียนบนความของการทำ Continuous Deployment ภายในระบบของเค้า http://engineering.instagram.com/posts/1125308487520335/continuous-deployment-at-instagram

เราจะมาดูกันว่ามีอะไรน่าสนใจบ้าง [ผมแปลแบบสรุปไปด้วยนะครับ ดังนั้นอาจจะไม่ใช่การแปลแบบแป๊ะๆ]

ทำไปทำไม?

Continuous Deployment นั้นมีข้อดีมากมายๆนะครับ ใครไม่รู้จักคำนี้และทำงาน Software Development ที่มีระบบขนาดกลาง/ใหญ่ (ที่มี Developers มากกว่า 10 ละกัน) ควรจะลองศึกษาดู

1. ทำให้ Developers/Engineers ทำงานได้เร็วขึ้น สามารถที่จะแก้ไขอะไรได้รวดเร็วมากขึ้น
2. ทำให้ช่วยในการหาข้อผิดพลาดที่เกิดจากการแก้ไขตัวระบบได้เร็วขึ้น จากที่จะต้องมาดูสิ่งที่แก้ไขที่มีเยอะแยะ ก็มาดูแค่รายครั้งที่มีการ Deploy ในแค่ละครั้ง
3. สิ่งที่ Commit แล้วมีปัญหาก็จะเจอได้รวดเร็วและยังแก้ได้เร็วด้วย

การนำไปใช้

ทาง Instagram นั้นใช้วิธี iterative approach ก็คือไม่ใช้ว่าทำระบบที่เดียวเสร็จแล้วใช้งานทันที แต่จะใช้การค่อยๆพัฒนาทีละจุดไปเรื่อยๆจนกระทั่งเสร็จสมบูรณ์

ก่อนหน้านี้เป็นยังไง

ก่อนที่ทาง Instagram จะมี Continuous Deployment นั้น Engineer จะใช้การ Deploy ตามใจและเวลาที่จะมีการแก้ไข รวมถึงต้องรู้การเช็ค Log และเริ่มการ Deploy ที่ละเครื่องเพื่อทำการทดสอบก่อนที่จะ Deploy ไปที่เครื่อง Servers ที่เหลือ

การทดสอบ/เทส

เริ่มจากการเพิ่มการเทสซึ่งเป็น Script ง่ายๆที่ทาง Engineer ต้องทำจากที่ต้องทำบนเครื่องที่ตั้งใจจะลงบน Production ก็เปลี่ยนมาเป็นทำการ Deploy ที่เครื่อง Canary Machine(เครื่องสำหรับให้ users ทดลองใช้)

จากนั้นมีการสร้างเครื่องที่ทำการทดสอบจาก Git – Master โดยใช้ Jenkins เมื่อเทสของ version ไหนผ่านก็จะมีการแนะนำว่าควรใช้ version นั้นแทนที่จะเป็น version ล่าสุด

การทำงานอัตโนมัติ

เนื่องจากระบบข้างบนแล้ว สิ่งที่ยังเหลือว่าจะต้องให้คนตัดสินใจก็คือ

1. จะเอา version ไหนไปใช้ในการ Deploy – ซึ่งทาง Instagram ก็เลือกใช้ version ที่ผ่านการทดสอบและมีการเปลี่ยนแปลงไม่เกิน 3 commits
2. การ Deploy สำเร็จหรือไม่ – หลักการก็คือถ้าไม่สามารถ Deploy ไปที่ servers ได้ด้วยอัตรา 1% จะถึงว่าไม่สำเร็จ

ปัญหา

หลังจากที่ทาง Instagram ได้ทำมาก็พบว่ามีปัญหาใหญ่ๆคือ

เทสไม่ผ่าน

หลายๆครั้งที่ทาง Engineer ได้พบว่ามีการแก้ไข software ที่ทำให้การเทสไม่ผ่าน ซึ่งทำให้ไม่สามารถ Deploy ได้ ซึ่งการแก้ไขนั้นต้องทำการ revert แบบ Manual รวมถึงการเทสที่ใช้เวลานานและไม่ค่อยเสถียร ซึ่งทาง Engineer ก็ได้ทำการแก้ไขให้เทสได้เร็วขึ้นเป็น 5 นาทีจาก 15 นาที

สิ่งที่จะ Deploy

ทาง Instagram พบว่าสิ่งที่จะต้อง Deploy มีมากในคิว เนื่องจากว่าระบบ Canary สามารถดักจับปัญหาได้(ทั้งปัญหาจริง และบั๊ก) ซึ่งทำให้การ Deploy หยุด และต้องมีการแก้ไขด้วย Engineer เพื่อให้ระบบ Automation ทำงานต่อได้ ซึ่งทำให้เกิดการล่าช้าของการ Deploy สิ่งใหม่ๆ ซึ่งทาง Engineerได้แก้ไขปัญหานี้ด้วยการปรับปรุงเงื่อนไขในการทำ Automation deploy ให้ทำงานได้ดีมากขึ้น

หลักการที่แนะนำ

ทาง Instagram ยังได้แนะนำว่าถ้าอยากได้ระบบแบบของเค้า ให้ลองตามนี้

1. การเทส

   ระบบเทสต้องเร็วและครอบคลุม แต่ไม่จำเป็นต้องสมบูรณ์ และต้องถูกใช้งานบ่อยๆ ทั้งตอน Code Review, ก่อนการ Deploy และหลังจาก Deploy

2. Canary

   ต้องมีการทำ automated canary เพื่อที่จะป้องกันไม่ให้มีการ commit ที่ไม่ดีเข้าไปอยู่ในสิ่งที่จะ Deploy ลงบน Server ทุกเครื่อง

3. Automated Test สำหรับการทำงานปกติ

   ไม่จำเป็นต้องมี automate ทั้งหมด แต่เฉพาะสิ่งที่สำคัญจริงๆและเป็นสิ่งที่เกิดขึ้นในเหตุการณ์ปกติ

4. ทำให้คนรู้สึกมั่นใจ

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

5. คิดไว้เลยว่าต้องเจอการ Deploy ไม่สำเร็จ

   อาจจะมีโอกาสที่จะมี version ที่ไม่ดีหลุดออกไปบน Production ซึ่งเป็นเรื่องที่ยอมรับได้ แต่ระบบจะต้องตรวจเจอได้เร็วและสามารถแก้ไข้แต่เร็วด้วย

ขั้นต่อไป

1. ทำให้เร็วยิ่งขึ้น
2. เพิ่ม Canary
3. เพิ่มข้อมูล
4. ปรับปรุงการดักจับข้อผิดพลาด