ฉันได้ทำ / สร้างงานนำเสนอที่เกี่ยวข้องกับ SCM จำนวนมากและตอนนี้ฉันพยายาม "อัปเกรด" เป็นตัวตายตัวแทนของ DevOps

สิ่งที่ฉันพยายามทำอยู่เสมอในการนำเสนอของฉันคือการสร้างสไลด์การนำเสนอซึ่งรวมถึงข้อความที่ฉันต้องการส่งมอบ (และจากนั้นฉันก็อธิบายเพิ่มเติมในส่วนที่เหลือของงานนำเสนอ) เมื่อทำเช่นนั้นฉันพยายามตอบคำถามของตัวเองเช่น "วลีที่ฉัน 1 ถึง 3 คืออะไรที่ฉันต้องการใช้ถ้าฉันมีเวลาประมาณ 10 ถึง 20 วินาที (เท่านั้น!) เพื่ออธิบายให้คนใหม่ดู? * "

ฉันคิดว่าฉันรู้ว่าDevOpsหมายถึงอะไรจริง ๆ และมันเกี่ยวกับอะไร แต่ฉันเคยเห็นการใช้งาน / บริบทที่แปลกประหลาดของDevOps (แม้แต่ในDevOps.SE ... ) มันทำให้ฉันสงสัยว่าบางทีสิ่งที่ฉันคิดว่า DevOps คือผิดทั้งหมด

โดยทั่วไปแล้วอะไรคือความหมายของคำจำกัดความของ DevOps

DevOps อย่างย่อ

จากวิกิพีเดีย :

DevOps (คำย่อประกอบของ " ซอฟต์แวร์DEV elopment " และ " เทคโนโลยีสารสนเทศOP eration S ") เป็นคำที่ใช้เพื่ออ้างถึงชุดของการปฏิบัติที่เน้นการทำงานร่วมกันและการสื่อสารของทั้งนักพัฒนาซอฟต์แวร์และผู้เชี่ยวชาญด้านเทคโนโลยีสารสนเทศ (IT) ในขณะที่อัตโนมัติ กระบวนการส่งมอบซอฟต์แวร์และการเปลี่ยนแปลงโครงสร้างพื้นฐาน

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

จากภาพรวม :

แผนภาพ Venn แสดง DevOps เป็นจุดตัดของการพัฒนา (วิศวกรรมซอฟต์แวร์) การดำเนินงานและการประกันคุณภาพ (QA)

แม้ว่าจะไม่มี "เครื่องมือ" เดียวสำหรับ DevOps แต่เป็นชุดเครื่องมือที่เรียกว่าเป็นDevOps toolchain :

ภาพประกอบแสดงขั้นตอนใน toolchain ของ DevOps

ภาพประกอบของ DevOps

ด้านล่างนี้เป็นคำพูดเล็กน้อยจากคำถามบางข้อในDevOpsซึ่งดูเหมือนว่าจะเหมาะสม / ยืนยันส่วนหนึ่งของคำอธิบาย DevOps ด้านบน:

• จาก ' ความแตกต่างระหว่าง SRE และ DevOps คืออะไร ':

  ... DevOps เกี่ยวกับการบำรุงรักษารหัส ...

• จาก ( คำตอบถึง) ' ฉันจะจ้าง DevOps ที่ดีได้อย่างไรให้ บริษัท ของฉันเหมาะสม? ':

  ... มันเป็นความเชื่อที่ผิด ๆ ที่“ DevOps” มีบทบาทใน บริษัท คำนี้หมายถึงการเปลี่ยนแปลงขององค์กรใน บริษัท ซอฟต์แวร์ ...

• จาก ' องค์กรของฉันต้องใช้ Agile Soft หรือไม่ dev ก่อนที่จะใช้ DevOps ':

  ... ยังมีองค์กรที่ไม่ได้ฝึกฝน Agile ในการพัฒนาซอฟต์แวร์ซึ่งอาจสนใจใช้ DevOps ...

DevOps ไม่ใช่บทบาท

ด้านล่างนี้เป็นคำพูดเล็กน้อยจากคำถามบางข้อในDevOps.SEซึ่งดูเหมือนจะแสดงให้เห็นว่า DevOps ไม่ใช่บทบาท:

• จาก ( คำตอบถึง) ' ความแตกต่างระหว่าง Sysadmin และ DevOps Engineer คืออะไร? ':

  ... DevOps ไม่ใช่บทบาท (เมื่อใช้เช่นนี้มันเป็น buzzword มากกว่าบทบาทจริง)

• จาก ( คำตอบถึง) ' ฉันจะจ้าง DevOps ที่ดีได้อย่างไรให้ บริษัท ของฉันเหมาะสม? ':

  ... มันเป็นความเชื่อที่ผิด ๆ ที่“ DevOps” มีบทบาทใน บริษัท คำนี้หมายถึงการเปลี่ยนแปลงขององค์กรใน บริษัท ซอฟต์แวร์ ...

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

รูปแบบองค์กร

DevOps Antipatterns:

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

