แนวทางปฏิบัติ DevOps ได้ผล เรามั่นใจในสิ่งนี้เมื่อเราลดเวลาการติดตั้งรีลีสลง 10 เท่า ในระบบ FIS Profile ซึ่งเราใช้ที่ VTB ขณะนี้การติดตั้งใช้เวลา 90 นาที แทนที่จะใช้เวลา 10 นาที เวลาในการสร้างรุ่นเปิดตัวลดลงจากสองสัปดาห์เหลือสองวัน จำนวนข้อบกพร่องในการใช้งานอย่างต่อเนื่องลดลงเหลือเกือบน้อยที่สุด เพื่อหลีกหนีจาก "การใช้แรงงานคน" และลดการพึ่งพาผู้ขาย เราต้องทำงานกับไม้ค้ำยันและค้นหาวิธีแก้ปัญหาที่ไม่คาดคิด ด้านล่างเป็นเรื่องราวโดยละเอียดเกี่ยวกับวิธีที่เราสร้างการพัฒนาภายในอย่างเต็มรูปแบบ
อารัมภบท: DevOps เป็นปรัชญา
ในปีที่ผ่านมา เราได้ทำงานมากมายเพื่อจัดระเบียบการพัฒนาภายในและการนำแนวทางปฏิบัติ DevOps ไปใช้ที่ VTB:
- เราสร้างกระบวนการพัฒนาภายในสำหรับ 12 ระบบ;
- เราเปิดตัวไปป์ไลน์ 15 ท่อ โดย XNUMX ท่อในนั้นถูกนำเข้าสู่การผลิต
- สถานการณ์การทดสอบ 1445 อัตโนมัติ
- เราประสบความสำเร็จในการนำรุ่นต่างๆ ที่เตรียมไว้โดยทีมงานภายในองค์กรไปใช้
หนึ่งในสิ่งที่ยากที่สุดในการจัดระเบียบการพัฒนาภายในและการนำแนวทางปฏิบัติ DevSecOps ไปใช้กลายเป็นระบบ FIS Profile ซึ่งเป็นตัวประมวลผลผลิตภัณฑ์ขายปลีกบน DBMS ที่ไม่เกี่ยวข้อง อย่างไรก็ตาม เราสามารถสร้างการพัฒนา เปิดตัวไปป์ไลน์ ติดตั้งแพ็คเกจที่ไม่เผยแพร่แต่ละรายการบนผลิตภัณฑ์ และเรียนรู้วิธีการประกอบการเผยแพร่ งานไม่ใช่เรื่องง่าย แต่น่าสนใจและไม่มีข้อจำกัดที่ชัดเจนในการดำเนินการ นี่คือระบบ - คุณต้องสร้างการพัฒนาภายในองค์กร เงื่อนไขเดียวคือการใช้ซีดีก่อนสภาพแวดล้อมที่มีประสิทธิผล
ในตอนแรก อัลกอริธึมการใช้งานดูเรียบง่ายและชัดเจน:
- เราพัฒนาความเชี่ยวชาญในการพัฒนาขั้นต้นและบรรลุคุณภาพในระดับที่ยอมรับได้จากทีมงานโค้ดโดยไม่มีข้อบกพร่องร้ายแรง
- เราบูรณาการเข้ากับกระบวนการที่มีอยู่ให้มากที่สุด
- ในการถ่ายโอนโค้ดระหว่างขั้นตอนที่ชัดเจน เราจะตัดไปป์ไลน์และดันปลายด้านใดด้านหนึ่งของไปป์ไลน์ไปต่อเนื่อง
ในช่วงเวลานี้ ทีมพัฒนาตามขนาดที่ต้องการจะต้องพัฒนาทักษะและเพิ่มส่วนแบ่งในการเผยแพร่ให้อยู่ในระดับที่ยอมรับได้ เพียงเท่านี้เราก็ถือว่างานเสร็จสมบูรณ์แล้ว
ดูเหมือนว่านี่เป็นเส้นทางที่ประหยัดพลังงานโดยสมบูรณ์ไปสู่ผลลัพธ์ที่ต้องการ: นี่คือ DevOps นี่คือตัวชี้วัดประสิทธิภาพของทีม นี่คือความเชี่ยวชาญที่สั่งสมมา... แต่ในทางปฏิบัติ เราได้รับการยืนยันอีกครั้งว่า DevOps ยังคงเกี่ยวกับปรัชญา และไม่ได้ “ติดอยู่กับกระบวนการ gitlab, ansible, Nexus และเพิ่มเติมในรายการ”
หลังจากวิเคราะห์แผนปฏิบัติการอีกครั้ง เราก็ตระหนักว่าเรากำลังสร้างผู้ให้บริการภายนอกภายในตัวเรา ดังนั้น การปรับรื้อกระบวนการจึงถูกเพิ่มเข้าไปในอัลกอริธึมที่อธิบายไว้ข้างต้น เช่นเดียวกับการพัฒนาความเชี่ยวชาญตลอดเส้นทางการพัฒนาทั้งหมดเพื่อให้บรรลุบทบาทผู้นำในกระบวนการนี้ ไม่ใช่ตัวเลือกที่ง่ายที่สุด แต่นี่คือเส้นทางของการพัฒนาที่ถูกต้องตามอุดมคติ
การพัฒนาภายในเริ่มต้นที่ไหน?
มันไม่ใช่ระบบที่เป็นมิตรที่สุดในการทำงานด้วย ในทางสถาปัตยกรรม มันเป็น DBMS ขนาดใหญ่ที่ไม่สัมพันธ์กันตัวหนึ่ง ซึ่งประกอบด้วยออบเจ็กต์ปฏิบัติการแยกจำนวนมาก (สคริปต์ ขั้นตอน แบตช์ ฯลฯ) ซึ่งได้รับการเรียกตามความจำเป็น และทำงานบนหลักการของกล่องดำ: ได้รับการร้องขอและปัญหา การตอบกลับ. ปัญหาอื่น ๆ ที่น่าสังเกต ได้แก่ :
- ภาษาแปลกใหม่ (คางทูม);
- อินเทอร์เฟซคอนโซล
- ขาดการบูรณาการกับเครื่องมือและกรอบงานอัตโนมัติยอดนิยม
- ปริมาณข้อมูลเป็นสิบเทราไบต์
- โหลดการดำเนินงานมากกว่า 2 ล้านครั้งต่อชั่วโมง
- ความสำคัญ - มีความสำคัญต่อธุรกิจ
ในขณะเดียวกันก็ไม่มีที่เก็บซอร์สโค้ดทางฝั่งของเรา เลย. มีเอกสารประกอบ แต่ความรู้และความสามารถหลักทั้งหมดอยู่ด้านข้างขององค์กรภายนอก
เราเริ่มเชี่ยวชาญการพัฒนาระบบตั้งแต่เริ่มต้น โดยคำนึงถึงคุณสมบัติและการกระจายตัวที่ต่ำ เริ่มในเดือนตุลาคม 2018:
- ศึกษาเอกสารและพื้นฐานของการสร้างโค้ด
- เราศึกษาหลักสูตรระยะสั้นด้านการพัฒนาที่ได้รับจากผู้ขาย
- เชี่ยวชาญทักษะการพัฒนาเบื้องต้น
- เรารวบรวมคู่มือการฝึกอบรมสำหรับสมาชิกในทีมใหม่
- เราตกลงที่จะรวมทีมไว้ในโหมด "การต่อสู้"
- แก้ไขปัญหาเกี่ยวกับการควบคุมคุณภาพโค้ด
- เราจัดจุดยืนเพื่อการพัฒนา
เราใช้เวลาสามเดือนในการพัฒนาความเชี่ยวชาญและดำดิ่งลงไปในระบบ และตั้งแต่ต้นปี 2019 การพัฒนาภายในได้เริ่มเคลื่อนไปสู่อนาคตที่สดใส บางครั้งอาจพบกับความยากลำบาก แต่มีความมั่นใจและมีเป้าหมาย
การโยกย้ายพื้นที่เก็บข้อมูลและการทดสอบอัตโนมัติ
งาน DevOps แรกคือพื้นที่เก็บข้อมูล เราตกลงอย่างรวดเร็วในการให้การเข้าถึง แต่จำเป็นต้องย้ายจาก SVN ปัจจุบันที่มีสาขา trunk หนึ่งสาขาไปยัง Git เป้าหมายของเราโดยเปลี่ยนไปใช้โมเดลหลายสาขาและการพัฒนา Git Flow นอกจากนี้เรายังมี 2 ทีมที่มีโครงสร้างพื้นฐานเป็นของตัวเอง รวมถึงทีมผู้จำหน่ายในต่างประเทศอีกด้วย ฉันต้องใช้ Gits สองตัวและรับรองการซิงโครไนซ์ ในสถานการณ์เช่นนี้ มันเป็นความชั่วร้ายที่น้อยกว่าสองประการ
การโยกย้ายพื้นที่เก็บข้อมูลถูกเลื่อนออกไปหลายครั้ง โดยจะแล้วเสร็จในเดือนเมษายนเท่านั้น ด้วยความช่วยเหลือจากเพื่อนร่วมงานจากแนวหน้า ด้วย Git Flow เราตัดสินใจที่จะทำให้สิ่งต่างๆ เป็นเรื่องง่ายสำหรับการเริ่มต้นและตัดสินใจตามแผนแบบคลาสสิกด้วยโปรแกรมแก้ไขด่วน พัฒนา และเผยแพร่ พวกเขาตัดสินใจละทิ้งอาจารย์ (หรือที่เรียกว่า prod-like) ด้านล่างนี้เราจะอธิบายว่าทำไมตัวเลือกนี้จึงเหมาะสมที่สุดสำหรับเรา พื้นที่เก็บข้อมูลภายนอกที่เป็นของผู้ขาย ซึ่งใช้ร่วมกันสำหรับสองทีม ถูกใช้เป็นผู้ปฏิบัติงาน มันซิงโครไนซ์กับพื้นที่เก็บข้อมูลภายในตามกำหนดเวลา ขณะนี้ด้วย Git และ Gitlab ทำให้กระบวนการต่างๆ เป็นอัตโนมัติได้
ปัญหาของการทดสอบอัตโนมัติได้รับการแก้ไขอย่างง่ายดายอย่างน่าประหลาดใจ - เราได้รับเฟรมเวิร์กสำเร็จรูปมาให้ เมื่อคำนึงถึงลักษณะเฉพาะของระบบ การเรียกการดำเนินการแยกกันถือเป็นส่วนที่เข้าใจได้ของกระบวนการทางธุรกิจและในขณะเดียวกันก็ทำหน้าที่เป็นการทดสอบหน่วยด้วย สิ่งที่เหลืออยู่คือการเตรียมข้อมูลการทดสอบและกำหนดลำดับที่ต้องการในการเรียกสคริปต์และประเมินผลลัพธ์ ดังรายการสถานการณ์จำลองที่สร้างขึ้นบนพื้นฐานของสถิติการดำเนินงาน ความสำคัญของกระบวนการและวิธีการถดถอยที่มีอยู่ การทดสอบอัตโนมัติจึงเริ่มปรากฏขึ้น ตอนนี้เราสามารถเริ่มสร้างไปป์ไลน์ได้แล้ว
เป็นอย่างไร: แบบจำลองก่อนระบบอัตโนมัติ
รูปแบบกระบวนการดำเนินการที่มีอยู่เป็นอีกเรื่องหนึ่ง การปรับเปลี่ยนแต่ละครั้งจะถูกถ่ายโอนด้วยตนเองเป็นแพ็คเกจการติดตั้งส่วนเพิ่มแยกต่างหาก ถัดไปคือการลงทะเบียนด้วยตนเองใน Jira และการติดตั้งด้วยตนเองในสภาพแวดล้อม สำหรับแต่ละแพ็คเกจ ทุกอย่างดูชัดเจน แต่เมื่อเตรียมการเปิดตัว สิ่งต่างๆ ก็มีความซับซ้อนมากขึ้น
การประกอบดำเนินการในระดับการส่งมอบแต่ละครั้งซึ่งเป็นวัตถุอิสระ การเปลี่ยนแปลงใด ๆ คือการส่งมอบใหม่ เหนือสิ่งอื่นใด มีการเพิ่มเวอร์ชันทางเทคนิค 60–70 เวอร์ชันลงในแพ็คเกจ 10-15 เวอร์ชันขององค์ประกอบการเปิดตัวหลัก - เวอร์ชันที่ได้รับเมื่อเพิ่มหรือแยกบางอย่างจากการเปิดตัวและสะท้อนถึงการเปลี่ยนแปลงของยอดขายนอกรุ่น
ออบเจ็กต์ภายในการส่งมอบซ้อนทับกัน โดยเฉพาะอย่างยิ่งในโค้ดที่ปฏิบัติการได้ ซึ่งไม่ซ้ำกันไม่ถึงครึ่ง มีการขึ้นต่อกันมากมายทั้งในโค้ดที่ติดตั้งไว้แล้วและโค้ดที่เพิ่งวางแผนการติดตั้ง
เพื่อให้ได้โค้ดเวอร์ชันที่ต้องการ จำเป็นต้องปฏิบัติตามลำดับการติดตั้งอย่างเคร่งครัด ในระหว่างที่วัตถุถูกเขียนใหม่ทางกายภาพหลายครั้ง ประมาณ 10–12 ครั้ง
หลังจากติดตั้งแพ็คเกจเป็นชุด ฉันต้องปฏิบัติตามคำแนะนำด้วยตนเองเพื่อเริ่มการตั้งค่า ผู้จัดจำหน่ายได้ประกอบและติดตั้งรุ่นดังกล่าวแล้ว องค์ประกอบของการเปิดตัวได้รับการชี้แจงเกือบจะก่อนช่วงเวลาของการดำเนินการซึ่งเกี่ยวข้องกับการสร้างแพ็คเกจ "แยกส่วน" เป็นผลให้ส่วนสำคัญของวัสดุสิ้นเปลืองถูกย้ายจากการปล่อยหนึ่งไปยังอีกการปล่อยโดยมีหางของ "การแยกส่วน" ของมันเอง
ตอนนี้เป็นที่ชัดเจนแล้วว่าด้วยวิธีนี้ - การประกอบปริศนาการเปิดตัวในระดับแพ็คเกจ - สาขาหลักเดียวไม่มีความหมายในทางปฏิบัติ การติดตั้งในการผลิตใช้เวลาแรงงานคนหนึ่งชั่วโมงครึ่งถึงสองชั่วโมง เป็นเรื่องดีที่อย่างน้อยในระดับตัวติดตั้งจะมีการระบุลำดับของการประมวลผลออบเจ็กต์: ฟิลด์และโครงสร้างถูกป้อนก่อนข้อมูลสำหรับสิ่งเหล่านั้นและขั้นตอนต่างๆ อย่างไรก็ตาม สิ่งนี้ใช้ได้เฉพาะในแพ็คเกจแยกต่างหากเท่านั้น
ผลลัพธ์เชิงตรรกะของแนวทางนี้คือข้อบกพร่องในการติดตั้งภาคบังคับในรูปแบบของวัตถุเวอร์ชันที่คดเคี้ยว รหัสที่ไม่จำเป็น คำแนะนำที่ขาดหายไป และไม่คำนึงถึงอิทธิพลร่วมกันของวัตถุ ซึ่งถูกกำจัดออกไปอย่างรุนแรงหลังจากปล่อยออกมา
การอัปเดตครั้งแรก: ดำเนินการประกอบและส่งมอบ
ระบบอัตโนมัติเริ่มต้นด้วยการส่งรหัสผ่านไปป์ตามเส้นทางนี้:
- รับการส่งมอบที่เสร็จแล้วจากการจัดเก็บ
- ติดตั้งบนสภาพแวดล้อมเฉพาะ
- เรียกใช้การทดสอบอัตโนมัติ
- ประเมินผลการติดตั้ง
- เรียกไปป์ไลน์ต่อไปนี้ที่ด้านข้างของคำสั่งการทดสอบ
ไปป์ไลน์ถัดไปควรลงทะเบียนงานใน Jira และรอให้กระจายคำสั่งไปยังลูปการทดสอบที่เลือก ซึ่งขึ้นอยู่กับระยะเวลาของการดำเนินงาน ทริกเกอร์ - จดหมายเกี่ยวกับความพร้อมในการจัดส่งไปยังที่อยู่ที่กำหนด แน่นอนว่านี่เป็นไม้ค้ำยันที่ชัดเจน แต่ฉันต้องเริ่มต้นที่ไหนสักแห่ง ในเดือนพฤษภาคม 2019 การโอนรหัสเริ่มต้นด้วยการตรวจสอบสภาพแวดล้อมของเรา กระบวนการได้เริ่มต้นขึ้นแล้ว สิ่งที่เหลืออยู่คือการทำให้มันมีรูปร่างที่เหมาะสม:
- การปรับเปลี่ยนแต่ละครั้งจะดำเนินการในสาขาที่แยกจากกัน ซึ่งสอดคล้องกับแพ็คเกจการติดตั้งและรวมเข้ากับสาขาหลักเป้าหมาย
- ทริกเกอร์การเปิดตัวไปป์ไลน์คือลักษณะของการคอมมิตใหม่ในสาขาหลักผ่านคำขอรวม ซึ่งถูกปิดโดยผู้ดูแลจากทีมภายใน
- ที่เก็บข้อมูลจะซิงโครไนซ์ทุกๆ ห้านาที
- เริ่มต้นการประกอบแพ็คเกจการติดตั้ง - โดยใช้แอสเซมเบลอร์ที่ได้รับจากผู้ขาย
หลังจากนี้ก็มีขั้นตอนการตรวจสอบและโอนโค้ด, เปิดท่อและประกอบฝั่งเราอยู่แล้ว
ตัวเลือกนี้เปิดตัวในเดือนกรกฎาคม ความยากลำบากในการเปลี่ยนแปลงส่งผลให้เกิดความไม่พอใจในหมู่ผู้ขายและแนวหน้า แต่ในเดือนหน้า เราก็สามารถขจัดจุดแข็งทั้งหมดออก และสร้างกระบวนการระหว่างทีมได้ ขณะนี้เรามีการประกอบโดยการส่งและการส่งมอบ
ในเดือนสิงหาคม เราจัดการเพื่อดำเนินการติดตั้งแพ็คเกจแยกต่างหากในการใช้งานจริงเป็นครั้งแรกให้เสร็จสิ้นโดยใช้ไปป์ไลน์ของเรา และตั้งแต่เดือนกันยายน โดยไม่มีข้อยกเว้น การติดตั้งแพ็คเกจที่ยังไม่เผยแพร่แต่ละรายการทั้งหมดได้ดำเนินการผ่านเครื่องมือซีดีของเรา นอกจากนี้ เรายังจัดการเพื่อให้บรรลุส่วนแบ่งของงานภายใน 40% ขององค์ประกอบการเปิดตัวด้วยทีมที่เล็กกว่าผู้จำหน่าย ซึ่งถือเป็นความสำเร็จที่แน่นอน งานที่ร้ายแรงที่สุดยังคงอยู่ - การประกอบและติดตั้งรุ่น
วิธีแก้ปัญหาสุดท้าย: แพ็คเกจการติดตั้งแบบสะสม
เราเข้าใจดีว่าการเขียนสคริปต์คำสั่งของผู้ขายนั้นเป็นระบบอัตโนมัติที่พอใช้ได้ เราต้องคิดใหม่เกี่ยวกับกระบวนการเอง วิธีแก้ปัญหานั้นชัดเจน - เพื่อรวบรวมอุปทานสะสมจากสาขาการเปิดตัวพร้อมอ็อบเจ็กต์ทั้งหมดของเวอร์ชันที่ต้องการ
เราเริ่มต้นด้วยการพิสูจน์แนวคิด: เราประกอบแพ็คเกจการเปิดตัวด้วยมือตามเนื้อหาของการใช้งานที่ผ่านมา และติดตั้งบนสภาพแวดล้อมของเรา ทุกอย่างได้ผลแนวคิดนี้กลับกลายเป็นว่าใช้งานได้ ต่อไป เราได้แก้ไขปัญหาเกี่ยวกับการเขียนสคริปต์การตั้งค่าการเริ่มต้นและรวมไว้ในการคอมมิต เราได้เตรียมแพ็คเกจใหม่และทดสอบในสภาพแวดล้อมการทดสอบโดยเป็นส่วนหนึ่งของการอัปเดตรูปร่าง การติดตั้งสำเร็จ แม้ว่าจะมีความคิดเห็นมากมายจากทีมงานดำเนินการก็ตาม แต่สิ่งสำคัญคือเราได้รับมอบหมายให้ดำเนินการผลิตในการเปิดตัวเดือนพฤศจิกายนพร้อมกับชุดประกอบของเรา
เหลือเวลาอีกเพียงเดือนกว่า สิ่งของที่คัดสรรมาอย่างดีบอกเป็นนัยอย่างชัดเจนว่าเวลากำลังจะหมดลงแล้ว พวกเขาตัดสินใจสร้างบิลด์จากสาขาที่วางจำหน่าย แต่ทำไมจึงต้องแยกออกจากกัน? เราไม่มีแบบ Prod และสาขาที่มีอยู่ก็ไม่ดี - มีโค้ดที่ไม่จำเป็นมากมาย เราต้องรีบตัด prod-likes ออก และนี่คือการคอมมิตมากกว่าสามพันครั้ง การประกอบด้วยมือไม่ใช่ทางเลือกเลย เราร่างสคริปต์ที่ทำงานผ่านบันทึกการติดตั้งผลิตภัณฑ์และรวบรวมคอมมิตไปยังสาขา ครั้งที่สามมันทำงานได้อย่างถูกต้อง และหลังจาก "เสร็จสิ้นด้วยไฟล์" สาขาก็พร้อม
เราเขียนโปรแกรมสร้างของเราเองสำหรับแพ็คเกจการติดตั้งและเสร็จสิ้นภายในหนึ่งสัปดาห์ จากนั้นเราก็ต้องแก้ไขตัวติดตั้งจากฟังก์ชันหลักของระบบ เนื่องจากเป็นโอเพ่นซอร์ส หลังจากตรวจสอบและแก้ไขหลายครั้ง ผลก็ถือว่าสำเร็จ ในขณะเดียวกันองค์ประกอบของการเปิดตัวก็เป็นรูปเป็นร่างสำหรับการติดตั้งที่ถูกต้องซึ่งจำเป็นต้องจัดวงจรทดสอบให้สอดคล้องกับวงจรที่ใช้งานจริงและมีการเขียนสคริปต์แยกต่างหากสำหรับสิ่งนี้
แน่นอนว่ามีความคิดเห็นมากมายเกี่ยวกับการติดตั้งครั้งแรก แต่โดยรวมแล้วโค้ดใช้งานได้ และหลังจากการติดตั้งครั้งที่สาม ทุกอย่างก็เริ่มดูดี การควบคุมองค์ประกอบและการควบคุมเวอร์ชันของวัตถุได้รับการตรวจสอบแยกกันในโหมดแมนนวล ซึ่งในขั้นตอนนี้ค่อนข้างสมเหตุสมผล
ความท้าทายเพิ่มเติมคือจำนวนเกมที่ไม่เผยแพร่จำนวนมากที่ต้องนำมาพิจารณาด้วย แต่ด้วยสาขาที่เหมือน Prod และ Rebase งานจึงโปร่งใส
ครั้งแรก รวดเร็ว และไม่มีข้อผิดพลาด
เราดำเนินการเปิดตัวด้วยทัศนคติในแง่ดีและประสบความสำเร็จในการติดตั้งบนวงจรต่างๆ แต่แท้จริงแล้วหนึ่งวันก่อนถึงเส้นตายปรากฎว่าผู้ขายยังทำงานไม่เสร็จเพื่อเตรียมการเปิดตัวสำหรับการติดตั้งในลักษณะที่ยอมรับ หากบิวด์ของเราใช้งานไม่ได้ด้วยเหตุผลบางประการ การเปิดตัวจะหยุดชะงัก ยิ่งกว่านั้นด้วยความพยายามของเราซึ่งไม่เป็นที่พอใจอย่างยิ่ง เราไม่มีทางถอย ดังนั้นเราจึงคิดผ่านทางเลือกอื่น เตรียมแผนปฏิบัติการ และเริ่มการติดตั้ง
น่าประหลาดใจที่การเปิดตัวทั้งหมดซึ่งประกอบด้วยวัตถุมากกว่า 800 ชิ้นเริ่มต้นอย่างถูกต้องในครั้งแรกและในเวลาเพียง 10 นาที เราใช้เวลาหนึ่งชั่วโมงในการตรวจสอบบันทึกเพื่อค้นหาข้อผิดพลาด แต่ไม่พบข้อผิดพลาดใดๆ
ตลอดวันรุ่งขึ้นแชทการเผยแพร่เงียบกริบ: ไม่มีปัญหาในการใช้งาน เวอร์ชันที่คดเคี้ยว หรือโค้ดที่ "ไม่เหมาะสม" มันเป็นเรื่องที่น่าอึดอัดใจด้วยซ้ำ ต่อมาก็มีความคิดเห็นบางส่วนเกิดขึ้น แต่เมื่อเทียบกับระบบอื่นๆ และประสบการณ์ก่อนหน้านี้ จำนวนและลำดับความสำคัญของพวกเขากลับต่ำกว่าอย่างเห็นได้ชัด
ผลกระทบเพิ่มเติมจากผลกระทบสะสมคือการเพิ่มคุณภาพของการประกอบและการทดสอบ เนื่องจากการติดตั้งเวอร์ชันเต็มหลายครั้ง ข้อบกพร่องของบิลด์และข้อผิดพลาดในการปรับใช้จึงถูกระบุในเวลาที่เหมาะสม การทดสอบในการกำหนดค่าเวอร์ชันเต็มทำให้สามารถระบุข้อบกพร่องเพิ่มเติมในอิทธิพลร่วมกันของวัตถุที่ไม่ปรากฏระหว่างการติดตั้งส่วนเพิ่มได้ ประสบความสำเร็จอย่างแน่นอน โดยเฉพาะอย่างยิ่งเมื่อได้รับการสนับสนุนจากเราถึง 57% ในการเปิดตัว
ผลลัพธ์และข้อสรุป
ในเวลาไม่ถึงหนึ่งปี เราก็สามารถ:
- สร้างการพัฒนาภายในอย่างเต็มรูปแบบโดยใช้ระบบที่แปลกใหม่
- ขจัดการพึ่งพาผู้ขายที่สำคัญ
- เปิดใช้ CI/CD สำหรับมรดกที่ไม่เป็นมิตรอย่างยิ่ง
- ยกระดับกระบวนการดำเนินการไปสู่ระดับทางเทคนิคใหม่
- ลดเวลาในการปรับใช้ลงอย่างมาก
- ลดจำนวนข้อผิดพลาดในการใช้งานลงอย่างมาก
- ประกาศตัวเองอย่างมั่นใจในฐานะผู้เชี่ยวชาญด้านการพัฒนาชั้นนำ
แน่นอนว่าสิ่งที่อธิบายไว้ส่วนใหญ่ดูเหมือนไร้สาระเลย แต่สิ่งเหล่านี้เป็นคุณลักษณะของระบบและข้อจำกัดของกระบวนการที่มีอยู่ในระบบ ในขณะนี้ การเปลี่ยนแปลงส่งผลกระทบต่อผลิตภัณฑ์และบริการของ IS Profile (บัญชีหลัก บัตรพลาสติก บัญชีออมทรัพย์ เอสโครว์ สินเชื่อเงินสด) แต่แนวทางนี้สามารถนำไปใช้กับ IS ใดๆ ก็ตามที่มีการกำหนดภารกิจในการนำแนวทางปฏิบัติ DevOps ไปใช้ โมเดลสะสมสามารถจำลองแบบได้อย่างปลอดภัยสำหรับการใช้งานในภายหลัง (รวมถึงโมเดลที่ไม่เผยแพร่) จากการส่งมอบจำนวนมาก
ที่มา: will.com