จากสคริปต์ไปจนถึงแพลตฟอร์มของเราเอง: วิธีที่เราพัฒนาอัตโนมัติที่ CIAN

ที่ RIT 2019 Alexander Korotkov เพื่อนร่วมงานของเราได้ทำ รายงาน เกี่ยวกับระบบอัตโนมัติของการพัฒนาที่ CIAN: เพื่อทำให้ชีวิตและการทำงานง่ายขึ้น เราใช้แพลตฟอร์ม Integro ของเราเอง ติดตามวงจรชีวิตของงาน ช่วยให้นักพัฒนาไม่ต้องดำเนินการตามปกติ และลดจำนวนจุดบกพร่องในการผลิตได้อย่างมาก ในโพสต์นี้ เราจะเสริมรายงานของ Alexander และบอกคุณว่าเราเปลี่ยนจากสคริปต์ธรรมดาไปสู่การรวมผลิตภัณฑ์โอเพ่นซอร์สผ่านแพลตฟอร์มของเราได้อย่างไร และสิ่งที่ทีมระบบอัตโนมัติที่แยกจากกันของเราทำได้อย่างไร
 

ระดับศูนย์

“ไม่มีสิ่งที่เรียกว่าระดับศูนย์ ฉันไม่รู้เรื่องนั้น”
อาจารย์ชิฟู่ จากภาพยนตร์เรื่อง "กังฟูแพนด้า"

ระบบอัตโนมัติที่ CIAN เริ่มต้นขึ้นหลังจากก่อตั้งบริษัทได้ 14 ปี ตอนนั้นมีทีมงานพัฒนาอยู่ 35 คน ยากที่จะเชื่อใช่ไหม? แน่นอนว่าระบบอัตโนมัติมีอยู่ในบางรูปแบบ แต่ทิศทางที่แยกจากกันสำหรับการบูรณาการอย่างต่อเนื่องและการส่งมอบโค้ดเริ่มเป็นรูปเป็นร่างในปี 2015 

ในเวลานั้น เรามี Python, C# และ PHP จำนวนมหาศาลที่ใช้งานบนเซิร์ฟเวอร์ Linux/Windows ในการปรับใช้สัตว์ประหลาดตัวนี้ เรามีชุดสคริปต์ที่เราเรียกใช้ด้วยตนเอง นอกจากนี้ยังมีการรวมตัวของเสาหินซึ่งนำมาซึ่งความเจ็บปวดและความทุกข์ทรมานเนื่องจากความขัดแย้งเมื่อรวมกิ่งก้าน แก้ไขข้อบกพร่อง และสร้างใหม่ "ด้วยภารกิจที่แตกต่างกันในการก่อสร้าง" กระบวนการที่เรียบง่ายมีลักษณะดังนี้:

เราไม่พอใจกับสิ่งนี้ และเราต้องการสร้างกระบวนการสร้างและปรับใช้ที่ทำซ้ำได้ เป็นอัตโนมัติ และจัดการได้ สำหรับสิ่งนี้ เราต้องการระบบ CI/CD และเราเลือกระหว่าง Teamcity เวอร์ชันฟรีและ Jenkins เวอร์ชันฟรี เนื่องจากเราทำงานร่วมกับระบบเหล่านี้และทั้งคู่ก็เหมาะกับเราในแง่ของชุดฟังก์ชัน เราเลือก Teamcity เป็นผลิตภัณฑ์ใหม่ล่าสุด ในเวลานั้น เรายังไม่ได้ใช้สถาปัตยกรรมไมโครเซอร์วิส และไม่ได้คาดหวังงานและโครงการจำนวนมาก

เรามาถึงแนวคิดของระบบของเราเอง

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

Teamcity จัดการกับระบบอัตโนมัติในระดับการเปิดตัวกระบวนการสร้างและการใช้งาน ในขณะที่ Integro มุ่งเน้นไปที่ระบบอัตโนมัติระดับบนสุดของกระบวนการพัฒนา จำเป็นต้องรวมงานกับปัญหาใน Jira เข้ากับการประมวลผลซอร์สโค้ดที่เกี่ยวข้องใน Bitbucket ในขั้นตอนนี้ Integro เริ่มมีขั้นตอนการทำงานของตัวเองสำหรับการทำงานกับงานประเภทต่างๆ 

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

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

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