• สะพาน DevOps - นี่คือที่หนึ่งหรือหลายทีมได้รับความรับผิดชอบในการทำงานจากทีมพัฒนาและ " การผลิต " เพื่อให้สามารถใช้งานได้ ความท้าทายมาถึงตอนนี้มีสองมือออกคือการพัฒนา→ DevOps และ DevOps →การดำเนินงาน

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

รูปแบบ DevOps:

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

• Institutionalized DevOps - ที่ซึ่งทีมงานโครงการร่วมกันรับผิดชอบทั้งในการพัฒนาและการดำเนินงานของซอฟต์แวร์สำเร็จรูปที่สร้างความเป็นเจ้าของร่วมและลูปตอบรับเชิงบวก

การปฏิบัติ

การปฏิบัติที่แท้จริงของ DevOps สร้างขึ้นจากการปฏิบัติอื่น ๆ หลายประการ ได้แก่ :

• ส่งเปรียว
• บูรณาการอย่างต่อเนื่อง
• จัดส่งอย่างต่อเนื่อง
• การปรับใช้อย่างต่อเนื่อง

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

สามวิธี

ในThe Phoenix Projectยีนคิมและผู้เขียนร่วมของเขาอธิบายสามวิธีของ DevOps :

ระบบการคิด

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

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

การขยายความคิดเห็นลูป

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

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

วัฒนธรรมการทดลองและเรียนรู้อย่างต่อเนื่อง

วิธีที่สามคือการสร้างวัฒนธรรมที่ส่งเสริมสองสิ่ง: การทดลองอย่างต่อเนื่องการรับความเสี่ยงและการเรียนรู้จากความล้มเหลว และความเข้าใจว่าการทำซ้ำและการฝึกฝนเป็นสิ่งที่จำเป็นสำหรับการเรียนรู้

สิ่งนี้เหมาะสมมากในพื้นที่วัฒนธรรมแม้ว่าจะขึ้นอยู่กับเครื่องมือและกระบวนการเพื่อให้วัฒนธรรมเติบโตขึ้นอย่างมาก

ฉันเคยได้ยินคำจำกัดความที่หลากหลายมากมายของ DevOps พวกเขารวมถึง:

• นักพัฒนาจัดการงานการดำเนินงาน
• คนคนหนึ่งทำงานได้มากเป็นสองเท่า (ในระยะเวลาเท่ากัน)
• นักพัฒนาและทีมปฏิบัติการที่ทำงานร่วมกัน
• การทำงานเป็นเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ (ในเส้นเลือดของ "Web Ops")
• ชื่องานสำหรับคนที่สร้างและดูแลรักษาเครื่องมือสำหรับนักพัฒนา
• การใช้ระบบอัตโนมัติในการดำเนินงาน
• การใช้คลาวด์สาธารณะในการดำเนินงาน
• งานที่รวมแง่มุมของการดำเนินงานการพัฒนาและการประกันคุณภาพ
• งานที่มีส่วนช่วยให้ทีมพัฒนาและฝ่ายปฏิบัติการทำงานร่วมกัน
• ปรัชญาของการทำลายอุปสรรคระหว่างทีม
• การปฏิบัติโครงสร้างพื้นฐานเป็นรหัส
• สิ่งที่คุณจะได้รับเมื่อวิศวกรซอฟต์แวร์เดิมเปลี่ยนไปสู่การปฏิบัติงาน
• คำศัพท์ที่ไม่มีความหมายอย่างสมบูรณ์

ไม่มีฉันทามติของประชาชนเกี่ยวกับสิ่งที่ DevOps จริงเป็น ไม่กี่ปีหลังเรามีปัญหาที่คล้ายกันกับ "เปรียว" และมีความหมายที่เป็นลายลักษณ์อักษร

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

คำจำกัดความที่ฉันมักจะใช้ในสถานการณ์นี้คือ:

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

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

จากรายงานการวิจัยทางวิทยาศาสตร์ต่อไปนี้เพื่อสำรวจคำถามนี้ว่า "DevOps คืออะไร" คำจำกัดความที่ได้รับที่เสนอของ DevOps คือ:

DevOps เป็นวิธีการพัฒนาที่มุ่งเชื่อมช่องว่างระหว่างการพัฒนา (Dev) และการปฏิบัติการ (Ops) โดยเน้นการสื่อสารและการทำงานร่วมกันการบูรณาการอย่างต่อเนื่องการประกันคุณภาพและการส่งมอบด้วยการใช้งานแบบอัตโนมัติ

[Jabbari et al.] "DevOps คืออะไร: การศึกษาการทำแผนที่อย่างเป็นระบบเกี่ยวกับคำจำกัดความและการปฏิบัติ" (2016)

Devops เป็นแนวปฏิบัติในการพัฒนาของการเขียนแอปพลิเคชันที่มีการดำเนินธุรกิจโดเมน ในกรณีที่การพัฒนาแอพพลิเคชั่นส่วนใหญ่มุ่งเน้นไปที่การสร้างแอพพลิเคชั่นที่ทำหน้าที่เกี่ยวกับการเงินหรือการดูแลสุขภาพหรือโลจิสติกส์หรือวิดีโอแมว devops มุ่งเน้นไปที่แอพพลิเคชั่น

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

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