ความแตกต่างระหว่าง DevOps และการจัดการการกำหนดค่าซอฟต์แวร์

ความแตกต่างระหว่างการดำเนินการพัฒนาและการจัดการการกำหนดค่าซอฟต์แวร์คืออะไร?

สำหรับฉันดูเหมือนว่าจะเหมือนกันตราบใดที่ทั้ง DevOps และ Software Configuration Management มุ่งเน้นไปที่:

1. การสร้างโครงสร้างพื้นฐานการพัฒนา - รับผิดชอบการควบคุมเวอร์ชันการจัดการการสร้างการจัดการการปรับใช้การจัดการการพึ่งพาการรวมอย่างต่อเนื่องและการจัดส่งฯลฯ
2. โดยใช้วิธีปฏิบัติที่ดีที่สุดสำหรับการจัดสภาพแวดล้อมการพัฒนา
3. การประกันคุณภาพของกระบวนการพัฒนา - รวบรวมตัวชี้วัดประสิทธิภาพการพัฒนาการทำงานเพื่อกำจัดคอขวดของกระบวนการพัฒนา (การทดสอบหน่วยการทำงานการประเมินความครอบคลุมการทดสอบหน่วย
4. การจัดการโครงสร้างพื้นฐาน - แพลตฟอร์มเป้าหมายและข้อมูลเฉพาะ
5. การจัดการการปล่อย - ทำให้แน่ใจว่ามีการส่งมอบการปล่อยให้กับลูกค้า / ลูกค้าตรงเวลา

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

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

บนมืออื่น ๆ , ซอฟแวร์การบริหารจัดการการกำหนดค่าเป็นระยะไกลจัดตั้งขึ้นภายในวิชาชีพและมาจากที่ไม่ใช่ระยะซอฟต์แวร์เฉพาะการบริหารจัดการการกำหนดค่า การจัดการการกำหนดค่าซอฟต์แวร์มักถูกอ้างอิงในบริบทของวิศวกรรมซอฟต์แวร์คำจำกัดความง่ายๆได้รับจาก Roger Pressman ใน"วิศวกรรมซอฟต์แวร์: วิธีการของผู้ปฏิบัติการ" :

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

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

DevOps เป็นการตอบสนองต่อการรับรู้ที่เพิ่มขึ้นว่ามีการตัดการเชื่อมต่อระหว่างกิจกรรมการพัฒนาแบบดั้งเดิมและกิจกรรมการดำเนินงานแบบดั้งเดิม การตัดการเชื่อมต่อนี้มักจะปรากฏว่าตัวเองเป็นความขัดแย้งและความไร้ประสิทธิภาพ

ในบทความเดียวกันความคล้ายคลึงกับ SCM ถูกบันทึกไว้:

การเพิ่มเข้าไปใน Wall of Confusion เป็นสิ่งที่ไม่ตรงกันในการพัฒนาและการใช้เครื่องมือ ดูเครื่องมือยอดนิยมที่นักพัฒนาร้องขอและใช้เป็นประจำทุกวัน จากนั้นดูเครื่องมือยอดนิยมที่ผู้ดูแลระบบร้องขอและใช้เป็นประจำทุกวัน ด้วยข้อยกเว้นที่น่าทึ่งบางประการเช่นตัวติดตามบั๊กและอาจเป็น SCMสงสัยว่าคุณจะเห็นความสนใจในการใช้เครื่องมืออื่น ๆ หรือการรวมระบบที่สำคัญระหว่างกัน แม้ว่าจะมีการทับซ้อนกันของเครื่องมือบางประเภท แต่การใช้งานจะแตกต่างกันในแต่ละกลุ่ม

สำหรับการใช้คำศัพท์การเปรียบเทียบของคุณไม่สมเหตุสมผล:

1. SCM เป็นส่วนย่อยของ CM ไม่ใช่เงื่อนไขการแข่งขัน
2. DevOps เป็นศัพท์ใหม่ค่อนข้างไม่มีจุดเปรียบเทียบกับศัพท์ที่สร้างขึ้น
3. DevOps มาจากการดำเนินงานของนักพัฒนาซอฟต์แวร์ (เห็นได้ชัด) แต่ไม่ค่อยมีการขยายเช่นนี้

การเป็นผู้จัดการการกำหนดค่าซอฟต์แวร์ Sr. โดยส่วนตัวเป็นเวลาหลายปี (10+) ฉันได้ยินเงื่อนไขที่ไม่ตรงกันในสถานการณ์ชีวิตจริงที่หลากหลาย ไม่ใช่เรื่องผิดปกติสำหรับบุคลากรด้านเทคนิคเนื่องจากลักษณะสัมพัทธ์ของตำแหน่ง พวกเขาทั้งสองมีบทบาทเฉพาะความต้องการและข้อกำหนดที่คล้ายกัน แต่ยังสามารถแบ่งแยกได้อย่างชัดเจนในความคิดของฉัน

ฉันเชื่อว่าวิธีที่ดีที่สุดในการอธิบายการแบ่งบทบาทเหล่านี้คือการมุ่งเน้นไปที่ความสัมพันธ์กับการโต้ตอบ ความหมายนี้การจัดการการกำหนดค่าซอฟต์แวร์จะมุ่งเน้นไปที่ระบบภายในและสภาพแวดล้อมพร้อมกับการรวมการปรับใช้การปล่อยและการจัดการซอร์สโค้ด ตำแหน่งที่ Developer Operations (DevOps) มุ่งเน้นไปที่ลักษณะการทำงานของสถาปัตยกรรมแอปพลิเคชั่นที่ต้องเผชิญกับภายนอกมากขึ้นในขณะที่ยังคงมีความเข้าใจที่ชัดเจนของโค้ดตามที่ตั้งใจไว้สำหรับการใช้งานและการปฏิบัติงานของสภาพแวดล้อม หากประสิทธิภาพของเครื่องจักรแสดงสัญญาณของการเสื่อมสภาพการสื่อสารระหว่างแอพพลิเคชั่นหลายอย่างผิดพลาดการสื่อสารระหว่างธุรกิจกับธุรกิจ (BtB) และ / หรือข้อ จำกัด ด้านสถาปัตยกรรมที่เกี่ยวข้องกับสภาพแวดล้อมการผลิตคุณจะต้องดูการปฏิบัติการของนักพัฒนา วิธีการแก้.

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

ฉันเคยเห็นความสับสนหลายอย่างของแต่ละคนและในแต่ละครั้งก็มีครอสโอเวอร์ที่ จำกัด อย่างไรก็ตามมันเป็นสิ่งสำคัญที่สุดที่จะคิดว่าความแตกต่างระหว่างความรับผิดชอบของแต่ละตำแหน่งอิสระที่เกี่ยวข้องกับการมุ่งเน้นหลักของพวกเขา หลักเมื่อจัดการกับระบบและฮาร์ดแวร์ที่ใช้ภายในเพื่อจัดการการกำหนดค่าสภาพแวดล้อมและการเปิดตัวผลิตภัณฑ์คุณจะต้องหา Software Configuration Manager ในทางกลับกันเมื่อต้องจัดการกับประสิทธิภาพของระบบการตรวจสอบการวิจัยและการวินิจฉัยระบบที่ลูกค้าของคุณใช้คุณควรดูที่ Developer Operations หรือ DevOps

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

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

DevOps เป็นเพียงคำศัพท์ใหม่สำหรับการจัดการการกำหนดค่า แต่มันได้รับเลือกให้แสดงให้เห็นว่าบทบาทนั้นไม่ใช่บทบาทเดียว แต่เป็นการทำงานร่วมกันระหว่างทีมพัฒนาและทีมปฏิบัติการ

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

นี่เป็นคำอธิบายที่ง่ายสำหรับคำถาม: DevOps เป็นคำที่ใช้เพื่ออธิบายการประสานงานหรือความสัมพันธ์ระหว่างการพัฒนา (การพัฒนารหัสโปรแกรมในสภาพแวดล้อมการพัฒนา) และการดำเนินงาน

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

เพื่อสรุป SCM เชื่อมต่อ Dev และ Ops

ฉันเห็นว่า DEVOPs อยู่ที่จุดสิ้นสุดการดำเนินการปฏิบัติงาน - สคริปต์การปรับใช้อัตโนมัติ, การสร้างสภาพแวดล้อม, สิ่งนั้น ในทางกลับกัน SCM เป็นเรื่องเกี่ยวกับความสมบูรณ์ของผลิตภัณฑ์และการจัดการที่มีประสิทธิภาพและตรวจสอบย้อนกลับของการเปลี่ยนแปลงผลิตภัณฑ์ ฉันมักจะมองว่า ALM เป็นส่วนหนึ่งของ SCM - อย่างไรก็ตามคุณสามารถจัดการการเปลี่ยนแปลงของผลิตภัณฑ์ได้อย่างไรถ้าคุณไม่ทราบว่ามีไดรเวอร์สำหรับการเปลี่ยนแปลงหรือเป็นใคร กรอบการปรับใช้อาจลดลงทั้งสองด้าน - และด้านใดจะขึ้นอยู่กับความต้องการด้านกฎระเบียบขององค์กรที่คุณทำงานอยู่เสมอ - คุณต้องการให้นักพัฒนาทำแฮ็คด่วนซึ่งหมายความว่าเครื่องฟอกไตของคุณทำงานได้อย่างถูกต้อง 99.99% หรือคุณต้องการสถานการณ์นั้นเพื่อให้คุณสามารถแฮ็ครหัสเว็บไซต์ของคุณได้เนื่องจากนักพัฒนาของคุณมีที่อยู่ IP แบบฮาร์ดโค้ด