กลยุทธ์การส่งเสริมการพึ่งพา: siled หรือ orchestrated

เรามีแอพพลิเคชั่นและบริการบนเว็บมากมาย (ผลิตภัณฑ์สาธารณะบางผลิตภัณฑ์, ภายในและส่วนหนึ่งของ "แบ็กเอนด์" ส่วนตัว) ที่พึ่งพาซึ่งกันและกัน แต่ละองค์ประกอบเหล่านี้มี 4 สภาพแวดล้อม (กลุ่มของเซิร์ฟเวอร์ / โหนดที่ให้บริการตามวัตถุประสงค์เฉพาะ):

• ที่ไม่ใช่การผลิต
  • DEV- สภาพแวดล้อมการพัฒนาแบบบูรณาการที่ CI สร้างการเปลี่ยนแปลงแบบพุช มีประโยชน์สำหรับวิศวกรในการแก้ปัญหาข้อบกพร่องที่หายากที่ไม่สามารถทำซ้ำได้
  • QA - แยก QA / สภาพแวดล้อมการทดสอบ
  • DEMO - สภาพแวดล้อมของ UAT ที่เสถียรสำหรับผู้มีส่วนได้เสีย
• การผลิต
  • LIVE - สภาพแวดล้อมสด / การผลิตของเรา

รหัสโปรโมชั่ไป: LOCAL(เครื่องของนักพัฒนา) => DEV=> QA=> =>DEMOLIVE

บอกว่าเรามีโปรแกรมที่เรียกว่าmyappที่มีการสนับสนุนจากบริการเว็บ RESTful เรียกว่าmywsที่ตัวเองได้รับการสนับสนุนโดย DB mydbที่เรียกว่า

ขณะนี้เรามีสิ่งที่ผมจะเรียกว่า " บงการ " โปรโมชั่นในหมู่อ้างอิงเหล่านี้คือmyapp-devจุดที่จะต้องซึ่งการใช้งานmyws-dev mydb-devในทำนองเดียวกันmyapp-qaชี้ไปที่การใช้งานmyws-qa mydb-qaเดียวกันและDEMOLIVE

ปัญหาของเรื่องนี้คือเมื่อใดก็ตามที่ฉันทำการเปลี่ยนแปลงพูดmyappสิ่งนี้ต้องให้ฉันทำการเปลี่ยนแปลงmywsและmydbเช่นกัน แต่เนื่องจากแต่ละDEVสภาพแวดล้อมชี้ไปที่สภาพแวดล้อมของการอ้างอิงDEVมันหมายความว่าฉันต้องกำหนดเวลาและวางการเปลี่ยนแปลงเหล่านี้ทั้งหมดในเวลาเดียวกัน นอกจากนี้หากการสร้างหนึ่งไม่เสถียร / แตกมันมักจะทำให้ส่วนประกอบต้นน้ำอื่น ๆ ล่ม ตัวอย่างเช่นถ้าแบ่งสิ่งที่นักพัฒนาเมื่อมีการเปลี่ยนmydb-devที่myws-devและmyapp-devกลุ่มที่มักจะยังไม่แน่นอน

เพื่อแก้ปัญหานี้ฉันกำลังรวบรวมข้อเสนอสำหรับสิ่งที่ฉันเรียกว่ากลยุทธ์การส่งเสริมการขาย " เงียบ ": การพึ่งพาระหว่างองค์ประกอบทั้งหมดเป็นไปตามแนวทางนี้:

• อ้างอิงต้นน้ำขึ้นอยู่กับDEMOสภาพแวดล้อมสำหรับการอ้างอิงปลายน้ำของพวกเขาสำหรับทุกสภาพแวดล้อมที่ไม่ใช่การผลิตของพวกเขา ( DEV, QAและDEMO); และ
• อัพสตรีมพึ่งพาขึ้นอยู่กับLIVEสภาพแวดล้อมสำหรับการพึ่งพาดาวน์สตรีมของพวกเขาสำหรับสภาพแวดล้อมการผลิตของพวกเขา

โดยใช้การประชุมนี้myapp-devจะ actuall ชี้ไปซึ่งจะใช้myws-demo mydb-demoในทำนองเดียวกันmyapp-qaก็จะชี้ไปและmyws-demomydb-demo

ข้อดีที่ฉันสามารถหาได้คือสร้างความเสถียร : มีโอกาสน้อยกว่ามากที่DEMOสภาพแวดล้อมสำหรับองค์ประกอบเฉพาะจะไม่เสถียรเนื่องจากรหัสไม่สามารถทำได้DEMOโดยไม่ต้องทำการทดสอบอย่างเข้มงวดทั้งในDEVและQAนอก

เสียอย่างเดียวที่ฉันสามารถหาวิธีนี้คือว่าถ้าDEMOไม่หยุดพักเป็นส่วนประกอบโดยเฉพาะอย่างยิ่งทุกสภาพแวดล้อมที่ไม่ใช่การผลิตสำหรับการอ้างอิงต้นน้ำทั้งหมดจะจู่ ๆ ก็ถูกทำลาย แต่ผมจะตอบโต้ว่าเรื่องนี้ควรจะเกิดขึ้นไม่ค่อยมากเพราะของการทดสอบดำเนินการบนและDEVQA

