ติดตามการเปลี่ยนแปลงการกำหนดค่าจาก dev เป็น prod อย่างมีประสิทธิภาพ

คำถามนี้ใช้บริการ Spring Boot เป็นตัวอย่าง แต่อาจเป็นเทคโนโลยีใด ๆ ก็ได้

สมมติว่าต่อไปนี้:

• สภาพแวดล้อม (dev / QA / prod) เป็นของทีมอื่น ซึ่งหมายความว่า dev ต้องไม่มีสิทธิ์เข้าถึงการกำหนดค่า prod
• การกำหนดค่า (สมมุติว่า application.properties) ถูกทำให้เป็นภายนอกไม่ใช่ส่วนหนึ่งของไบนารี
• ไบนารี / แพ็คเกจเดียวกัน (สมมุติว่า service.jar) ถูกปรับใช้ในแต่ละสภาพแวดล้อมและควบคุมโดยการปรับใช้อัตโนมัติ

ในขณะที่การเปลี่ยนแปลงสิ่งประดิษฐ์ไบนารี (service.jar) ได้รับการเผยแพร่โดยอัตโนมัติไปยังแต่ละสภาพแวดล้อมการเปลี่ยนแปลงการกำหนดค่ายังคงต้องมีการแทรกแซงด้วยตนเองซึ่งท้ายที่สุดก็กลายเป็นถูกทำข้อมูลให้ตรงกันในแต่ละสภาพแวดล้อม

ตัวอย่างเช่นสมมติว่าทีม dev เพิ่มคู่ของคีย์ - ค่าลงในแอปพลิเคชันคุณสมบัติในสภาพแวดล้อมของพวกเขา อะไรจะเป็นวิธีที่ดีที่สุดในการบันทึกคีย์ใหม่เหล่านี้ดังนั้นเมื่อการปรับใช้เกิดขึ้นในทีม ops พวกเขารู้ว่าต้องเพิ่มคีย์ใดดังนั้นความเสี่ยงของการเริ่มบริการใหม่และการเห็นว่าล้มเหลวเนื่องจากคีย์ที่หายไป

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

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

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

ตัวอย่างเช่นสมมติว่าทีมงาน dev เพิ่มคู่ของคีย์ - ค่าลงในแอปพลิเคชั่นคุณสมบัติในสภาพแวดล้อมของพวกเขา อะไรจะเป็นวิธีที่ดีที่สุดในการบันทึกคีย์ใหม่เหล่านี้ดังนั้นเมื่อการปรับใช้เกิดขึ้นในทีม ops พวกเขารู้ว่าต้องเพิ่มคีย์ใดดังนั้นความเสี่ยงในการเริ่มบริการใหม่และการเห็นว่าล้มเหลวเนื่องจากคีย์ที่หายไป

วิธีที่ดีที่สุดในการลดความเสี่ยงจากความล้มเหลวคือหลีกเลี่ยงการเปลี่ยนแอปพลิเคชันของคุณในแบบที่ต้องใช้คีย์ใหม่ดังนั้นแอปพลิเคชันควรเข้ากันได้ย้อนหลังกับไฟล์การกำหนดค่ารุ่นเก่าทุกครั้งที่ทำได้ บ่อยครั้งที่แอปพลิเคชันของคุณสามารถทำงานได้อย่างเหมาะสมโดยระบุค่าเริ่มต้นที่สร้างไว้สำหรับคีย์ใหม่สำหรับกรณีที่ไม่มี

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

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

ตัวอย่างเช่นฉันใช้เว็บเบราว์เซอร์ Firefox และในแต่ละรุ่นใหม่ (ซึ่งฉันได้รับโดยอัตโนมัติ) มีการเพิ่มบางสิ่งในการกำหนดค่าท้องถิ่นที่สามารถตรวจสอบได้ในหน้า "about: config" นี่เปรียบได้กับการกำหนดค่าในสภาพแวดล้อม "การผลิต" ของคุณ เนื่องจากการกำหนดค่าทั้งหมดถูกเก็บไว้อย่างเข้ากันได้ย้อนหลังอย่างเคร่งครัดฉันไม่จำเป็นต้องเพิ่มคีย์ใหม่ในการกำหนดค่าด้วยตนเองเพียงเพราะมีเบราว์เซอร์รุ่นใหม่ และสำหรับกรณีที่ฉันต้องการเปลี่ยนบางสิ่งบางอย่างที่นั่น (อาจเป็นรายการใหม่ซึ่งไม่ได้เป็นส่วนหนึ่งของรุ่นก่อนหน้า) ฉันใช้เมนูเครื่องมือ / ตัวเลือกหรือหน้า "เกี่ยวกับ: config" และสามารถค้นหารายการพร้อมบางอย่าง ประเภทของเอกสาร ดังนั้นฉันขอแนะนำให้พยายามใช้ระบบของคุณในลักษณะที่เปรียบเทียบได้

ที่เดียวที่ฉันเคยทำงานพวกเขามีปัญหาที่คล้ายกัน การกำหนดค่าการผลิตถูกควบคุมโดยทีมงานสร้างเท่านั้นที่จะสามารถเข้าถึงได้ในที่เก็บรหัส การกำหนดค่า dev, qa, test, ฯลฯ ... สามารถมองเห็นได้โดยทุกคน

ในตัวอย่างของคุณผู้พัฒนาจะอัพเดตไฟล์แบบโลคัลตรวจสอบในคอนโทรลแหล่งที่มาจากนั้นบางคนจะขอให้ทีมสร้างทำบิลด์ "config only" ใหม่ซึ่งตรวจสอบไฟล์การกำหนดค่าและปรับใช้ แต่ไม่ได้คอมไพล์ใหม่หรือ ปรับใช้แอปพลิเคชันทั้งหมดอีกครั้ง

มันขึ้นอยู่กับสมาชิกในทีมที่จะอัพเดตไฟล์กำหนดค่าสำหรับสภาพแวดล้อมอื่นในเวลาที่เหมาะสม เมื่อถึงเวลาที่จะต้องปรับปรุงการผลิตทีมงานสร้างจะต้องอัปเดตไฟล์ผ่านคำขออย่างชัดเจนจากผู้นำทีม dev แต่โดยทั่วไปแล้วคำขอจะดูเหมือน "คัดลอกไฟล์ app.config จาก QA1 ไปยัง PROD" สิ่งที่ละเอียดอ่อนเช่นรหัสผ่านอยู่ในไฟล์กำหนดค่าแยกต่างหากและอีกครั้งทีมสร้างเท่านั้นที่สามารถเข้าถึงไฟล์รหัสผ่านการผลิตได้ ความแตกต่างคือการที่นักพัฒนามักจะทำไม่ได้ร้องขอการเปลี่ยนแปลงไฟล์รหัสผ่านเนื่องจากไม่มีรหัสผ่านการผลิต ครั้งเดียวที่พวกเขาจะขอให้ทีมบิลด์อัปเดตมันคือเมื่อเพิ่มรหัสผ่านใหม่สำหรับบริการใหม่ และถึงตอนนั้นนักพัฒนาอาจไม่ทราบรหัสผ่านการผลิตพวกเขารู้เพียงกุญแจที่จะเพิ่มไปยังไฟล์ (เช่น "newService2.password")

เทคโนโลยีที่ใช้ในการจัดการสิ่งนี้คือเจนกินส์ นอกจากนี้ยังมีเครื่องมือในบ้านที่ใช้ในการขอและกำหนดเวลาการสร้างผ่านเจนกินส์