การนำโปรเจ็กต์ใหม่เข้าสู่การใช้งานจริงจำเป็นต้องมีความสมดุลอย่างระมัดระวังระหว่างความเร็วในการปรับใช้และความน่าเชื่อถือของโซลูชัน Slack ให้ความสำคัญกับการวนซ้ำอย่างรวดเร็ว รอบการตอบรับที่สั้น และการตอบสนองต่อคำขอของผู้ใช้ทันที นอกจากนี้ บริษัทยังมีโปรแกรมเมอร์หลายร้อยคนที่มุ่งมั่นที่จะทำงานอย่างมีประสิทธิผลมากที่สุดเท่าที่จะเป็นไปได้
ผู้เขียนเนื้อหาซึ่งเราเผยแพร่ในวันนี้กล่าวว่าบริษัทที่มุ่งมั่นที่จะปฏิบัติตามค่านิยมดังกล่าวและในขณะเดียวกันก็เติบโตขึ้นจะต้องปรับปรุงระบบการปรับใช้โครงการอย่างต่อเนื่อง บริษัทจำเป็นต้องลงทุนในกระบวนการทำงานที่โปร่งใสและเชื่อถือได้ เพื่อให้มั่นใจว่ากระบวนการเหล่านี้สอดคล้องกับขนาดของโครงการ ที่นี่เราจะพูดถึงขั้นตอนการทำงานที่พัฒนาขึ้นใน Slack และเกี่ยวกับการตัดสินใจบางส่วนที่ทำให้บริษัทใช้ระบบการปรับใช้โครงการที่มีอยู่ในปัจจุบัน
กระบวนการปรับใช้โครงการทำงานอย่างไรในปัจจุบัน
PR แต่ละรายการ (คำขอดึง) ใน Slack จะต้องได้รับการตรวจสอบโค้ดและต้องผ่านการทดสอบทั้งหมดให้สำเร็จ หลังจากตรงตามเงื่อนไขเหล่านี้เท่านั้นโปรแกรมเมอร์จึงจะสามารถรวมรหัสของเขาเข้ากับสาขาหลักของโครงการได้ อย่างไรก็ตาม รหัสนี้จะปรับใช้เฉพาะในช่วงเวลาทำการ ตามเวลาอเมริกาเหนือเท่านั้น ด้วยเหตุนี้การที่พนักงานของเราอยู่ที่ที่ทำงาน เราจึงเตรียมพร้อมอย่างเต็มที่ในการแก้ไขปัญหาที่ไม่คาดคิด
ทุกๆ วัน เราดำเนินการปรับใช้ตามแผนประมาณ 12 ครั้ง ในระหว่างการปรับใช้แต่ละครั้ง โปรแกรมเมอร์ที่ได้รับมอบหมายให้เป็นผู้นำการปรับใช้มีหน้าที่รับผิดชอบในการนำบิลด์ใหม่เข้าสู่การใช้งานจริง นี่เป็นกระบวนการหลายขั้นตอนที่ช่วยให้มั่นใจว่าการประกอบจะถูกนำเข้าสู่การผลิตได้อย่างราบรื่น ด้วยวิธีนี้ เราจึงสามารถตรวจพบข้อผิดพลาดก่อนที่จะส่งผลกระทบต่อผู้ใช้ทั้งหมดของเรา หากมีข้อผิดพลาดมากเกินไป การปรับใช้แอสเซมบลีสามารถย้อนกลับได้ หากพบปัญหาเฉพาะหลังการเปิดตัว จะสามารถออกการแก้ไขได้อย่างง่ายดาย
อินเทอร์เฟซของระบบ Checkpoint ซึ่งใช้ใน Slack เพื่อปรับใช้โปรเจ็กต์
กระบวนการปรับใช้รีลีสใหม่สู่การใช้งานจริงอาจประกอบด้วยสี่ขั้นตอน
▍1. การสร้างสาขาการเปิดตัว
แต่ละรีลีสจะเริ่มต้นด้วยสาขารีลีสใหม่ ซึ่งเป็นจุดหนึ่งในประวัติ Git ของเรา ซึ่งจะทำให้คุณสามารถกำหนดแท็กให้กับการเผยแพร่และให้พื้นที่ที่คุณสามารถแก้ไขข้อบกพร่องที่พบในกระบวนการเตรียมการเผยแพร่เพื่อเผยแพร่สู่การใช้งานจริงได้
▍2. การปรับใช้ในสภาพแวดล้อมการแสดงละคร
ขั้นตอนต่อไปคือการปรับใช้แอสเซมบลีบนเซิร์ฟเวอร์ staging และรันการทดสอบอัตโนมัติสำหรับประสิทธิภาพโดยรวมของโปรเจ็กต์ (การทดสอบควัน) สภาพแวดล้อมการจัดเตรียมคือสภาพแวดล้อมการใช้งานจริงที่ไม่ได้รับการรับส่งข้อมูลภายนอก ในสภาพแวดล้อมนี้ เราทำการทดสอบด้วยตนเองเพิ่มเติม สิ่งนี้ทำให้เรามั่นใจเพิ่มเติมว่าโปรเจ็กต์ที่แก้ไขนั้นทำงานได้อย่างถูกต้อง การทดสอบอัตโนมัติเพียงอย่างเดียวไม่เพียงพอที่จะให้ความมั่นใจในระดับนี้
▍3. การทำให้ใช้งานได้ในสภาพแวดล้อมลองใช้และคานารี
การปรับใช้สู่การใช้งานจริงเริ่มต้นด้วยสภาพแวดล้อมการลองใช้ ซึ่งแสดงโดยชุดโฮสต์ที่ให้บริการพื้นที่ทำงาน Slack ภายในของเรา เนื่องจากเราเป็นผู้ใช้ Slack ที่มีความกระตือรือร้น การใช้แนวทางนี้จึงช่วยให้เราตรวจพบจุดบกพร่องจำนวนมากตั้งแต่เนิ่นๆ ในการปรับใช้ หลังจากที่เราตรวจสอบให้แน่ใจว่าฟังก์ชันพื้นฐานของระบบไม่เสียหาย แอสเซมบลีจะถูกปรับใช้ในสภาพแวดล้อมแบบคานารี แสดงถึงระบบที่คิดเป็นประมาณ 2% ของปริมาณการใช้งานจริง
▍4. ค่อย ๆ ปล่อยสู่การผลิต
หากตัวบ่งชี้การตรวจสอบสำหรับรีลีสใหม่มีเสถียรภาพ และหากหลังจากการปรับใช้โปรเจ็กต์ในสภาพแวดล้อมแบบคานารีแล้ว เราไม่ได้รับการร้องเรียนใดๆ เราจะค่อยๆ ถ่ายโอนเซิร์ฟเวอร์ที่ใช้งานจริงไปยังรีลีสใหม่ กระบวนการปรับใช้แบ่งออกเป็นขั้นตอนต่อไปนี้: 10%, 25%, 50%, 75% และ 100% ส่งผลให้เราสามารถถ่ายโอนปริมาณการใช้งานจริงไปยังรีลีสใหม่ของระบบได้ช้าๆ ในขณะเดียวกัน เราก็มีเวลาตรวจสอบสถานการณ์หากตรวจพบความผิดปกติใดๆ
▍จะเกิดอะไรขึ้นหากมีสิ่งผิดปกติเกิดขึ้นระหว่างการใช้งาน?
การแก้ไขโค้ดถือเป็นความเสี่ยงเสมอ แต่เรารับมือกับสิ่งนี้ได้ด้วยการมี "ผู้นำการปรับใช้" ที่ได้รับการฝึกอบรมมาเป็นอย่างดีซึ่งจัดการกระบวนการนำรุ่นใหม่เข้าสู่การผลิต ตรวจสอบตัวบ่งชี้การตรวจสอบ และประสานงานการทำงานของโปรแกรมเมอร์ที่ปล่อยโค้ด
ในกรณีที่มีบางอย่างผิดพลาดจริงๆ เราจะพยายามตรวจพบปัญหาโดยเร็วที่สุด เราตรวจสอบปัญหา ค้นหา PR ที่ทำให้เกิดข้อผิดพลาด ย้อนกลับ วิเคราะห์อย่างละเอียด และสร้างโครงสร้างใหม่ จริงอยู่ที่บางครั้งปัญหาก็ไม่มีใครสังเกตเห็นจนกว่าโครงการจะเข้าสู่การผลิต ในสถานการณ์เช่นนี้ สิ่งที่สำคัญที่สุดคือการคืนค่าบริการ ดังนั้น ก่อนที่เราจะเริ่มตรวจสอบปัญหา เราจะย้อนกลับไปยังรุ่นการทำงานก่อนหน้าทันที
Building Block ของระบบการปรับใช้
มาดูเทคโนโลยีที่รองรับระบบการปรับใช้โครงการของเรากัน
▍ปรับใช้อย่างรวดเร็ว
ขั้นตอนการทำงานที่อธิบายไว้ข้างต้นอาจดูเหมือนค่อนข้างชัดเจนเมื่อมองย้อนกลับไป แต่ระบบการปรับใช้ของเรากลับไม่เป็นเช่นนี้ในทันที
เมื่อบริษัทมีขนาดเล็กลงมาก แอปพลิเคชันทั้งหมดของเราสามารถทำงานได้บนอินสแตนซ์ Amazon EC10 จำนวน 2 รายการ การปรับใช้โปรเจ็กต์ในสถานการณ์นี้หมายถึงการใช้ rsync เพื่อซิงโครไนซ์เซิร์ฟเวอร์ทั้งหมดอย่างรวดเร็ว ก่อนหน้านี้ รหัสใหม่อยู่ห่างจากการใช้งานจริงเพียงหนึ่งขั้นตอน ซึ่งแสดงโดยสภาพแวดล้อมชั่วคราว แอสเซมบลีถูกสร้างขึ้นและทดสอบในสภาพแวดล้อมดังกล่าว จากนั้นจึงเข้าสู่การผลิตโดยตรง ระบบดังกล่าวเข้าใจง่ายมาก โดยอนุญาตให้โปรแกรมเมอร์คนใดคนหนึ่งปรับใช้โค้ดที่เขาเขียนไว้เมื่อใดก็ได้
แต่เมื่อจำนวนลูกค้าของเราเพิ่มขึ้น ขนาดของโครงสร้างพื้นฐานที่จำเป็นในการสนับสนุนโครงการก็เพิ่มตามไปด้วย ในไม่ช้า เนื่องจากระบบมีการเติบโตอย่างต่อเนื่อง โมเดลการปรับใช้ของเราซึ่งอิงจากการพุชโค้ดใหม่ไปยังเซิร์ฟเวอร์ จึงไม่สามารถทำงานได้อีกต่อไป กล่าวคือ การเพิ่มเซิร์ฟเวอร์ใหม่แต่ละเซิร์ฟเวอร์หมายถึงการเพิ่มเวลาที่ต้องใช้ในการปรับใช้ให้เสร็จสมบูรณ์ แม้แต่กลยุทธ์ที่ใช้ rsync แบบขนานก็มีข้อจำกัดบางประการ
เราลงเอยด้วยการแก้ไขปัญหานี้โดยการย้ายไปใช้ระบบการปรับใช้แบบขนานโดยสิ้นเชิง ซึ่งได้รับการออกแบบให้แตกต่างจากระบบเก่า กล่าวคือ ตอนนี้เราไม่ได้ส่งโค้ดไปยังเซิร์ฟเวอร์โดยใช้สคริปต์การซิงโครไนซ์ ตอนนี้เซิร์ฟเวอร์แต่ละเครื่องดาวน์โหลดแอสเซมบลีใหม่อย่างอิสระ โดยรู้ว่าจำเป็นต้องดำเนินการดังกล่าวโดยการตรวจสอบการเปลี่ยนแปลงคีย์กงสุล เซิร์ฟเวอร์โหลดโค้ดแบบขนาน สิ่งนี้ช่วยให้เราสามารถรักษาความเร็วในการปรับใช้ที่สูงได้แม้ในสภาพแวดล้อมที่มีการเติบโตของระบบอย่างต่อเนื่อง
1. เซิร์ฟเวอร์ที่ใช้งานจริงจะตรวจสอบคีย์กงสุล 2. การเปลี่ยนแปลงที่สำคัญ เป็นการแจ้งให้เซิร์ฟเวอร์ทราบว่าจำเป็นต้องเริ่มดาวน์โหลดโค้ดใหม่ 3. เซิร์ฟเวอร์ดาวน์โหลดไฟล์ tarball พร้อมรหัสแอปพลิเคชัน
▍การปรับใช้แบบอะตอมมิก
โซลูชันอื่นที่ช่วยให้เราเข้าถึงระบบการปรับใช้หลายระดับคือการปรับใช้แบบอะตอมมิก
ก่อนที่จะใช้การปรับใช้แบบอะตอมมิก การใช้งานแต่ละครั้งอาจส่งผลให้เกิดข้อความแสดงข้อผิดพลาดจำนวนมาก ความจริงก็คือกระบวนการคัดลอกไฟล์ใหม่ไปยังเซิร์ฟเวอร์ที่ใช้งานจริงไม่ใช่แบบอะตอมมิก ส่งผลให้ช่วงเวลาสั้น ๆ โค้ดที่เรียกว่าฟังก์ชันใหม่พร้อมใช้งานก่อนที่ฟังก์ชันจะพร้อมใช้งาน เมื่อมีการเรียกรหัสดังกล่าว จะส่งผลให้เกิดข้อผิดพลาดภายในถูกส่งกลับ สิ่งนี้แสดงให้เห็นในคำขอ API ที่ล้มเหลวและหน้าเว็บที่ใช้งานไม่ได้
ทีมงานที่ทำงานเกี่ยวกับปัญหานี้แก้ไขได้โดยการแนะนำแนวคิดของไดเร็กทอรี "ร้อน" และ "เย็น" รหัสในไดเร็กทอรีร้อนมีหน้าที่ในการประมวลผลปริมาณการใช้งานจริง และในไดเร็กทอรี "เย็น" โค้ดในขณะที่ระบบกำลังทำงานอยู่นั้นกำลังถูกเตรียมสำหรับการใช้งานเท่านั้น ในระหว่างการปรับใช้ รหัสใหม่จะถูกคัดลอกไปยังไดเร็กทอรีแบบเย็นที่ไม่ได้ใช้ จากนั้น เมื่อไม่มีกระบวนการที่ใช้งานอยู่บนเซิร์ฟเวอร์ จะมีการสลับไดเร็กทอรีทันที
1. คลายโค้ดแอปพลิเคชันลงในไดเร็กทอรี "cold" 2. การสลับระบบเป็นไดเร็กทอรี "เย็น" ซึ่งกลายเป็น "ร้อน" (การดำเนินการแบบอะตอมมิก)
ผลลัพธ์: การเปลี่ยนแปลงโดยเน้นไปที่ความน่าเชื่อถือ
ในปี 2018 โครงการได้ขยายไปถึงระดับที่การใช้งานอย่างรวดเร็วเริ่มส่งผลเสียต่อเสถียรภาพของผลิตภัณฑ์ เรามีระบบการปรับใช้งานขั้นสูงซึ่งเราทุ่มเททั้งเวลาและความพยายามอย่างมาก สิ่งที่เราต้องทำคือสร้างใหม่และปรับปรุงกระบวนการปรับใช้ของเรา เราได้เติบโตขึ้นเป็นบริษัทขนาดใหญ่พอสมควร ซึ่งมีการพัฒนาทั่วโลกเพื่อจัดระเบียบการสื่อสารที่ไม่หยุดชะงักและเพื่อแก้ไขปัญหาที่สำคัญ ดังนั้นความน่าเชื่อถือจึงกลายเป็นจุดสนใจของเรา
เราจำเป็นต้องทำให้กระบวนการปรับใช้ Slack ใหม่มีความปลอดภัยมากขึ้น ความต้องการนี้ทำให้เราปรับปรุงระบบการปรับใช้งานของเรา ตามความเป็นจริง เราได้พูดคุยถึงระบบที่ได้รับการปรับปรุงนี้ข้างต้น ในส่วนลึกของระบบ เรายังคงใช้เทคโนโลยีการปรับใช้ที่รวดเร็วและระดับอะตอมมิกต่อไป วิธีการปรับใช้เสร็จสิ้นเปลี่ยนไป ระบบใหม่ของเราได้รับการออกแบบให้ค่อยๆ ปรับใช้โค้ดใหม่ในระดับต่างๆ ในสภาพแวดล้อมที่แตกต่างกัน ตอนนี้เราใช้เครื่องมือสนับสนุนขั้นสูงและเครื่องมือตรวจสอบระบบมากขึ้นกว่าเดิม สิ่งนี้ทำให้เราสามารถตรวจจับและแก้ไขข้อผิดพลาดได้นานก่อนที่จะมีโอกาสเข้าถึงผู้ใช้ปลายทาง
แต่เราจะไม่หยุดเพียงแค่นั้น เรากำลังปรับปรุงระบบนี้อย่างต่อเนื่องโดยใช้เครื่องมือเสริมขั้นสูงและเครื่องมือระบบอัตโนมัติในการทำงาน
เรียนผู้อ่าน! กระบวนการปรับใช้การเปิดตัวโครงการใหม่ทำงานอย่างไรในที่ที่คุณทำงาน
ที่มา: will.com