องค์กรปัจจุบันของรหัสและการกำหนดค่าที่คุณอธิบายมีโครงสร้างโดยโซลูชันทางเทคนิคที่เกี่ยวข้อง นี่คือการออกแบบที่ไม่ดีที่จะเพิ่มค่าใช้จ่ายจำนวนมากในกิจกรรมการบำรุงรักษาของเราและจะเพิ่มกับดักจำนวนมากในทางของเราเช่นกัน แต่องค์กรนั้นควรได้รับการวางโครงสร้างโดยใช้สิ่งประดิษฐ์ที่เรากำลังปรับใช้
เหตุผลสำหรับสิ่งนี้คือเราต้องการพิจารณาสิ่งประดิษฐ์ ( เช่นอิมเมจนักเทียบท่าหรือชุดซอฟต์แวร์) เป็นวัตถุของคำกริยาต่อไปนี้:
เพื่อพิจารณาชุดงานอัตโนมัติจำนวนเล็กน้อยที่เราต้องการดำเนินการ หากเราต้องการเปลี่ยนบางสิ่งเกี่ยวกับวิธีการใช้คำกริยาทดสอบมันเป็นเรื่องง่ายที่จะไปที่โฟลเดอร์ที่สอดคล้องกับสิ่งประดิษฐ์นั้นในที่เก็บที่เหมาะสมจากนั้นค้นหารายการระบบอัตโนมัติเฉพาะของเจนกินส์ที่ต้องได้รับการอัปเดต หากสูตรอาหารอัตโนมัติมีโครงสร้างอยู่รอบ ๆ โซลูชันทางเทคนิคเราต้องหาสีน้ำเงินที่เจนกินส์มีส่วนร่วมในขั้นตอนการทดสอบและค้นหารายการอัตโนมัติที่เกี่ยวข้องกับสิ่งประดิษฐ์ ในสถานการณ์ที่ซับซ้อนองค์กรที่อยู่รอบ ๆ โซลูชันทางเทคนิคทำให้การอัปเดตนั้นยากมากเพราะเราต้องรู้วิธีแก้ปัญหาทางเทคนิคทั้งหมดที่เกี่ยวข้องกับบริการบางอย่างเพื่ออัปเดตตามนั้น
ตัวอย่างเช่นที่เก็บที่มีรหัสสำหรับเว็บไซต์และบริการไมโคร "a" อาจมีไดเรกทอรีย่อยดังต่อไปนี้เพื่อการดำเนินงาน:
./ops/website
./ops/micro-service-a
แต่ละคนมีสามสคริปต์เรียกว่าbuild, และtest deployตอนนี้การจัดระเบียบรายการระบบอัตโนมัติได้รับการชี้แจงอย่างใดลองเปลี่ยนความสนใจของเราไปยังการกำหนดค่า
เงื่อนไขหลักและข้อกำหนดเกี่ยวกับองค์กรการกำหนดค่าถูกกำหนดโดยdeployคำกริยาเมื่อนำไปใช้กับสิ่งประดิษฐ์ที่เหมือนบริการ deployกริยาควรมีพารามิเตอร์ต่อไปนี้:
- รุ่นของสิ่งประดิษฐ์ที่จะปรับใช้
- เป้าหมายการปรับใช้ของสิ่งประดิษฐ์ซึ่งอธิบายสภาพแวดล้อมที่เป็นรูปธรรมซึ่งสิ่งประดิษฐ์ที่นำไปใช้งานจะทำงาน ( เช่นคลัสเตอร์และจุดสิ้นสุดที่ควรพูดคุย)
- ข้อมูลประจำตัวที่ควรใช้เพื่อเชื่อมต่อกับปลายทางอื่น ๆ ( เช่นฐานข้อมูล)
- การกำหนดค่ารันไทม์ของ (เช่นระยะเวลาที่รายการแคชควรอยู่ ฯลฯ )
จากมุมมองการปฏิบัติงานการแยกแยะความแตกต่างของพาราเมทรีนี้สอดคล้องกับองศาอิสระของปัญหาการปรับใช้ - นอกเหนือจากข้อมูลประจำตัวที่สามารถรวมกับการกำหนดค่ารันไทม์ได้ แต่จะเป็นการดีกว่าถ้าแยกพวกเขาออกจากกัน