ปัญหาในการพัฒนา software ส่วนใหญ่ที่พบเจอคือ

“It didn’t work in production”

นั่นคือทุกอย่างมันจะดูดีมาก ๆ 
เมื่อไม่ทำการ deploy ไปยัง production server !!

สาเหตุของความผิดพลาดประกอบไปด้วยอะไรบ้าง ?

  • มีขั้นตอนที่ยุ่งยาก มากมาย
  • มี script ต้อง run เยอะ
  • ทำการ deploy แบบ manual

หมายความว่า
เรากำลังหลอกตัวเองอยู่ตลอดเวลาใช่ไหม
ว่าระบบงานของเราเสร็จแล้ว
และพร้อมทำการ deployเพื่อส่งมอบระบบงานไปให้ผู้ใช้งาน !!

ดังนั้นเราน่าจะต้องมีกระบวนการและระบบอะไรบางอย่าง
มาช่วยจัดการเรื่องเหล่านี้นั่นคือ
ที่มาที่ไปของ Continuous Delivery
และเหล่าเครื่องมือต่าง ๆ ให้ใช้งาน

เมื่อมีขั้นตอนและเครื่องมือสำหรับการส่งมอบระบบงานที่ดีแล้ว

ทั้งการ reproduce software ขึ้นมาใหม่
ทั้งการนำ automation process มาใช้
ทั้งการนำ automation test มาใช้
ทั้งการนำ automation deployment มาใช้

แต่เมื่อมาดูที่ระบบงานพบว่า

Architecture ของระบบนั้นยังเป็น Monolith และ service ย่อย ๆ มีขนาดใหญ่
ทำให้เมื่อมีการเปลี่ยนแปลงในครั้งหนึ่ง ๆ
ต้องทำการ build, test และ deploy ระบบเกือบจะทั้งหมดพร้อม ๆ กัน
รวมทั้งอาจจะยังต้องมี manual process บางอย่างอีกด้วย
เช่นการเปิดปิด firewall หรือพวก load balance
หรือหนักกว่านั้น 
การ rollback เมื่อการ deploy มีความผิดพลาด ทำได้ยาก
การทดสอบในระดับ UI พังง่าย หรือไม่เสถียรเลย    
การส่งมอบและ deploy ยังเป็นแบบ Big bang

ทำให้เกิดแนวคิดในการแก้ไขปัญหาเหล่านี้ขึ้นมา

ทั้ง Microservices
ทั้ง Infrastructure as a Code
ทั้ง Testing framework ใหม่ ๆ ที่ช่วยให้การทดสอบมีความเสถียรมากขึ้น

ส่งผลให้เกิดคือ
แยก service ใหญ่ ๆ ออกเป็น service เล็ก ๆ
โดยแต่ละ service จะมีขั้นตอนการทำงานตั้งแต่ build, test และ deploy ไปเลย
แสดงดังรูป

แต่แนวทางของ Microservices ก็มีปัญหาเช่นกัน

เนื่องจากในแต่ละ service ต้องมีทีมที่ดูแล
แต่ละคนจะต้องมีความสามารถในเรื่องต่าง ๆ ที่จำเป็นต่อการพัฒนาและส่งมอบระบบ
ทั้ง Dev, QA/Tester และ Operation เป็นต้น
ทำงานร่วมกัน ไปด้วยกัน มีเป้าหมายเดียวกัน
เพื่อส่งมอบระบบที่มีคุณภาพสูงและรวดเร็ว
นี่มันคือแนวคิด DevOps ใช่ไหม ?

ที่สำคัญกระบวนการทำงานและเครื่องมือก็เปลี่ยนไป

เพื่อให้เหมาะสมกับงานและคนอีกด้วย  ประกอบไปด้วย

  • Develop และ Build เช่น CI/CD pipeline, Container (Docker, Kubernetes), Feature toggle และ Trunk-based development
  • Test ประกอบไปด้วย Unit, Integration, Component, Contract และ End-to-end testing
  • Deploy จาก script หรือ manual process เปลี่ยนมาเป็น declarative deployment แทน ทำให้ repeat ได้ง่ายขึ้น (Help, Ks) รวมไปถึง strategy ในการ deploy เพื่อลดเวลา downtime เช่น Rolling update, Blue green deployment และ Canary deployment ไปจนถึง dynamic environment อีกด้วย
  • Monitor  เช่น observability ต่าง ๆ คือ Centralize logging, Distributed tracing และ Metric ต่าง ๆ ของระบบ

โดยแต่ละส่วนนี้ จำเป็นต้องมีความปลอดภัย (Security) ด้วย
เพื่อป้องกันการโจมตีหรือบุกรุกในจุดต่าง ๆ
รวมทั้งเรื่องการจัดการ secret ต่าง ๆ

Reference Websites