มาอย่างต่อเนื่องกับอีก Session ที่สนุกเพราะแปะมีมตลอดทางกับ Deploy Production every sprint!? Is it possible? ใน ODDS| CONF 2024 ซึ่งเอาตรง ๆ ตอนนิลอ่านหัวข้อครั้งแรกนิลก็แบบ มันจะเป็นไปได้หรอวะ ส่งของให้ User ใช้ Sprint ละครั้ง แต่สำหรับพี่จี๊บแห่ง ODDS| กับทีมของเขาแล้ว มันเป็นไปได้ครับ ทีมพี่เขาทำได้วิธีไหน มารู้ไปพร้อม ๆ กันครับ
- สิ่งที่จะพี่ิจี๊บเล่าต่อไปนี้เป็นแค่ประสบการณ์ที่พี่เขาเจอ ไม่ได้แปลว่าใช้ได้กับทุกที่ แค่มาเล่าสู่กันฟัง
- ทีมทำ Product Jago มี Active User 14M คน มีทีมย่อยข้างใน 3 ทีม
- ทีมทำงานกันในรูปแบบ LeSS แต่ยังไม่ Fully LeSS (ขอแรกตัวเองว่ายังเป็น LeSS Practitioner)
- ด้วยวิธีการทำงานแบบ LeSS ทำให้เกิดการกระจาย Knowledge ทั้งทีม
- วิธี Development ที่เลือกใช้คือ Trunk-Based Development ก็คือทุก ๆ คนทำงานกันที่ Branch Main/Master เพื่อให้ทุก ๆ คนได้ Code ที่อัปเดทและ Stable อยู่เสมอ
- แล้วเมื่อไหร่เราจะกล้าเอาของขึ้น Branch Master/Main ล่ะ ก็คือเราต้องเขียน Test Coverage ไว้ 100%
- แต่เอาจริง ๆ Test Coverage 100% ยากมาก เอาเป็นว่าถ้าเราสามารถนอนหลับสนิทได้โดยไม่ต้องพะวงว่า Code เราจะไปบึ้มบน Production หรือเปล่า = Coverage ดีแล้ว 55555
- เวลาจะทำ Feature เพิ่ม ต้องคิดเผื่อ Backward Compatibility เช่น มือถือเครื่องเก่า ๆ ยังต้องใช้งานได้
- สิ่งหนึ่งที่สามารถช่วยทำ Backward Compatibility ได้คือการทำ Feature Toggle (หรือที่ชาวบ้านเรียกกันว่า Feature Flag)
- เสร็จแล้วจะมี Process ในการ Deploy ขึ้น Staging เพื่อให้ QA ทำ Regression Testing ต่อไป
- เมื่อ QA นั่งทำ Manual Regression Testing เสร็จ แต่ละทีมก็ต้องส่งคนไปประสานกับ QA ว่า Feature ที่แต่ละทีมทำไปมี Bug อะไรไหม
- พอ Regression Testing เยอะ ๆ และนั่งทำกัน Manual เกิด Pain ขึ้นทำให้ทีมเริ่มทำ Automation E2E Testing กันเพื่อช่วยลด Pain ให้ QA
- ทีมคุยงานกันผ่าน gather.town ทำให้ทีมเอาผลการทำ E2E Testing มา Integrate กับ gather ให้ต้นไม้ 1 ต้น = 1 Case ถ้า Pass ต้นไม้เป็นสีเขียว ถ้า Fail ต้นไม้เป็นสีแดง
- หลัง Test เสร็จก็จะยิง Meeting ที่ชื่อว่า “Go/No-Go Meeting” เพื่อมาคุยร่วมกันว่าของที่จะเอาขึ้นมีอะไรบ้างและของที่จะเอาขึ้นมี Known Issues อะไรบ้าง เพื่อตัดสินใจว่าจะ Go (Deploy ขึ้น Production) หรือ No-Go (ยังไม่ Deploy)
- นอกจากนี้ยังคุยกันถึงวัน Deploy ด้วยเพื่อหลีกเลี่ยงวันที่อาจจะมี Traffic เข้ามาเยอะ เช่น ไม่ Deploy ช่วงสงกรานต์
- ถ้ามี Known Issues ที่ Product Owner ยอมรับได้ ทุกคนโอเคหมด ก็ Let’s Go เข้า Process เอาขึ้น Prod ละะ
- ในขั้นตอนการ Deploy ตอนแรกใช้ GitLab CI แต่ทีมเจอ Tool ที่ดีกว่านั่นคือ Harness
- ดีกว่ายังไง? ดีกว่าเพราะสามารถทำ Canary Deployment ได้
- แล้ว Canary Deployment คืออะไร มันคือการ Deploy App เราไปใช้ User แค่กลุ่มนึงใช้ก่อน แล้วพอเราได้ Feedback จาก User กลุ่มนั้นมาแล้วว่า App ทำงานได้ปกติ เราก็จะ Deploy App ไปให้ User ที่เหลือใช้
- Process ที่เล่ามาจะใช้เวลาประมาณ 8 วันทำการ นานที่ Regression Testing
- ปัจจัยที่ทำให้เกิดการ Deploy Prod ทุก Sprint ได้คือการที่คิดเผื่อ Backward Compatibility, การมี Team Collaboration, การ Share Knowledge กันในทีม, การมี Test Coverage และ Regression Testing, มีการ Monitor กันและการทำ Canary Deployment
- พี่จี๊บเล่าให้ฟังว่าปีนึงแล้วจะเกิดเหตุการณ์ No-Go ขึ้นปี 2-3 ครั้ง ซึ่งจะเกิดขึ้นเมื่อ Known Issue นั้นใหญ่มากจน Product Owner ไม่ปล่อยผ่าน
ฟังแล้วแบบ Inspired มาก อยากเอาของขึ้น Production ทุก Sprint เลย 55555