มีโอกาสไปร่วมงาน Meetup ของทาง ThoughtWorks Tech Talks ประจำเดือนมีนาคม
ในหัวข้อเรื่อง CI/CD pipeline :: The Good and The Bad
ซึ่งมีหลายเรื่องที่น่าสนใจ เพื่อนำมาประยุกต์ใช้งาน
จึงทำการสรุปไว้นิดหน่อย
ทุกสิ่งทุกอย่างมันเริ่มต้นจากปัญหา
ดังนั้นเราต้องรู้ปัญหาก่อนว่า คืออะไร ?
แต่บางครั้งเราอาจจะเจอปัญหาอยู่
แต่ปัญหามันดันเป็นข้อจำกัด หรือ ความเคยชินก็เป็นไปได้ !!
ดังนั้นเราต้องมองไปที่ Business goal/value
นั่นคือทำอย่างไรที่บริษัทจะส่งมอบ product ไปถึงมือ customer ให้เร็วและมีคุณภาพที่ดี นั่นคือเรื่องของ time-to-market และส่งมอบบ่อย ๆ
แต่ในบาง business ก็ไม่ต้องการส่งมอบบ่อย ๆ นะ !!
เน้นไปที่เรื่องของคุณภาพของการพัฒนาและส่งมอบ
ซึ่งปัญหาที่เจอบ่อย ๆ คือ Overhead ในเรื่องของการส่งมอบหรือ release ระบบงาน
ถึงแม้ว่าเราจะทำงานเป็นรอบสั้น ๆ แล้ว แต่ Overhead ของการ release ยังคงสูง
และสูงขึ้นอย่างต่อเนื่อง
ทำให้ยิ่งทำงานรอบสั้น ๆ มากเท่าไร
เวลาการเตรียม release จะสูงเป็นถึง 50% ของเวลาการพัฒนาทั้งหมด !!
ดังนั้นเราควรต้องหาวิธีการลด overhead ในเรื่องนี้ลงมาให้ได้มากที่สุด
เมื่อเห็นปัญหาแล้ว สิ่งที่ต้องเริ่มทำหรือหาคือ pipeline ของการทำงาน
เน้นในส่วนของการพัฒนาไปจนถึงการ deploy มามีขั้นตอนอะไรบ้าง ?
เช่น
- การ build
- การทดสอบ
- การ package software
- การ deploy
จากนั้นพยายามแทนที่การทำงานแบบ manual ด้วยการทำงานแบบอัตโนมัติ
มีประโยคที่น่าสนใจคือ
“Automate what your care about “
อะไรที่คุณใส่ใจแล้วให้มันทำงานแบบอัตโนมัติซะ
เพราะว่าคนเรามักทำความผิดพลาดได้เสมอ
คำถามที่น่าสนใจคือ แล้วในขั้นตอนหรือ pipeline นั้นต้องมีอะไรบ้าง ?
มันมีหลายมุมมองเช่น Risk profile ของระบบงาน ว่ามีความเสี่ยงอะไรบ้าง ?
ค่าของ MTBF (Mean Time Between Failure)
คือเวลาตั้งแต่สร้างจนถึงเวลาที่รู้ว่ามัน fail หรือผิดพลาดนานเพียงใด ยิ่งนานยิ่งแย่
ดังนั้นจำเป็นต้องทำให้ลดลง เพื่อให้เราแก้ไขได้อย่างรวดเร็ว
นั่นคือ pipeline ที่ดีต้องให้ feeback ที่เร็วและมีคุณภาพ
ใน meetup ยกตัวอย่างของ pipeline ของระบบงานมีขั้นตอนดังนี้
- Code linting
- Unit test
- Security scan เช่น dependency check
- Build/package
- Deploy to Dev
- End-to-end test / UI test
- Performance test
- Pen test
- Deploy to production
ปัญหาที่ตามมาของขั้นตอนต่าง ๆ ข้างต้นคือ
มันทำงานนานมาก ๆ ทำให้ feedback ที่ได้มาช้ามาก ๆ !!
แทนที่จะเข้ามาช่วย ดันก่อให้เกิดปัญหาอีก
ดังนั้นจำเป็นต้องแก้ไขคือ แบ่งการทำงานของ pipeline ออกมาคือ
- อะไรบ้างที่ต้องทำเมื่อทำการ commit/push code ซึ่งต้องเร็ว
- อะไรที่ไม่จำเป็นต้องทำทุก ๆ การเปลี่ยนแปลง เพราะว่าช้า เช่น End-to-End test, performance test และ Pen test ให้ทำงานเป็น schedule ซะ เช่นทุกชั่วโมง ทุกวัน เป็นต้น
ทุกอย่างที่บอกมา มันดีนะ แต่ว่าเรายังไม่พร้อม !!!
เป็นข้ออ้างที่เจอบ่อยมาก ๆ
ทั้งไม่มีชุดการทดสอบ
ทั้งไม่มีการ deploy แบบอัตโนมัติ
ทั้ง … เยอะแยะไปหมด
สิ่งที่แนะนำคือ ให้เริ่มจากสิ่งที่ทีมใช้ก่อน
ยกตัวอย่างเช่น
การ build ให้เริ่มจากการทำ script การ build ก่อน
การ deploy ให้เริ่มจาก deploy script ไปยัง Dev server ก่อน
เช่นการเขียน Ansible playbook เป็นต้น
ทำให้ทีม ให้ทีมลองใช้ ให้ทีมเห็นค่า
ว่ามันช่วยให้ชีวิตดีขึ้นนะ เป้าหมายเพื่อให้ทีมติดใจ
ถ้าเป็นไปตามเป้า การขยายไปยังขั้นตอนอื่น ๆ ก็ง่ายแล้ว
ประเด็นหลัก ๆ คือ ต้องทำให้เห็นคุณค่าของสิ่งที่ทำขึ้นมา
มิฉะนั้นมันก็จะหายไปเช่นเดิม
อีกประเด็นที่น่าสนใจคือ เมื่อเกิดปัญหาหรือ pipeline
แจ้งว่าเกิดข้อผิดพลาด แต่ไม่มีใครสนใจ นี่คือสิ่งหนึ่งที่เกิดขึ้นบ่อยมาก ๆ
มันเกิดจากความไม่เข้าใจ ไม่เห็นประโยชน์
หนักกว่านั้นคือ มันไม่ใช่หน้าที่
ดังนั้นจาก Principle ข้อหนึ่งของ Continuous Integration (CI) คือ
เมื่อเกิดข้อผิดพลาดแล้วให้ทุกคนในทีมหยุด และมาช่วยกันแก้ไข
เป็นสิ่งหนึ่งที่ขาดไม่ได้เลย
ดังนั้นจำเป็นต้องสร้างข้อตกลงกันนะ
เรื่องต่อมาคือ ความน่าเชื่อถือของ Pipeline
เมื่อระบบงานใหญ่ขึ้น Code มากขึ้น
ชุดการทดสอบมากขึ้น
ขั้นตอนมากขึ้น
ปัญหาที่ตามมาคือ การทำงานของ pipeline ไม่เสถียร
คือทำงานผ่านบ้างไม่ผ่านบ้าง ทั้ง ๆ ที่ยังไม่ทำอะไรเลย
ยกตัวอย่างเช่น ทดสอบไม่ผ่าน
ยิ่งเป็นการทดสอบที่มี dependency เยอะ ๆ ยิ่งมีปัญหาบ่อย
รวมทั้งทำงานช้าอีกด้วย
เรื่องของการทดสอบจึงต้องให้ความสำคัญกับ Test Pyramid ให้มาก
แต่ถ้าทำแบบไม่เข้าใจมันจะเกิดปัญหาดังรูป Cupcake
คือเกิด Silo ในการทำงานน
นั้นคือแต่ละทีมก็ต่างคนต่างทำไป
ทำให้เกิดชุดการทดสอบซ้ำกันมากมาย
สิ่งที่ควรทำคือ ลดหรือทำลาย Silo นี้ซะ
พูดง่ายแต่ทำไม่ง่ายเลย
เนื่องจากมันคือ เรื่องของความไว้เนื้อเชื่อใจล้วน ๆ
มันไม่ใช่เรื่องของเทคโนโลยีอะไรเลย
สุดท้ายสิ่งที่เราควรทำก่อนคือ
หาเส้นทางไปยังการ deploy สู่ production ให้เจอ
จากนั้นเริ่มออกแบบสร้าง pipeline ของเราขึ้นมาแบบ incremental
แต่ pipeline ที่สร้างต้องมี feedback loop ที่สั้นและเร็ว
รวมทั้งต้องมีคุณภาพอีกด้วย