เราทำการทดสอบอัตโนมัติ

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

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

ทีมงานอัตโนมัติ

ขณะนี้เรามีเจ้าหน้าที่จำนวน 130 คน และเราจะดำเนินการต่อไป ที่จะเติบโต. ทีมงานสำหรับการบูรณาการอย่างต่อเนื่องและการส่งมอบโค้ด (ต่อไปนี้จะเรียกว่าทีม Deploy and Integration หรือ DI) ประกอบด้วย 7 คนและทำงานใน 2 ทิศทาง: การพัฒนาแพลตฟอร์มระบบอัตโนมัติ Integro และ DevOps 

DevOps รับผิดชอบสภาพแวดล้อม Dev/Beta ของไซต์ CIAN ซึ่งเป็นสภาพแวดล้อม Integro ช่วยนักพัฒนาแก้ปัญหาและพัฒนาแนวทางใหม่ในการปรับขนาดสภาพแวดล้อม ทิศทางการพัฒนา Integro เกี่ยวข้องกับทั้ง Integro และบริการที่เกี่ยวข้อง เช่น ปลั๊กอินสำหรับ Jenkins, Jira, Confluence และยังพัฒนายูทิลิตี้เสริมและแอปพลิเคชันสำหรับทีมพัฒนาอีกด้วย 

ทีม DI ทำงานร่วมกับทีม Platform ซึ่งพัฒนาสถาปัตยกรรม ไลบรารี และแนวทางการพัฒนาภายใน ในขณะเดียวกัน นักพัฒนาภายใน CIAN ก็สามารถมีส่วนร่วมในระบบอัตโนมัติได้ เช่น สร้างระบบอัตโนมัติขนาดเล็กเพื่อให้เหมาะกับความต้องการของทีม หรือแบ่งปันแนวคิดดีๆ เกี่ยวกับวิธีทำให้ระบบอัตโนมัติดียิ่งขึ้น

เลเยอร์เค้กของระบบอัตโนมัติที่ CIAN

ระบบทั้งหมดที่เกี่ยวข้องกับระบบอัตโนมัติสามารถแบ่งออกเป็นหลายชั้น:

1. ระบบภายนอก (Jira, Bitbucket ฯลฯ) ทีมพัฒนาทำงานร่วมกับพวกเขา
2. แพลตฟอร์มอินทิโกร บ่อยครั้งที่นักพัฒนาไม่ได้ทำงานร่วมกับมันโดยตรง แต่เป็นสิ่งที่ทำให้ระบบอัตโนมัติทั้งหมดทำงานต่อไป
3. บริการจัดส่ง จัดเตรียม และค้นพบ (เช่น Jeknins กงสุล Nomad) ด้วยความช่วยเหลือของพวกเขา เราจึงปรับใช้โค้ดบนเซิร์ฟเวอร์และรับรองว่าบริการต่างๆ จะทำงานร่วมกันได้
4. ฟิสิคัลเลเยอร์ (เซิร์ฟเวอร์ ระบบปฏิบัติการ ซอฟต์แวร์ที่เกี่ยวข้อง) รหัสของเราทำงานในระดับนี้ นี่อาจเป็นได้ทั้งเซิร์ฟเวอร์จริงหรือเซิร์ฟเวอร์เสมือน (LXC, KVM, Docker)

ตามแนวคิดนี้ เราแบ่งพื้นที่รับผิดชอบภายในทีม DI สองระดับแรกอยู่ในขอบเขตความรับผิดชอบของทิศทางการพัฒนา Integro และสองระดับสุดท้ายอยู่ในขอบเขตความรับผิดชอบของ DevOps อยู่แล้ว การแยกจากกันนี้ช่วยให้เรามุ่งความสนใจไปที่งานและไม่รบกวนการมีปฏิสัมพันธ์เนื่องจากเราอยู่ใกล้กันและแลกเปลี่ยนความรู้และประสบการณ์อย่างต่อเนื่อง