นี้ได้เป็นปัญหาที่นักพัฒนาหลายคน (ที่มีประสบการณ์มากอย่างชาญฉลาดและกว่าตัวเอง) มีการแก้ไขและฉันจะไม่ต้องแปลกใจถ้าปัญหานี้และการแก้ปัญหาอยู่แล้วมีชื่อให้กับพวกเขา (นอกเหนือจากสิ่งที่ฉันเรียกบงการ / siled) ดังนั้นฉันจึงถามว่า: ข้อดีของกลยุทธ์การส่งเสริมการขายแบบเงียบมีค่ามากกว่าข้อเสียใด ๆ และข้อเสียที่ฉันอาจมองเห็นที่นี่คืออะไร?

หากฉันอ่านโพสต์ของคุณถูกต้องดูเหมือนว่าข้อเสนอนี้จะแก้ไขปัญหาที่กล่าวมาไม่ได้

เมื่อใดก็ตามที่ฉันทำการเปลี่ยนแปลงพูด myapp สิ่งนี้ต้องการให้ฉันทำการเปลี่ยนแปลงกับ myws และ mydb เช่นกัน แต่เนื่องจากสภาพแวดล้อม DEV แต่ละจุดชี้ไปที่สภาพแวดล้อม DEV ของการพึ่งพามันหมายความว่าฉันต้องกำหนดเวลาและเริ่มการเปลี่ยนแปลงเหล่านี้ทั้งหมดในเวลาเดียวกัน

"กลยุทธ์การส่งเสริมการขายที่เงียบ" ดูเหมือนว่าจะทำให้เรื่องนี้แย่ลงเท่านั้น หาก myapp v2, myws v2 และ mydb v2 เป็นเพียง DEV เท่านั้นและ myapp v2 อาศัย mydb v2 เพื่อไม่ให้ทำงานผิดพลาดจากนั้นเมื่อฉันพยายามเรียกใช้ myapp v2 บน DEV ฉันจะกด mydb v1 DEMO แล้วจึงขัดข้อง คุณจะต้องถูกบังคับให้ต้องแทนที่ไซโลอย่างต่อเนื่องหรือปรับใช้ mydb v2 ไปจนถึงการแย่งก่อนที่คุณจะสามารถเริ่มทำงานกับ myapp v2 ได้ ที่สำคัญกว่านั้นคือคุณจะไม่ทำการทดสอบ mydb v2 บน DEV ดังนั้นถ้ามันหักคุณจะไม่พบจนกว่ามันจะหยุดทำงานกับ DEMO แล้วคุณจะกลับมาที่จตุรัสหนึ่ง

ในระดับหนึ่งปัญหาที่คุณอธิบายนั้นหลีกเลี่ยงไม่ได้ไม่ว่าจะตั้งค่าเวิร์กโฟลว์ของคุณอย่างไร แต่ก็สามารถย่อเล็กสุดได้ เคล็ดลับคือเพื่อให้แน่ใจว่ามีการกำหนดอินเทอร์เฟซระหว่าง mydb และ myws (และอินเทอร์เฟซระหว่าง myws และ myapp) ไว้อย่างเคร่งครัดและต้องการการอัปเดตทั้งหมดของอินเทอร์เฟซนั้น ที่งานของฉันเรามี XML schema ที่กำหนดอินเทอร์เฟซระหว่างแอพและบริการของเราและเครื่องมือภายในของเรามากมายจะไม่ยอมให้เราทำการปรับปรุง schema ที่เข้ากันไม่ได้

นอกจากนี้หากการสร้างหนึ่งไม่เสถียร / แตกมันมักจะทำให้ส่วนประกอบต้นน้ำอื่น ๆ ล่ม ตัวอย่างเช่นหากนักพัฒนาแบ่งบางอย่างเมื่อเปลี่ยน mydb-dev คลัสเตอร์ myws-dev และ myapp-dev มักจะไม่เสถียรเช่นกัน

สิ่งนี้ฟังดูเป็นปัญหาร้ายแรง แต่ไม่ใช่ปัญหาการปรับใช้ ฐานข้อมูลที่ใช้งานไม่ได้จะช่วยป้องกันบริการและแอปให้ทำงานได้อย่างเหมาะสม แต่ไม่ควร "ไม่เสถียร" พวกเขาควรจะส่งคืนข้อความแสดงข้อผิดพลาดบางอย่างเพื่อให้ทุกคนที่เรียกใช้ myapp ใน dev เห็นว่า "ขออภัยฐานข้อมูลของเรากำลังมีปัญหาในวันนี้" แทนที่จะหยุดทำงาน

หากปัญหาคือฐานข้อมูลที่ใช้งานไม่ได้จะทำให้เกิดปัญหาเหล่านี้จากนั้นสิ่งที่คุณสามารถทำได้คือการตั้งค่าระบบ "ชั่วคราว siloing" ที่ช่วยให้คุณพูดว่า "mydb DEV เสียแล้วตอนนี้โปรดจัดเส้นทาง myws DEV ทั้งหมด กาลเวลา ". แต่นี่ควรเป็นวิธีการแก้ไขชั่วคราวจนกว่า mydb DEV จะทำงานตามปกติอีกครั้ง หากทุกอย่าง "siled" เป็นอย่างนั้นคุณจะกลับมาที่ปัญหาที่ฉันอธิบายไว้ข้างต้นเพราะไม่มีใครทำงานกับ mydb DEV เลย

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