ที่ GitLab เราดำเนินการแก้ไขซอฟต์แวร์ด้วยสองวิธี: ด้วยตนเองและโดยอัตโนมัติ อ่านต่อเพื่อเรียนรู้เกี่ยวกับงานของผู้จัดการรุ่นในการสร้างและส่งมอบการอัปเดตที่สำคัญผ่านการปรับใช้อัตโนมัติไปยัง gitlab.com รวมถึงแพตช์สำหรับผู้ใช้เพื่อใช้งานในการติดตั้งของตนเอง
ฉันขอแนะนำให้ตั้งการเตือนบนสมาร์ทวอทช์ของคุณ: ทุกเดือนในวันที่ 22 ผู้ใช้ที่ทำงานกับ GitLab ในสถานประกอบการของตนจะสามารถดูการอัปเดตผลิตภัณฑ์เวอร์ชันปัจจุบันของเราได้ การเปิดตัวรายเดือนมีคุณสมบัติใหม่ การพัฒนาคุณสมบัติที่มีอยู่ และมักจะแสดงผลลัพธ์สุดท้ายของคำขอของชุมชนสำหรับการใช้เครื่องมือหรือการผสาน
แต่ดังที่แสดงให้เห็นในทางปฏิบัติแล้ว การพัฒนาซอฟต์แวร์แทบจะไม่มีข้อบกพร่องเลย เมื่อพบจุดบกพร่องหรือช่องโหว่ด้านความปลอดภัย ผู้จัดการรุ่นในทีมจัดส่งจะสร้างโปรแกรมแก้ไขสำหรับผู้ใช้ของเราพร้อมกับการติดตั้ง Gitlab.com ได้รับการอัปเดตในระหว่างกระบวนการซีดี เราเรียกกระบวนการซีดีนี้ว่าการปรับใช้อัตโนมัติเพื่อหลีกเลี่ยงความสับสนกับฟีเจอร์ซีดีใน GitLab กระบวนการนี้สามารถรวมข้อเสนอแนะจากคำขอดึงที่ส่งโดยผู้ใช้ ลูกค้า และทีมพัฒนาภายในของเรา ดังนั้นการแก้ปัญหาที่น่าเบื่อของการปล่อยแพตช์ได้รับการแก้ไขในสองวิธีที่แตกต่างกันมาก
«เรารับรองว่าทุกสิ่งที่นักพัฒนาทำจะถูกปรับใช้กับทุกสภาพแวดล้อมทุกวันก่อนที่จะเผยแพร่บน GitLab.com"อธิบาย , ผู้จัดการฝ่ายเทคนิคอาวุโส ฝ่ายโครงสร้างพื้นฐาน "คิดว่าการเผยแพร่สำหรับการติดตั้งของคุณเป็นภาพรวมสำหรับการปรับใช้ gitlab.com ซึ่งเราได้เพิ่มขั้นตอนแยกต่างหากเพื่อสร้างแพ็คเกจเพื่อให้ผู้ใช้ของเราสามารถใช้เพื่อติดตั้งในการติดตั้งของพวกเขา'
ไม่ว่าจุดบกพร่องหรือช่องโหว่จะเป็นเช่นไร ลูกค้า gitlab.com จะได้รับการแก้ไขในไม่ช้าหลังจากที่เผยแพร่ ซึ่งถือเป็นข้อดีของกระบวนการซีดีอัตโนมัติ แพทช์สำหรับผู้ใช้ที่มีการติดตั้งของตนเองต้องมีการเตรียมการแยกต่างหากโดยผู้จัดการรุ่น
ทีมจัดส่งกำลังทำงานอย่างหนักเพื่อทำให้กระบวนการส่วนใหญ่ที่เกี่ยวข้องกับการสร้างรุ่นต่างๆ เป็นอัตโนมัติเพื่อลดการเผยแพร่ (เวลาเฉลี่ยในการผลิต เช่น เวลาที่ใช้ในการผลิต) ระยะเวลาตั้งแต่ประมวลผลคำขอรวมโดยนักพัฒนาไปจนถึงการปรับใช้งานบน gitlab.com
«เป้าหมายของทีมส่งของคือเพื่อให้แน่ใจว่าเราจะก้าวไปได้เร็วขึ้นในฐานะบริษัทหรืออย่างน้อยก็ทำให้คนส่งของทำงานเร็วขึ้นใช่ไหม? มารินกล่าว
ทั้งลูกค้า gitlab.com และผู้ใช้การติดตั้งต่างได้รับประโยชน์จากความพยายามของทีมจัดส่งในการลดรอบเวลาและเพิ่มความเร็วในการปรับใช้ ในบทความนี้เราจะอธิบายความเหมือนและความแตกต่างระหว่างทั้งสองวิธีนี้ และเรายังจะอธิบายวิธีที่ทีมจัดส่งของเราเตรียมแพตช์สำหรับผู้ใช้ที่ทำงานในสถานประกอบการของตน ตลอดจนวิธีที่เรารับรองว่า gitlab.com เป็นข้อมูลล่าสุดโดยใช้การปรับใช้อัตโนมัติ
Release Manager ทำหน้าที่อะไร?
สมาชิกในทีมทุกเดือน การเผยแพร่ของเราแก่ผู้ใช้ในสถานประกอบการของพวกเขา รวมถึงแพตช์และการเผยแพร่การรักษาความปลอดภัยที่อาจเกิดขึ้นระหว่างการเผยแพร่ พวกเขายังรับผิดชอบในการเป็นผู้นำการเปลี่ยนแปลงของบริษัทไปสู่การใช้งานแบบอัตโนมัติและต่อเนื่อง
การเผยแพร่การติดตั้งด้วยตนเองและการเผยแพร่ gitlab.com ใช้เวิร์กโฟลว์ที่คล้ายกัน แต่ทำงานในเวลาต่างกัน Marin อธิบาย
ประการแรกและสำคัญที่สุด ตัวจัดการการเผยแพร่ โดยไม่คำนึงถึงประเภทการเผยแพร่ จะตรวจสอบให้แน่ใจว่า GitLab พร้อมใช้งานและปลอดภัยตั้งแต่วินาทีที่เปิดตัวแอปพลิเคชันบน gitlab.com รวมถึงตรวจสอบให้แน่ใจว่าปัญหาเดียวกันนั้นจะไม่จบลงในโครงสร้างพื้นฐานของลูกค้าด้วย ความสามารถของตัวเอง
เมื่อจุดบกพร่องหรือช่องโหว่ได้รับการแก้ไขใน GitLab แล้ว ผู้จัดการรุ่นจะต้องประเมินว่าจะรวมอยู่ในแพตช์หรืออัปเดตความปลอดภัยสำหรับผู้ใช้ที่มีการติดตั้ง หากเขาตัดสินใจว่าจุดบกพร่องหรือช่องโหว่สมควรได้รับการอัปเดต งานเตรียมการจะเริ่มต้นขึ้น
ผู้จัดการรุ่นต้องตัดสินใจว่าจะเตรียมการแก้ไขหรือเมื่อใดที่จะปรับใช้ ซึ่งจะขึ้นอยู่กับบริบทของสถานการณ์เป็นอย่างมาก "ในขณะเดียวกัน เครื่องจักรก็จัดการบริบทได้ไม่ดีเท่ามนุษย์"มารินกล่าว
มันคือทั้งหมดที่เกี่ยวกับการแก้ไข
แพตช์คืออะไร และเหตุใดเราจึงต้องการแพตช์เหล่านั้น
ผู้จัดการรุ่นตัดสินใจว่าจะปล่อยโปรแกรมแก้ไขตามความรุนแรงของจุดบกพร่องหรือไม่
ข้อผิดพลาดจะแตกต่างกันไปขึ้นอยู่กับความรุนแรง ดังนั้นข้อผิดพลาด S4 หรือ S3 อาจเป็นรูปแบบ เช่น การแทนที่พิกเซลหรือไอคอน สิ่งนี้มีความสำคัญไม่น้อยไปกว่า แต่ไม่มีผลกระทบที่มีนัยสำคัญต่อเวิร์กโฟลว์ของใครก็ตาม ซึ่งหมายความว่าโอกาสที่การแก้ไขจะถูกสร้างขึ้นสำหรับข้อผิดพลาด S3 หรือ S4 ดังกล่าวนั้นมีน้อย Marin อธิบาย
อย่างไรก็ตาม ช่องโหว่ S1 หรือ S2 หมายความว่าผู้ใช้ไม่ควรอัปเดตเป็นเวอร์ชันล่าสุด หรือมีข้อบกพร่องที่สำคัญที่ส่งผลต่อขั้นตอนการทำงานของผู้ใช้ หากรวมอยู่ในตัวติดตาม แสดงว่าผู้ใช้จำนวนมากพบปัญหาดังกล่าว ดังนั้นผู้จัดการรุ่นจึงเริ่มเตรียมการแก้ไขทันที
เมื่อแพทช์สำหรับช่องโหว่ S1 หรือ S2 พร้อมแล้ว ตัวจัดการการเปิดตัวจะเริ่มปล่อยแพทช์
ตัวอย่างเช่น แพตช์ GitLab 12.10.1 ถูกสร้างขึ้นหลังจากระบุปัญหาการบล็อกหลายประการ และนักพัฒนาได้แก้ไขปัญหาพื้นฐานที่เป็นสาเหตุ ผู้จัดการรุ่นเผยแพร่ประเมินความถูกต้องของระดับความรุนแรงที่กำหนด และหลังจากการยืนยัน กระบวนการเปิดตัวโปรแกรมแก้ไขก็เริ่มขึ้น ซึ่งพร้อมดำเนินการภายใน XNUMX ชั่วโมงหลังจากค้นพบปัญหาการบล็อก
เมื่อมี S4, S3 และ S2 สะสมจำนวนมาก Release Manager จะพิจารณาบริบทเพื่อระบุความเร่งด่วนในการเปิดตัวโปรแกรมแก้ไข และเมื่อถึงจำนวนที่กำหนดแล้ว รายการทั้งหมดจะรวมกันและเผยแพร่ การแก้ไขหลังการวางจำหน่ายหรือการอัปเดตความปลอดภัยมีการสรุปไว้ในโพสต์บนบล็อก
วิธีที่ผู้จัดการรุ่นสร้างแพตช์
เราใช้ GitLab CI และคุณสมบัติอื่นๆ เช่น ChatOps เพื่อสร้างแพตช์ ตัวจัดการการเผยแพร่เริ่มการเปิดตัวการแก้ไขโดยเปิดใช้งานทีม ChatOps บนช่องทางภายในของเรา #releases ในสแลค
/chatops run release prepare 12.10.1ChatOps ทำงานภายใน Slack เพื่อทริกเกอร์เหตุการณ์ต่างๆ ซึ่งจากนั้นจะถูกประมวลผลและดำเนินการโดย GitLab ตัวอย่างเช่น ทีมจัดส่งได้ตั้งค่า ChatOps เพื่อดำเนินการต่างๆ โดยอัตโนมัติเพื่อเผยแพร่แพตช์
เมื่อ Release Manager เริ่มทีม ChatOps ใน Slack งานที่เหลือจะเกิดขึ้นโดยอัตโนมัติใน GitLab โดยใช้ CICD มีการสื่อสารสองทางระหว่าง ChatOps ใน Slack และ GitLab ในระหว่างกระบวนการเผยแพร่ เนื่องจาก Release Manager เปิดใช้งานขั้นตอนหลักบางขั้นตอนในกระบวนการ
วิดีโอด้านล่างแสดงกระบวนการทางเทคนิคในการเตรียมแพตช์สำหรับ GitLab
การปรับใช้อัตโนมัติทำงานอย่างไรบน gitlab.com
กระบวนการและเครื่องมือที่ใช้ในการอัปเดต gitlab.com นั้นคล้ายคลึงกับกระบวนการและเครื่องมือที่ใช้สร้างแพตช์ การอัปเดต gitlab.com ต้องการการทำงานด้วยตนเองน้อยลงจากมุมมองของผู้จัดการรุ่น
แทนที่จะใช้งานการปรับใช้โดยใช้ ChatOps เราใช้คุณสมบัติ CI เช่น ซึ่งผู้จัดการรุ่นสามารถกำหนดเวลาการดำเนินการบางอย่างให้ดำเนินการในเวลาที่ต้องการได้ แทนที่จะเป็นกระบวนการที่ต้องดำเนินการด้วยตนเอง มีไปป์ไลน์ที่ทำงานเป็นระยะๆ ชั่วโมงละครั้งเพื่อดาวน์โหลดการเปลี่ยนแปลงใหม่ที่ทำกับโปรเจ็กต์ GitLab จัดแพ็กเกจและกำหนดเวลาการปรับใช้ และรันการทดสอบ QA และขั้นตอนที่จำเป็นอื่นๆ โดยอัตโนมัติ
“ดังนั้นเราจึงมีการปรับใช้จำนวนมากที่ทำงานในสภาพแวดล้อมที่แตกต่างกันก่อน gitlab.com และหลังจากที่สภาพแวดล้อมเหล่านั้นอยู่ในสภาพดีและการทดสอบแสดงให้เห็นผลลัพธ์ที่ดี ตัวจัดการการเผยแพร่จะเริ่มการดำเนินการปรับใช้ gitlab.com” Marin กล่าว
เทคโนโลยี CICD สำหรับการรองรับการอัปเดต gitlab.com จะทำให้กระบวนการทั้งหมดเป็นอัตโนมัติจนถึงจุดที่ผู้จัดการรุ่นต้องเปิดใช้การปรับใช้สภาพแวดล้อมการผลิตใน gitlab.com ด้วยตนเอง
Marin อธิบายรายละเอียดเกี่ยวกับกระบวนการอัปเดต gitlab.com ในวิดีโอด้านล่าง
ทีมงานจัดส่งทำอะไรอีกบ้าง?
ข้อแตกต่างที่สำคัญระหว่างกระบวนการอัปเดต gitlab.com และการปล่อยแพตช์ให้กับลูกค้าภายในองค์กรก็คือ กระบวนการหลังต้องใช้เวลามากขึ้นและทำงานด้วยตนเองมากขึ้นจากผู้จัดการการเผยแพร่
“บางครั้งเราชะลอการปล่อยแพตช์ให้กับลูกค้าด้วยการติดตั้งเนื่องจากปัญหาที่รายงาน ปัญหาด้านเครื่องมือ และเนื่องจากมีความแตกต่างหลายประการที่ต้องนำมาพิจารณาเมื่อปล่อยแพตช์เดียว” Marin กล่าว
เป้าหมายระยะสั้นอย่างหนึ่งของทีมจัดส่งคือการลดปริมาณงานด้วยตนเองในส่วนของผู้จัดการรุ่นเพื่อเร่งการเปิดตัว ทีมงานกำลังทำงานเพื่อลดความซับซ้อน ปรับปรุง และทำให้กระบวนการเผยแพร่เป็นอัตโนมัติ ซึ่งจะช่วยแก้ไขปัญหาที่มีความรุนแรงต่ำ (S3 และ S4, ประมาณ นักแปล). การมุ่งเน้นที่ความเร็วเป็นตัวบ่งชี้ประสิทธิภาพหลัก: จำเป็นต้องลด MTTP - เวลาจากการได้รับคำขอรวมเพื่อปรับใช้ผลลัพธ์บน gitlab.com - จาก 50 ชั่วโมงปัจจุบันเป็น 8 ชั่วโมง
ทีมจัดส่งยังดำเนินการย้าย gitlab.com ไปยังโครงสร้างพื้นฐานที่ใช้ Kubernetes อีกด้วย
หมายเหตุบรรณาธิการ: หากคุณเคยได้ยินเกี่ยวกับเทคโนโลยี Kubernetes แล้ว (และฉันไม่สงสัยเลยว่าคุณมี) แต่ยังไม่ได้สัมผัสด้วยมือของคุณ ฉันขอแนะนำให้เข้าร่วมหลักสูตรเร่งรัดออนไลน์ ซึ่งจะจัดขึ้นในวันที่ 28-30 กันยายน และ ซึ่งจะจัดขึ้นในวันที่ 14–16 ตุลาคม สิ่งนี้จะช่วยให้คุณนำทางและทำงานกับเทคโนโลยีได้อย่างมั่นใจ
สองแนวทางที่บรรลุเป้าหมายเดียวกัน ได้แก่ การส่งมอบการอัปเดตที่รวดเร็ว ทั้งสำหรับ gitlab.com และสำหรับลูกค้าที่โรงงานของตน
มีความคิดเห็นหรือคำแนะนำสำหรับเราบ้างไหม?
เรายินดีให้ทุกคนมีส่วนร่วมใน GitLab และเรายินดีรับคำติชมจากผู้อ่านของเรา หากคุณมีไอเดียสำหรับทีมจัดส่งของเรา อย่าลังเลเลย พร้อมแจ้งให้ทราบ team: Delivery.
ที่มา: will.com