เต็ม

มามุ่งเน้นไปที่ Integro และเริ่มต้นด้วยกลุ่มเทคโนโลยี:

• เซนโอเอส 7
• นักเทียบท่า + เร่ร่อน + กงสุล + ห้องนิรภัย
• Java 11 (Integro monolith เก่าจะยังคงอยู่ใน Java 8)
• Spring Boot 2.X + การกำหนดค่า Spring Cloud
• PostgreSql11
• RabbitMQ 
• อาปาเช่จุดชนวน
• Camunda (ฝัง)
• Grafana + กราไฟท์ + โพร + เยเกอร์ + ELK
• UI เว็บ: ตอบสนอง (CSR) + MobX
• SSO: เสื้อคลุมกุญแจ

เรายึดมั่นในหลักการของการพัฒนาไมโครเซอร์วิส แม้ว่าเราจะมีมรดกในรูปแบบของ Integro เวอร์ชันแรกๆ ก็ตาม ไมโครเซอร์วิสแต่ละรายการทำงานในคอนเทนเนอร์ Docker ของตัวเอง และบริการสื่อสารกันผ่านคำขอ HTTP และข้อความ RabbitMQ ไมโครเซอร์วิสจะค้นหากันและกันผ่านทางกงสุลและทำการร้องขอ โดยผ่านการอนุญาตผ่าน SSO (Keycloak, OAuth 2/OpenID Connect)

เพื่อเป็นตัวอย่างในชีวิตจริง ลองโต้ตอบกับเจนกินส์ ซึ่งประกอบด้วยขั้นตอนต่อไปนี้:

1. ไมโครเซอร์วิสการจัดการเวิร์กโฟลว์ (ต่อไปนี้จะเรียกว่าไมโครเซอร์วิส Flow) ต้องการเรียกใช้บิลด์ใน Jenkins ในการดำเนินการนี้ เขาใช้กงสุลเพื่อค้นหา IP:PORT ของไมโครเซอร์วิสสำหรับการผสานรวมกับ Jenkins (ต่อไปนี้จะเรียกว่าไมโครเซอร์วิสของ Jenkins) และส่งคำขอแบบอะซิงโครนัสไปเพื่อเริ่มการสร้างใน Jenkins
2. หลังจากได้รับคำขอแล้ว ไมโครเซอร์วิส Jenkins จะสร้างและตอบกลับด้วยรหัสงาน ซึ่งสามารถใช้เพื่อระบุผลลัพธ์ของงานได้ ในเวลาเดียวกัน จะทริกเกอร์บิลด์ใน Jenkins ผ่านการเรียก REST API
3. Jenkins ดำเนินการสร้าง และหลังจากเสร็จสิ้นแล้ว จะส่ง webhook พร้อมผลการดำเนินการไปยังไมโครเซอร์วิสของ Jenkins
4. ไมโครเซอร์วิสของ Jenkins ที่ได้รับ webhook จะสร้างข้อความเกี่ยวกับความสมบูรณ์ของการประมวลผลคำขอ และแนบผลการดำเนินการไปกับเว็บฮุค ข้อความที่สร้างขึ้นจะถูกส่งไปยังคิว RabbitMQ
5. ข้อความที่เผยแพร่จะเข้าถึงไมโครเซอร์วิส Flow ผ่านทาง RabbitMQ ซึ่งเรียนรู้เกี่ยวกับผลลัพธ์ของการประมวลผลงานโดยจับคู่รหัสงานจากคำขอและข้อความที่ได้รับ

ขณะนี้เรามีไมโครเซอร์วิสประมาณ 30 รายการ ซึ่งสามารถแบ่งออกเป็นหลายกลุ่ม:

