ภาพ:
สวัสดีทุกคน! เราเป็นวิศวกรระบบอัตโนมัติจากบริษัท และเราสนับสนุนการพัฒนาผลิตภัณฑ์ของบริษัท: เราสนับสนุนขั้นตอนการประกอบทั้งหมดตั้งแต่การคอมมิตบรรทัดโค้ดโดยนักพัฒนาไปจนถึงการเผยแพร่ผลิตภัณฑ์สำเร็จรูปและสิทธิ์การใช้งานบนเซิร์ฟเวอร์อัพเดท เราเรียกอย่างไม่เป็นทางการว่าวิศวกร DevOps ในบทความนี้ เราต้องการพูดคุยเกี่ยวกับขั้นตอนทางเทคโนโลยีของกระบวนการผลิตซอฟต์แวร์ วิธีที่เรามองเห็นและวิธีที่เราจำแนกประเภท
จากเนื้อหา คุณจะได้เรียนรู้เกี่ยวกับความซับซ้อนของการประสานงานการพัฒนาหลายผลิตภัณฑ์ เกี่ยวกับแผนที่เทคโนโลยีคืออะไร และช่วยให้ปรับปรุงและจำลองโซลูชันได้อย่างไร ขั้นตอนหลักและขั้นตอนของกระบวนการพัฒนาคืออะไร ขอบเขตความรับผิดชอบเป็นอย่างไร ระหว่าง DevOps และทีมงานในบริษัทของเรา
เกี่ยวกับ Chaos และ DevOps
โดยสังเขป แนวคิดของ DevOps รวมถึงเครื่องมือและบริการสำหรับการพัฒนา ตลอดจนวิธีการและแนวปฏิบัติที่ดีที่สุดสำหรับการใช้งาน เรามาแยกจากทั่วโลกกันเถอะ เป้าหมาย จากการนำแนวคิด DevOps ไปใช้ในบริษัทของเรา: นี่เป็นการลดต้นทุนการผลิตและการบำรุงรักษาผลิตภัณฑ์ในเชิงปริมาณอย่างสม่ำเสมอ (ชั่วโมงการทำงานหรือชั่วโมงเครื่องจักร, CPU, RAM, ดิสก์ ฯลฯ) วิธีที่ง่ายและชัดเจนที่สุดในการลดต้นทุนการพัฒนาโดยรวมในระดับของบริษัททั้งหมดคือ ลดต้นทุนในการทำงานซีเรียลทั่วไปให้เหลือน้อยที่สุด ในทุกขั้นตอนของการผลิต แต่ขั้นตอนเหล่านี้คืออะไร จะแยกออกจากกระบวนการทั่วไปได้อย่างไร ประกอบด้วยขั้นตอนใดบ้าง
เมื่อบริษัทพัฒนาผลิตภัณฑ์หนึ่งๆ ทุกอย่างจะชัดเจนไม่มากก็น้อย โดยปกติแล้วจะมีแผนงานและแผนการพัฒนาร่วมกัน แต่จะทำอย่างไรเมื่อสายผลิตภัณฑ์ขยายตัวและมีสินค้ามากขึ้น? เมื่อมองแวบแรก พวกเขามีกระบวนการและสายการประกอบที่คล้ายคลึงกัน และเกม "ค้นหาความแตกต่าง X" ในบันทึกและสคริปต์ก็เริ่มต้นขึ้น แต่จะเป็นอย่างไรหากมีโครงการมากกว่า 5 โครงการที่กำลังพัฒนาอยู่และจำเป็นต้องมีการสนับสนุนสำหรับหลายเวอร์ชันที่พัฒนาในช่วงหลายปี เราต้องการนำโซลูชันจำนวนสูงสุดเท่าที่จะเป็นไปได้กลับมาใช้ซ้ำในท่อส่งผลิตภัณฑ์ หรือเราพร้อมที่จะใช้จ่ายเงินในการพัฒนาที่ไม่เหมือนใครสำหรับแต่ละผลิตภัณฑ์หรือไม่
จะหาสมดุลระหว่างความเป็นเอกลักษณ์และโซลูชันแบบอนุกรมได้อย่างไร
คำถามเหล่านี้เริ่มเกิดขึ้นต่อหน้าเราบ่อยขึ้นเรื่อยๆ ตั้งแต่ปี 2015 จำนวนผลิตภัณฑ์เพิ่มขึ้น และเราพยายามขยายแผนกระบบอัตโนมัติ (DevOps) ซึ่งรองรับสายการประกอบของผลิตภัณฑ์เหล่านี้ให้เหลือน้อยที่สุด ในขณะเดียวกัน เราต้องการจำลองโซลูชันระหว่างผลิตภัณฑ์ต่างๆ ให้ได้มากที่สุด เพราะเหตุใดจึงทำสิ่งเดียวกันในผลิตภัณฑ์ XNUMX ชนิดด้วยวิธีที่ต่างกัน
ผู้อำนวยการฝ่ายพัฒนา: "พวกเราช่วยประเมินหน่อยได้ไหมว่า DevOps ทำอะไรกับผลิตภัณฑ์ได้บ้าง"
เรา: “เราไม่รู้ เราไม่ได้ถามคำถามแบบนี้ แต่ควรพิจารณาตัวชี้วัดอะไร”
ผู้อำนวยการฝ่ายพัฒนา: "ใครจะรู้! คิด…"
เช่นเดียวกับในภาพยนตร์ที่โด่งดัง: "ฉันอยู่ในโรงแรม! .. " - "เอ่อ ... คุณช่วยบอกทางได้ไหม" จากการไตร่ตรอง เราได้ข้อสรุปว่าก่อนอื่นเราต้องตัดสินใจเกี่ยวกับสถานะสุดท้ายของผลิตภัณฑ์ นี่เป็นเป้าหมายแรกของเรา
ดังนั้น คุณจะวิเคราะห์ผลิตภัณฑ์นับโหลด้วยทีมงานที่ค่อนข้างใหญ่ตั้งแต่ 10 ถึง 200 คนและกำหนดเมตริกที่วัดได้เมื่อจำลองโซลูชันได้อย่างไร
1:0 ในความโปรดปรานของ Chaos หรือ DevOps บนสะบัก
เราเริ่มต้นด้วยความพยายามที่จะใช้ไดอะแกรม IDEF0 และไดอะแกรมกระบวนการทางธุรกิจต่างๆ จากซีรีส์ BPwin ความสับสนเริ่มขึ้นหลังจากช่องที่ 50 ของขั้นต่อไปของโครงการถัดไป และช่องเหล่านี้สำหรับแต่ละโครงการสามารถวาดด้วยหางของงูหลามที่ยาวกว่า XNUMX ขั้นขึ้นไป ฉันรู้สึกเศร้าและอยากจะหอนไปที่ดวงจันทร์ - มันไม่เข้ากับคนทั่วไป
งานการผลิตทั่วไป
การสร้างแบบจำลองกระบวนการผลิตเป็นงานที่ซับซ้อนและต้องใช้ความอุตสาหะมาก คุณต้องรวบรวม ประมวลผล และวิเคราะห์ข้อมูลจำนวนมากจากแผนกต่างๆ และห่วงโซ่การผลิต คุณสามารถอ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ในบทความ "'
เมื่อเราเริ่มสร้างแบบจำลองกระบวนการผลิตของเรา เรามีเป้าหมายเฉพาะ - เพื่อถ่ายทอดให้พนักงานทุกคนที่เกี่ยวข้องกับการพัฒนาผลิตภัณฑ์ของบริษัท และผู้จัดการโครงการ:
- วิธีการที่ผลิตภัณฑ์และส่วนประกอบต่างๆ เริ่มตั้งแต่การคอมมิตบรรทัดโค้ด เข้าถึงลูกค้าในรูปแบบของตัวติดตั้งและการอัปเดต
- ทรัพยากรใดบ้างที่มีให้สำหรับแต่ละขั้นตอนของการผลิตผลิตภัณฑ์
- บริการใดบ้างที่เกี่ยวข้องในแต่ละขั้นตอน
- แบ่งเขตความรับผิดชอบในแต่ละด่านอย่างไร
- มีสัญญาอะไรบ้างที่ทางเข้าและทางออกของแต่ละด่าน
การคลิกที่ภาพจะเป็นการเปิดขนาดเต็ม
งานของเราในบริษัทแบ่งออกเป็นหลายส่วนการทำงาน ทิศทางของโครงสร้างพื้นฐานมีส่วนร่วมในการเพิ่มประสิทธิภาพการทำงานของทรัพยากร "เหล็ก" ทั้งหมดของแผนกรวมถึงระบบอัตโนมัติของการปรับใช้เครื่องเสมือนและสภาพแวดล้อมในนั้น ทิศทางของการตรวจสอบให้การควบคุมประสิทธิภาพการบริการตลอด 24 ชั่วโมงทุกวัน เรายังจัดให้มีการตรวจสอบเป็นบริการสำหรับนักพัฒนา ทิศทางเวิร์กโฟลว์ช่วยให้ทีมมีเครื่องมือในการจัดการกระบวนการพัฒนาและทดสอบ วิเคราะห์สถานะของโค้ด และรับการวิเคราะห์ในโครงการ และสุดท้าย ทิศทางของ webdev จัดให้มีการเผยแพร่การเผยแพร่บนเซิร์ฟเวอร์การอัปเดต GUS และ FLUS ตลอดจนการออกใบอนุญาตของผลิตภัณฑ์โดยใช้บริการ LicenseLab เพื่อสนับสนุนไปป์ไลน์การผลิต เราได้ตั้งค่าและบำรุงรักษาบริการสนับสนุนต่างๆ มากมายสำหรับนักพัฒนา (คุณสามารถฟังเรื่องราวเกี่ยวกับพวกเขาบางส่วนในการพบปะครั้งเก่า: и). เรายังพัฒนาเครื่องมืออัตโนมัติภายใน ได้แก่ .
ในช่วงห้าปีที่ผ่านมา งานของเราสะสมงานประเภทเดียวกันและงานประจำจำนวนมาก และนักพัฒนาของเราจากแผนกอื่นๆ ส่วนใหญ่มาจากสิ่งที่เรียกว่า งานทั่วไปโซลูชันซึ่งเป็นระบบอัตโนมัติทั้งหมดหรือบางส่วนไม่ก่อให้เกิดความยุ่งยากสำหรับนักแสดงและไม่ต้องการงานจำนวนมาก เราได้วิเคราะห์งานดังกล่าวร่วมกับพื้นที่ชั้นนำและสามารถระบุประเภทของงานแต่ละประเภทหรือ ขั้นตอนการผลิต, ด่านถูกแบ่งออกเป็นขั้นที่แบ่งแยกไม่ได้ และหลายขั้นรวมกัน ห่วงโซ่กระบวนการผลิต.
ตัวอย่างที่ง่ายที่สุดของห่วงโซ่เทคโนโลยีคือขั้นตอนการประกอบ การปรับใช้ และการทดสอบผลิตภัณฑ์แต่ละรายการของเราภายในบริษัท ในทางกลับกัน ตัวอย่างเช่น ขั้นตอนการสร้างประกอบด้วยขั้นตอนทั่วไปที่แยกจากกันหลายขั้นตอน: การดาวน์โหลดแหล่งที่มาจาก GitLab, การเตรียมการอ้างอิงและไลบรารีของบุคคลที่สาม, การทดสอบหน่วยและการวิเคราะห์โค้ดแบบสแตติก, การดำเนินการสร้างสคริปต์บน GitLab CI, การเผยแพร่สิ่งประดิษฐ์ในพื้นที่เก็บข้อมูลบน สิ่งประดิษฐ์และการสร้างบันทึกประจำรุ่นผ่านเครื่องมือ ChangelogBuilder ภายในของเรา
คุณสามารถอ่านเกี่ยวกับงาน DevOps ทั่วไปได้ในบทความอื่นๆ ของเราเกี่ยวกับ Habré: ""และ"'
ห่วงโซ่การผลิตทั่วไปเกิดขึ้นมากมาย กระบวนการผลิต. วิธีการมาตรฐานในการอธิบายกระบวนการคือการใช้โมเดล IDEF0 ที่ใช้งานได้
ตัวอย่างการสร้างแบบจำลองกระบวนการผลิต CI
เราให้ความสนใจเป็นพิเศษกับการพัฒนาโครงการมาตรฐานสำหรับระบบการบูรณาการอย่างต่อเนื่อง สิ่งนี้ทำให้สามารถบรรลุการรวมกันของโครงการโดยเน้นสิ่งที่เรียกว่า ปล่อยโครงร่างการสร้างพร้อมโปรโมชัน.
นี่คือวิธีการทำงาน โปรเจ็กต์ทั้งหมดมีลักษณะทั่วไป: ประกอบด้วยการกำหนดค่าของแอสเซมบลีที่อยู่ในที่เก็บสแน็ปช็อตที่ Artifactory หลังจากนั้นจึงปรับใช้และทดสอบบนม้านั่งทดสอบ แล้วจึงเลื่อนระดับเป็นที่เก็บรีลีส บริการ Artifactory เป็นจุดแจกจ่ายเดียวสำหรับสิ่งประดิษฐ์บิลด์ทั้งหมดระหว่างทีมและบริการอื่นๆ
หากเราลดความซับซ้อนลงอย่างมากและทำให้รูปแบบการเผยแพร่ของเราเป็นแบบทั่วไป ก็จะประกอบด้วยขั้นตอนต่อไปนี้:
- การประกอบผลิตภัณฑ์ข้ามแพลตฟอร์ม
- การปรับใช้กับม้านั่งทดสอบ
- เรียกใช้การทดสอบการทำงานและอื่น ๆ
- การส่งเสริมการสร้างที่ทดสอบแล้วเพื่อเผยแพร่ที่เก็บที่ Artifactory
- การเผยแพร่การสร้างรุ่นบนเซิร์ฟเวอร์อัปเดต
- การส่งมอบชุดประกอบและการปรับปรุงการผลิต
- เปิดตัวการติดตั้งและอัปเดตผลิตภัณฑ์
ตัวอย่างเช่น พิจารณาแบบจำลองทางเทคโนโลยีของโครงร่างการเผยแพร่ทั่วไปนี้ (ต่อไปนี้เรียกว่าแบบจำลอง) ในรูปแบบของแบบจำลอง IDEF0 ที่ใช้งานได้ ซึ่งสะท้อนให้เห็นถึงขั้นตอนหลักของกระบวนการ CI ของเรา รุ่น IDEF0 ใช้สิ่งที่เรียกว่า สัญกรณ์ ICOM (Input-Control-Output-Mechanism) เพื่ออธิบายทรัพยากรที่ใช้ในแต่ละขั้นตอน โดยพิจารณาจากกฎและข้อกำหนดที่ดำเนินการ ผลผลิตคืออะไร และกลไก บริการ หรือบุคคลใดดำเนินการในขั้นตอนใดขั้นตอนหนึ่ง
การคลิกที่ภาพจะเป็นการเปิดขนาดเต็ม
ตามกฎแล้วมันง่ายกว่าที่จะแยกย่อยและให้รายละเอียดเกี่ยวกับคำอธิบายของกระบวนการในแบบจำลองการทำงาน แต่เมื่อจำนวนองค์ประกอบเพิ่มขึ้น การเข้าใจบางสิ่งในองค์ประกอบเหล่านั้นก็ยิ่งยากขึ้นเรื่อยๆ แต่ในการพัฒนาจริง ยังมีขั้นตอนเสริม: การตรวจสอบ การรับรองผลิตภัณฑ์ เวิร์กโฟลว์อัตโนมัติ และอื่นๆ เป็นเพราะปัญหาการปรับขนาด เราจึงละทิ้งคำอธิบายนี้
กำเนิดแห่งความหวัง
ในหนังสือเล่มหนึ่ง เราพบแผนที่เก่าของโซเวียตที่อธิบายกระบวนการทางเทคโนโลยี (ซึ่งปัจจุบันยังคงใช้อยู่ในรัฐวิสาหกิจและมหาวิทยาลัยหลายแห่ง) รอ รอ เพราะเราก็มีเวิร์กโฟลว์เช่นกัน!.. มีขั้นตอน ผลลัพธ์ เมตริก ข้อกำหนด ตัวบ่งชี้ และอื่น ๆ ... ทำไมไม่ลองใช้โฟลว์ชีตกับไปป์ไลน์ผลิตภัณฑ์ของเราด้วยล่ะ มีความรู้สึก: "นี่แหละ! เราพบเธรดที่ถูกต้องแล้ว ถึงเวลาดึงให้ดี!
ในตารางอย่างง่าย เราตัดสินใจบันทึกผลิตภัณฑ์ตามคอลัมน์ และขั้นตอนทางเทคโนโลยีและขั้นตอนไปป์ไลน์ของผลิตภัณฑ์ตามแถว เหตุการณ์สำคัญเป็นสิ่งที่ยิ่งใหญ่ เช่น ขั้นตอนการสร้างผลิตภัณฑ์ และขั้นตอนเป็นสิ่งที่เล็กกว่าและมีรายละเอียดมากกว่า เช่น ขั้นตอนการดาวน์โหลดซอร์สโค้ดไปยังเซิร์ฟเวอร์บิลด์ หรือขั้นตอนการคอมไพล์โค้ด
ที่จุดตัดของแถวและคอลัมน์ของแผนที่ เราใส่สถานะสำหรับระยะและผลิตภัณฑ์เฉพาะ สำหรับสถานะ มีการกำหนดชุดของสถานะ:
- ไม่มีข้อมูล - หรือไม่เหมาะสม. จำเป็นต้องวิเคราะห์ความต้องการสำหรับขั้นตอนในผลิตภัณฑ์ การวิเคราะห์ได้ดำเนินการไปแล้ว แต่ขั้นตอนนี้ไม่จำเป็นหรือไม่สมเหตุสมผลทางเศรษฐกิจ
- เลื่อนออกไป - หรือไม่เกี่ยวข้องในขณะนี้ จำเป็นต้องมีขั้นตอนในท่อส่ง แต่ไม่มีแรงบังคับสำหรับการดำเนินการในปีนี้
- วางแผน. ขั้นตอนนี้มีการวางแผนสำหรับการดำเนินการในปีนี้
- นำไปใช้. ขั้นตอนในไปป์ไลน์ถูกนำไปใช้ในปริมาณที่ต้องการ
การกรอกตารางเริ่มโครงการทีละโครงการ ขั้นแรก ขั้นและขั้นตอนของโครงการหนึ่งถูกจัดประเภทและบันทึกสถานะ จากนั้นพวกเขาก็ทำโปรเจกต์ถัดไป แก้ไขสถานะในนั้น และเพิ่มสเตจและขั้นตอนที่ขาดหายไปในโปรเจ็กต์ก่อนหน้านี้ เป็นผลให้เราได้ขั้นตอนและขั้นตอนของไปป์ไลน์การผลิตทั้งหมดของเราและสถานะในโครงการเฉพาะ มันกลายเป็นสิ่งที่คล้ายกับเมทริกซ์ความสามารถไปป์ไลน์ผลิตภัณฑ์ เราเรียกเมทริกซ์ดังกล่าวว่าแผนที่เทคโนโลยี
ด้วยความช่วยเหลือของแผนที่เทคโนโลยี เราประสานงานกับทีมอย่างสมเหตุสมผลเกี่ยวกับแผนการทำงานสำหรับปีและเป้าหมายที่เราต้องการบรรลุร่วมกัน: ขั้นตอนใดที่เราเพิ่มในโครงการในปีนี้ และขั้นตอนใดที่เราจะทำในภายหลัง นอกจากนี้ ในระหว่างการทำงาน เราอาจมีการปรับปรุงในขั้นตอนที่เราทำสำเร็จสำหรับผลิตภัณฑ์เพียงชิ้นเดียว จากนั้นเราจะขยายแผนที่ของเราและแนะนำการปรับปรุงนี้เป็นขั้นตอนหรือขั้นตอนใหม่ จากนั้นเราจะวิเคราะห์สำหรับแต่ละผลิตภัณฑ์และค้นหาความเป็นไปได้ในการทำซ้ำการปรับปรุง
พวกเขาอาจคัดค้านเรา:“ แน่นอนว่าทั้งหมดนี้เป็นสิ่งที่ดี แต่เมื่อเวลาผ่านไปจำนวนขั้นตอนและขั้นตอนจะมีขนาดใหญ่ขึ้นอย่างห้ามปราม จะเป็นอย่างไร?
เราได้แนะนำคำอธิบายที่เป็นมาตรฐานและค่อนข้างสมบูรณ์ของข้อกำหนดสำหรับแต่ละขั้นและขั้นตอน เพื่อให้ทุกคนในบริษัทเข้าใจตรงกัน เมื่อเวลาผ่านไป เมื่อมีการแนะนำการปรับปรุง ขั้นตอนหนึ่งๆ อาจถูกรวมเข้ากับอีกขั้นหนึ่งหรืออีกขั้นหนึ่ง และจากนั้นก็จะ "ยุบ" ในขณะเดียวกัน ข้อกำหนดและความแตกต่างทางเทคโนโลยีทั้งหมดก็สอดคล้องกับข้อกำหนดของขั้นตอนหรือขั้นตอนทั่วไป
จะประเมินผลของการทำซ้ำโซลูชันได้อย่างไร เราใช้วิธีการที่ง่ายมาก: เราระบุต้นทุนเงินทุนเริ่มต้นสำหรับการดำเนินการขั้นตอนใหม่กับต้นทุนผลิตภัณฑ์ทั่วไปประจำปี แล้วหารด้วยทั้งหมดเมื่อทำซ้ำ
บางส่วนของการพัฒนาจะแสดงเป็นเหตุการณ์สำคัญและขั้นตอนบนแผนที่แล้ว เราสามารถมีอิทธิพลต่อการลดต้นทุนของผลิตภัณฑ์ผ่านการแนะนำระบบอัตโนมัติสำหรับขั้นตอนทั่วไป หลังจากนั้น เราจะพิจารณาการเปลี่ยนแปลงในลักษณะเชิงคุณภาพ เมตริกเชิงปริมาณ และกำไรที่ทีมได้รับ (ในชั่วโมงการทำงานหรือชั่วโมงเครื่องจักรที่ประหยัดได้)
แผนที่เทคโนโลยีของกระบวนการผลิต
หากเราทำตามขั้นตอนและขั้นตอนทั้งหมดเข้ารหัสด้วยแท็กและขยายเป็นห่วงโซ่เดียวมันจะยาวมากและเข้าใจยาก (แค่ "หางงูเหลือม" ที่เราพูดถึงในตอนต้นของบทความ) :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]ขั้นตอนเหล่านี้คือขั้นตอนของการสร้างผลิตภัณฑ์ [สร้าง] นำไปใช้กับเซิร์ฟเวอร์ทดสอบ [ปรับใช้] ทดสอบ [ทดสอบ] เลื่อนระดับบิลด์เพื่อปล่อยที่เก็บข้อมูลตามผลการทดสอบ [ส่งเสริม] สร้างและเผยแพร่ใบอนุญาต [ใบอนุญาต] เผยแพร่ [ เผยแพร่] บนเซิร์ฟเวอร์อัปเดต GUS และจัดส่งไปยังเซิร์ฟเวอร์อัปเดต FLUS การติดตั้งและอัปเดตส่วนประกอบของผลิตภัณฑ์บนโครงสร้างพื้นฐานของลูกค้าโดยใช้ Product Configuration Management [Install] ตลอดจนการรวบรวมการวัดระยะไกล [Telemetry] จากผลิตภัณฑ์ที่ติดตั้ง
นอกจากนี้ ยังสามารถแยกแยะขั้นตอนที่แยกจากกัน: การตรวจสอบสถานะโครงสร้างพื้นฐาน [InfMonitoring] การกำหนดเวอร์ชันซอร์สโค้ด [SourceCodeControl] การเตรียมสภาพแวดล้อมการสร้าง [Prepare] การจัดการโครงการ [เวิร์กโฟลว์] การจัดหาเครื่องมือสื่อสารให้กับทีม [การสื่อสาร] การรับรองผลิตภัณฑ์ [ การรับรอง] และรับประกันความพอเพียงของกระบวนการ CI [CISelfSufficiency] (เช่น ความเป็นอิสระของชุดประกอบจากอินเทอร์เน็ต) ขั้นตอนหลายสิบขั้นตอนในกระบวนการของเราจะไม่ได้รับการพิจารณาด้วยซ้ำ เนื่องจากเป็นขั้นตอนที่เฉพาะเจาะจงมาก
การทำความเข้าใจและดูกระบวนการผลิตทั้งหมดจะง่ายกว่ามากหากแสดงไว้ในแบบฟอร์ม แผนที่เทคโนโลยี; นี่คือตารางที่แต่ละขั้นตอนการผลิตและขั้นตอนการแยกย่อยของแบบจำลองถูกเขียนเป็นแถว และในคอลัมน์คำอธิบายของสิ่งที่ทำในแต่ละขั้นตอนหรือแต่ละขั้นตอน ความสำคัญหลักอยู่ที่ทรัพยากรที่จัดหาให้แต่ละขั้น และการจำกัดขอบเขตความรับผิดชอบ
แผนที่สำหรับเราคือลักษณนามชนิดหนึ่ง สะท้อนให้เห็นถึงชิ้นส่วนเทคโนโลยีขนาดใหญ่ของการผลิตผลิตภัณฑ์ ด้วยเหตุนี้ ทีมระบบอัตโนมัติของเราจึงโต้ตอบกับนักพัฒนาได้ง่ายขึ้นและร่วมกันวางแผนการใช้งานขั้นตอนการทำงานอัตโนมัติ ตลอดจนเข้าใจว่าต้นทุนแรงงานและทรัพยากรใด (คนและฮาร์ดแวร์) ที่จำเป็นสำหรับสิ่งนี้
ภายในบริษัทของเรา แผนที่จะถูกสร้างขึ้นโดยอัตโนมัติจากเทมเพลต jinja เป็นไฟล์ HTML ทั่วไป จากนั้นจึงอัปโหลดไปยังเซิร์ฟเวอร์ GitLab Pages สามารถดูภาพหน้าจอพร้อมตัวอย่างแผนที่ที่สร้างขึ้นอย่างสมบูรณ์ได้ .
การคลิกที่ภาพจะเป็นการเปิดขนาดเต็ม
กล่าวโดยย่อ แผนที่เทคโนโลยีคือภาพทั่วไปของกระบวนการผลิต ซึ่งสะท้อนถึงบล็อกที่แยกประเภทอย่างชัดเจนพร้อมฟังก์ชันการทำงานทั่วไป
โครงสร้างแผนงานของเรา
แผนที่ประกอบด้วยหลายส่วน:
- พื้นที่ชื่อเรื่อง - นี่คือคำอธิบายทั่วไปของแผนที่ แนวคิดพื้นฐานได้รับการแนะนำ ทรัพยากรหลักและผลลัพธ์ของกระบวนการผลิตได้รับการกำหนด
- แดชบอร์ด - คุณสามารถควบคุมการแสดงข้อมูลสำหรับแต่ละผลิตภัณฑ์ได้ที่นี่ สรุปขั้นตอนและขั้นตอนที่นำไปใช้โดยทั่วไปสำหรับผลิตภัณฑ์ทั้งหมดมีให้
- แผนที่เทคโนโลยี - คำอธิบายแบบตารางของกระบวนการทางเทคโนโลยี บนแผนที่:
- ขั้นตอนขั้นตอนและรหัสทั้งหมดจะได้รับ
- มีคำอธิบายสั้น ๆ และครบถ้วนของขั้นตอน;
- มีการระบุทรัพยากรอินพุตและบริการที่ใช้ในแต่ละขั้นตอน
- มีการระบุผลลัพธ์ของแต่ละขั้นตอนและขั้นตอนแยกต่างหาก
- มีการระบุพื้นที่รับผิดชอบสำหรับแต่ละขั้นตอนและขั้นตอน
- ทรัพยากรทางเทคนิค เช่น HDD (SSD), RAM, vCPU และชั่วโมงการทำงานที่จำเป็นในการสนับสนุนงานในขั้นตอนนี้ ทั้งในช่วงเวลาปัจจุบัน - ข้อเท็จจริง และในอนาคต - แผนได้รับการพิจารณาแล้ว
- สำหรับแต่ละผลิตภัณฑ์ มีการระบุว่าขั้นตอนหรือขั้นตอนทางเทคโนโลยีใดบ้างที่ได้รับการนำไปใช้ วางแผนไว้สำหรับการนำไปใช้ ไม่เกี่ยวข้องหรือไม่ได้นำไปใช้
การตัดสินใจตามแผนที่เทคโนโลยี
หลังจากตรวจสอบแผนที่แล้ว คุณสามารถดำเนินการบางอย่างได้ - ขึ้นอยู่กับบทบาทของพนักงานในบริษัท (ผู้จัดการฝ่ายพัฒนา ผู้จัดการผลิตภัณฑ์ ผู้พัฒนา หรือผู้ทดสอบ):
- ทำความเข้าใจว่าขั้นตอนใดขาดหายไปในผลิตภัณฑ์หรือโครงการจริง และประเมินความจำเป็นในการดำเนินการ
- กำหนดขอบเขตความรับผิดชอบระหว่างหลายแผนกหากทำงานในขั้นตอนต่างๆ
- ตกลงสัญญาที่ทางเข้าและทางออกของเวที
- รวมขั้นตอนการทำงานของคุณเข้ากับกระบวนการพัฒนาโดยรวม
- ประเมินความต้องการทรัพยากรที่จัดเตรียมในแต่ละด่านได้แม่นยำยิ่งขึ้น
สรุปทั้งหมดข้างต้น
การกำหนดเส้นทางมีความหลากหลาย ขยายได้ และบำรุงรักษาง่าย การพัฒนาและบำรุงรักษาคำอธิบายของกระบวนการในรูปแบบนี้ง่ายกว่ามากในรูปแบบ IDEF0 เชิงวิชาการที่เข้มงวด นอกจากนี้ คำอธิบายแบบตารางยังง่ายกว่า คุ้นเคยกว่า และมีโครงสร้างดีกว่าแบบจำลองการทำงาน
สำหรับการดำเนินการตามขั้นตอนทางเทคนิค เรามีเครื่องมือภายในพิเศษ CrossBuilder ซึ่งเป็นเครื่องมือเลเยอร์ระหว่างระบบ CI บริการ และโครงสร้างพื้นฐาน นักพัฒนาซอฟต์แวร์ไม่จำเป็นต้องตัดจักรยาน: ในระบบ CI ของเรา การเรียกใช้หนึ่งในสคริปต์ (งานที่เรียกว่า) ของเครื่องมือ CrossBuilder ก็เพียงพอแล้ว ซึ่งจะดำเนินการอย่างถูกต้องโดยคำนึงถึงคุณสมบัติของโครงสร้างพื้นฐานของเรา .
ผลของการ
บทความนี้ค่อนข้างยาว แต่สิ่งนี้หลีกเลี่ยงไม่ได้เมื่ออธิบายการสร้างแบบจำลองของกระบวนการที่ซับซ้อน ในตอนท้าย ฉันต้องการแก้ไขแนวคิดหลักของเราโดยย่อ:
- เป้าหมายของการนำแนวคิด DevOps ไปใช้ในบริษัทของเราคือการลดต้นทุนการผลิตและการบำรุงรักษาผลิตภัณฑ์ของบริษัทอย่างสม่ำเสมอในเชิงปริมาณ (ชั่วโมงการทำงานหรือชั่วโมงเครื่องจักร, vCPU, RAM, ดิสก์)
- วิธีการลดต้นทุนโดยรวมของการพัฒนาคือการลดต้นทุนในการดำเนินงานซีเรียลทั่วไป: ขั้นตอนและขั้นตอนของกระบวนการทางเทคโนโลยี
- งานทั่วไปคืองานที่โซลูชันเป็นแบบอัตโนมัติทั้งหมดหรือบางส่วน ไม่ทำให้ผู้ปฏิบัติงานลำบากและไม่ต้องการค่าแรงจำนวนมาก
- กระบวนการผลิตประกอบด้วยขั้นตอน ขั้นตอนต่างๆ แบ่งออกเป็นขั้นตอนที่แบ่งแยกไม่ได้ ซึ่งเป็นงานทั่วไปที่มีขนาดและขอบเขตต่างกัน
- จากงานทั่วไปที่แตกต่างกัน เรามาถึงห่วงโซ่เทคโนโลยีที่ซับซ้อนและแบบจำลองหลายระดับของกระบวนการผลิต ซึ่งสามารถอธิบายได้ด้วยแบบจำลอง IDEF0 ที่ใช้งานได้หรือแผนที่เทคโนโลยีที่ง่ายกว่า
- แผนที่เทคโนโลยีคือการแสดงตารางของขั้นตอนและขั้นตอนของกระบวนการผลิต สิ่งที่สำคัญที่สุด: แผนที่ช่วยให้คุณเห็นกระบวนการทั้งหมดอย่างครบถ้วนเป็นชิ้นใหญ่โดยมีความเป็นไปได้ในการลงรายละเอียด
- จากแผนที่เทคโนโลยี เป็นไปได้ที่จะประเมินความจำเป็นในการแนะนำขั้นตอนในผลิตภัณฑ์เฉพาะ กำหนดขอบเขตความรับผิดชอบ ตกลงในสัญญาที่อินพุตและเอาต์พุตของขั้นตอน และประเมินความต้องการทรัพยากรได้แม่นยำยิ่งขึ้น
ในบทความต่อไปนี้ เราจะอธิบายรายละเอียดเพิ่มเติมว่าเครื่องมือทางเทคนิคใดบ้างที่ใช้ในการปรับใช้ขั้นตอนทางเทคโนโลยีบางอย่างบนแผนที่ของเรา
ผู้เขียนบทความ:
- — หัวหน้าฝ่ายระบบอัตโนมัติ (DevOps) ที่ Positive Technologies
- - รอง หัวหน้าแผนกระบบอัตโนมัติ (DevOps) ที่ Positive Technologies
ที่มา: will.com