ปัญหาของ Staging
- pre-live ไม่เหมือนกับโปรดักชัน
- เกิดคิวสำหรับการรีลีส
- รีลีสมีขนาดใหญ่เกินไป
- ขาดความเป็นเจ้าของต่อการเปลี่ยนแปลง
- ปล่อยให้กระบวนการมารับผิดชอบแทนคน
วิธีที่ Squeaky ทำการ Ship
- merge เฉพาะสิ่งที่พร้อมขึ้น live เท่านั้น: ทดสอบการเปลี่ยนแปลงอย่างเพียงพอในสภาพแวดล้อมพัฒนาแบบ local
- ใช้กลยุทธ์ branching แบบ flat: เมื่อฟีเจอร์พร้อมสำหรับการ merge ให้ rebase และทดสอบ หากเกิดปัญหาให้ roll forward
- ฟีเจอร์ที่มีความเสี่ยงสูงใช้ feature flag เสมอ
- deploy แบบแมนนวล: เฝ้าติดตามอย่างต่อเนื่องหลังการเปลี่ยนแปลง มี monitoring/logging/alarm ครอบคลุมโดยรวม ใช้การ deploy แบบ blue/green
สรุป
- หากละทิ้งสภาพแวดล้อม staging เพื่อทำ CI/CD อย่างแท้จริง ก็จะสร้างวิธีคิดอีกแบบหนึ่งในการ shipping ซอฟต์แวร์ได้
- หากไม่มีบัฟเฟอร์ก่อนที่การเปลี่ยนแปลงจะขึ้น live ก็ต้องมั่นใจว่าการเปลี่ยนแปลงนั้นเหมาะสมกับโปรดักชัน
- ต้องมีความเป็นเจ้าของและใส่ใจกับทุกการเปลี่ยนแปลงที่ตนเองทำ
- ช่วยลดต้นทุนและความซับซ้อนของอินฟราสตรักเจอร์ และทำให้วงจรการพัฒนาง่ายขึ้นและเร็วขึ้น
3 ความคิดเห็น
พอนึกถึงความรู้สึกอุ่นใจที่เคยได้รับจากการสร้างสภาพแวดล้อม staging ภายในองค์กรแล้ว ก็เลยยังไม่ค่อยรู้สึกคล้อยตามเท่าไร
ถึงอย่างนั้นก็เห็นด้วยกับข้อเสียอย่างการที่การปล่อยใช้งานล่าช้า หรือมีการเปลี่ยนแปลงสะสมมากขึ้น
ผมคิดว่าแค่การมีสภาพแวดล้อม staging อยู่ก็มีความหมายแล้ว เพราะทำให้ตรวจสอบได้ว่าสามารถ deploy ไปยังสภาพแวดล้อมอื่นได้ และตอบโจทย์ธรรมชาติของซอฟต์แวร์ที่ต้องสามารถทำซ้ำหรือคัดลอกได้หรือไม่
อืม ผมก็ไม่แน่ใจนะว่าควรไปพึ่งพาเรื่อง "ความเป็นเจ้าของ" / "ความใส่ใจ" ของคนที่ยังไม่สมบูรณ์แบบหรือเปล่า อย่างน้อยการขอความช่วยเหลือจากคอมพิวเตอร์ที่ทำงานได้อย่างสมบูรณ์แบบตามที่สั่ง ก็น่าจะเป็นสิ่งที่โปรแกรมเมอร์คอมพิวเตอร์ควรทำไม่ใช่เหรอครับ
แล้วก็ถ้าขยายแนวคิดออกไป
สเตจจิง = ใช้สำหรับการอนุมัติขั้นสุดท้าย (เช็กว่าในท้ายที่สุดมันตรงกับสเปกที่เราคุยกันไว้ไหม หรือพอใส่ข้อมูลโปรดักต์จริงแล้วหน้าตามันน่าเกลียดกว่าที่คิด ฯลฯ เป็นการตรวจเช็กในลักษณะนี้)
เดฟ = ใช้สำหรับการพูดคุยเรื่องคนที่เกี่ยวข้องอย่างนักพัฒนาและเรื่องฟีเจอร์ (ใช้เดโม)
แบบนี้อยู่ครับ
อืม.. ผมคิดว่าปัญหาแบบนี้ก็ขึ้นอยู่กับว่ากำลังพัฒนาบริการประเภทไหนอยู่ด้วย
ไม่ว่าจะทดสอบมากแค่ไหนก็ยังอาจเกิดปัญหาได้ และต้องพิจารณาว่าผู้ใช้จะยอมรับสิ่งนั้นได้หรือไม่
ซอฟต์แวร์อย่าง Facebook ที่ถึงจะทำงานผิดพลาดบ้าง ผู้ใช้ก็อาจมองว่าเป็นเรื่องปกติ วิธีแบบนี้ก็พอทำได้
แต่ถ้าเป็นโครงสร้างพื้นฐานที่สำคัญต่อภารกิจ หรือเป็นบริการแบบเสียเงิน ก็ควรเตรียมการอย่างเต็มที่เพื่อไม่ให้เกิดปัญหาครับ