1. การจัดการการตั้งค่า.
2. ข้อมูลและการโต้ตอบกับผู้ใช้ (ผู้ส่งสาร จดหมาย)
3. การทำงานกับซอร์สโค้ด
4. บูรณาการกับเครื่องมือการปรับใช้ (เจนกินส์, เร่ร่อน, กงสุล ฯลฯ )
5. การตรวจสอบ (การเผยแพร่ ข้อผิดพลาด ฯลฯ)
6. ยูทิลิตี้เว็บ (UI สำหรับจัดการสภาพแวดล้อมการทดสอบ การรวบรวมสถิติ ฯลฯ)
7. บูรณาการกับตัวติดตามงานและระบบที่คล้ายกัน
8. การจัดการเวิร์กโฟลว์สำหรับงานต่างๆ

งานเวิร์กโฟลว์

Integro ดำเนินกิจกรรมที่เกี่ยวข้องกับวงจรชีวิตงานโดยอัตโนมัติ พูดง่ายๆ ก็คือ วงจรชีวิตของงานจะเข้าใจว่าเป็นเวิร์กโฟลว์ของงานใน Jira กระบวนการพัฒนาของเรามีขั้นตอนการทำงานที่หลากหลาย ขึ้นอยู่กับโครงการ ประเภทของงาน และตัวเลือกที่เลือกในงานเฉพาะ 

มาดูขั้นตอนการทำงานที่เราใช้บ่อยที่สุด:

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

การทดสอบด้วยตนเองอย่างสมบูรณ์บน DEV+BETA โดยไม่มีการทดสอบ Canary (โดยปกติแล้วนี่คือวิธีที่เราเผยแพร่ Monolith)

อาจมีการผสมผสานการเปลี่ยนแปลงอื่นๆ บางครั้งสามารถเลือกเส้นทางที่ปัญหาจะเกิดขึ้นได้ผ่านตัวเลือกใน Jira

การเคลื่อนไหวของงาน

มาดูขั้นตอนหลักที่จะดำเนินการเมื่องานเคลื่อนผ่านเวิร์กโฟลว์ “การทดสอบ DEV + การทดสอบ Canary”:

1. ผู้พัฒนาหรือ PM สร้างงาน

2. นักพัฒนารับงานไปทำงาน หลังจากเสร็จสิ้น จะสลับไปที่สถานะอยู่ระหว่างการตรวจสอบ

3. Jira ส่ง Webhook ไปยังไมโครเซอร์วิสของ Jira (รับผิดชอบในการผสานรวมกับ Jira)

4. ไมโครเซอร์วิส Jira ส่งคำขอไปยังบริการ Flow (รับผิดชอบเวิร์กโฟลว์ภายในที่ดำเนินการงาน) เพื่อเริ่มเวิร์กโฟลว์

5. บริการภายใน Flow:

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

  i) การอัปเดตสาขาหลัก (Git microservice สำหรับการทำงานกับโค้ด)
  ii) สาขาถูกบล็อกจากการเปลี่ยนแปลงโดยนักพัฒนา (ไมโครเซอร์วิส Bitbucket)
  iii) Pull Request ถูกสร้างขึ้นสำหรับสาขานี้ (ไมโครเซอร์วิส Bitbucket)
  iv) ข้อความเกี่ยวกับคำขอดึงใหม่จะถูกส่งไปยังแชทของนักพัฒนา (แจ้งไมโครเซอร์วิสสำหรับการทำงานกับการแจ้งเตือน)
  v) งานสร้าง ทดสอบ และปรับใช้เริ่มต้นบน DEV (ไมโครเซอร์วิสของ Jenkins สำหรับการทำงานกับ Jenkins)
  vi) หากขั้นตอนก่อนหน้าทั้งหมดเสร็จสมบูรณ์ Integro จะใส่ Approve ไว้ใน Pull Request (ไมโครเซอร์วิส Bitbucket)

• Integro รอการอนุมัติในคำขอดึงจากผู้ตรวจสอบที่ได้รับมอบหมาย
• ทันทีที่ได้รับการอนุมัติที่จำเป็นทั้งหมด (รวมถึงการทดสอบอัตโนมัติผ่านไปด้วยดี) Integro จะโอนงานไปเป็นสถานะ Test on Dev (Jira microservice)

6. ผู้ทดสอบทำการทดสอบงาน หากไม่มีปัญหา งานจะถูกโอนไปยังสถานะพร้อมสำหรับการสร้าง

7. Integro “มองเห็น” ว่างานพร้อมสำหรับการเปิดตัวและเริ่มการปรับใช้ในโหมดคานารี (ไมโครเซอร์วิสของ Jenkins) ความพร้อมในการปล่อยตัวถูกกำหนดโดยชุดของกฎ ตัวอย่างเช่น งานอยู่ในสถานะที่ต้องการ ไม่มีการล็อกงานอื่นๆ ขณะนี้ไม่มีการอัปโหลดไมโครเซอร์วิสนี้ที่ใช้งานอยู่ เป็นต้น

8. งานถูกโอนไปยังสถานะ Canary (ไมโครเซอร์วิส Jira)

9. Jenkins เปิดตัวงานการปรับใช้ผ่าน Nomad ในโหมด canary (ปกติ 1-3 อินสแตนซ์) และแจ้งบริการตรวจสอบการเปิดตัว (ไมโครเซอร์วิส DeployWatch) เกี่ยวกับการปรับใช้

10. ไมโครเซอร์วิส DeployWatch จะรวบรวมพื้นหลังของข้อผิดพลาดและตอบสนองต่อข้อผิดพลาดนั้น หากจำเป็น หากเกินพื้นหลังของข้อผิดพลาด (บรรทัดฐานของพื้นหลังจะถูกคำนวณโดยอัตโนมัติ) นักพัฒนาจะได้รับแจ้งผ่านไมโครเซอร์วิสแจ้งเตือน หากผ่านไป 5 นาทีนักพัฒนาไม่ตอบสนอง (คลิกเปลี่ยนกลับหรือคงอยู่) ระบบจะเปิดใช้งานการย้อนกลับอัตโนมัติของอินสแตนซ์ Canary หากไม่เกินพื้นหลัง นักพัฒนาจะต้องเปิดใช้งานการปรับใช้งานไปยังการผลิตด้วยตนเอง (โดยการคลิกปุ่มใน UI) หากภายใน 60 นาที นักพัฒนาไม่ได้เปิดตัวการปรับใช้สู่การใช้งานจริง อินสแตนซ์ Canary จะถูกย้อนกลับด้วยเหตุผลด้านความปลอดภัยด้วย

11. หลังจากเปิดตัวการปรับใช้กับการใช้งานจริง:

• งานจะถูกโอนไปยังสถานะการผลิต (ไมโครเซอร์วิส Jira)
• ไมโครเซอร์วิส Jenkins เริ่มกระบวนการปรับใช้และแจ้งไมโครเซอร์วิส DeployWatch เกี่ยวกับการปรับใช้
• ไมโครเซอร์วิส DeployWatch จะตรวจสอบว่าคอนเทนเนอร์ทั้งหมดในการผลิตได้รับการอัปเดตแล้ว (มีหลายกรณีที่ไม่ได้รับการอัปเดตทั้งหมด)
• การแจ้งเตือนเกี่ยวกับผลลัพธ์ของการปรับใช้จะถูกส่งไปยังการผลิตผ่านไมโครเซอร์วิสแจ้งเตือน

12. นักพัฒนาจะมีเวลา 30 นาทีในการเริ่มย้อนกลับงานจากการผลิต หากตรวจพบพฤติกรรมไมโครเซอร์วิสที่ไม่ถูกต้อง หลังจากเวลานี้ งานจะถูกรวมเข้ากับมาสเตอร์ (ไมโครเซอร์วิส Git) โดยอัตโนมัติ

13. หลังจากรวมเข้ากับมาสเตอร์สำเร็จแล้ว สถานะของงานจะเปลี่ยนเป็นปิด (ไมโครเซอร์วิส Jira)

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

มีอะไรต่อไป

เรามีแผนใหญ่สำหรับการพัฒนาระบบอัตโนมัติ เช่น ขจัดการดำเนินการด้วยตนเองในระหว่างการเผยแพร่ครั้งใหญ่ การปรับปรุงการตรวจสอบในระหว่างการปรับใช้อัตโนมัติ และปรับปรุงปฏิสัมพันธ์กับนักพัฒนา

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

ที่มา: will.com