ครั้งหนึ่งเราเคยจัดหาระบบการจัดการเอกสารอิเล็กทรอนิกส์ให้กับลูกค้าที่โรงงานแห่งเดียว แล้วไปยังวัตถุอื่น และอีกอย่างหนึ่ง และในวันที่สี่และห้า เราถูกพาตัวไปจนไปถึงวัตถุที่กระจายอยู่ 10 ชิ้น มันกลับกลายเป็นว่าทรงพลัง... โดยเฉพาะอย่างยิ่งเมื่อเราต้องทำการเปลี่ยนแปลง ในส่วนหนึ่งของการส่งมอบไปยังวงจรการผลิต ในที่สุด 5 สถานการณ์ของระบบการทดสอบต้องใช้เวลา 10 ชั่วโมงและพนักงาน 6-7 คน ค่าใช้จ่ายดังกล่าวบังคับให้เราจัดส่งสินค้าให้น้อยที่สุดเท่าที่จะเป็นไปได้ หลังจากดำเนินการมาสามปี เราก็ทนไม่ไหวและตัดสินใจเติมสีสันให้โปรเจ็กต์นี้ด้วย DevOps เพียงเล็กน้อย
ตอนนี้การทดสอบทั้งหมดจะใช้เวลา 3 ชั่วโมง และมีผู้เข้าร่วม 3 คน: วิศวกร XNUMX คนและผู้ทดสอบ XNUMX คน การปรับปรุงจะแสดงเป็นตัวเลขอย่างชัดเจน และนำไปสู่การลด TTM อันเป็นที่รักอย่างมาก จากประสบการณ์ของเรา มีลูกค้าจำนวนมากที่สามารถได้รับประโยชน์จาก DevOps มากกว่าผู้ที่รู้เรื่องนี้ด้วยซ้ำ ดังนั้น เพื่อให้ DevOps ใกล้ชิดกับผู้คนมากขึ้น เราได้พัฒนา Constructor ที่เรียบง่าย ซึ่งเราจะพูดถึงรายละเอียดเพิ่มเติมในโพสต์นี้
ตอนนี้เรามาบอกคุณในรายละเอียดเพิ่มเติม บริษัทพลังงานแห่งหนึ่งกำลังติดตั้งระบบการจัดการเอกสารทางเทคนิคในโรงงานขนาดใหญ่ 10 แห่ง ไม่ใช่เรื่องง่ายที่จะดำเนินโครงการในระดับนี้โดยไม่มี DevOps เนื่องจากแรงงานที่ใช้แรงงานจำนวนมากทำให้งานล่าช้าอย่างมาก และยังลดคุณภาพด้วย งานที่ใช้แรงงานคนทั้งหมดเต็มไปด้วยข้อผิดพลาด ในทางกลับกัน มีโครงการที่มีการติดตั้งเพียงครั้งเดียว แต่ทุกอย่างจำเป็นต้องทำงานโดยอัตโนมัติ ต่อเนื่อง และไม่มีข้อผิดพลาด - ตัวอย่างเช่น ระบบการไหลของเอกสารแบบเดียวกันในองค์กรขนาดใหญ่ที่มีเสาหินขนาดใหญ่ มิฉะนั้นจะมีบางคนทำการตั้งค่าด้วยตนเอง โดยลืมคำแนะนำในการปรับใช้ และผลที่ตามมาก็คือ การตั้งค่าจะหายไปและทุกอย่างจะพังลงในการใช้งานจริง
โดยปกติแล้วเราจะทำงานร่วมกับลูกค้าผ่านสัญญา และในกรณีนี้ความสนใจของเราแตกต่างออกไปเล็กน้อย ลูกค้าพิจารณาโครงการอย่างเคร่งครัดภายในงบประมาณและข้อกำหนดทางเทคนิค อาจเป็นเรื่องยากที่จะอธิบายให้เขาทราบถึงประโยชน์ของแนวทางปฏิบัติ DevOps ต่างๆ ที่ไม่รวมอยู่ในข้อกำหนดทางเทคนิค จะเป็นอย่างไรหากเขาสนใจที่จะเผยแพร่อย่างรวดเร็วโดยเพิ่มมูลค่าทางธุรกิจ หรือสร้างไปป์ไลน์อัตโนมัติ
อนิจจาเมื่อทำงานกับต้นทุนที่ได้รับการอนุมัติล่วงหน้า จะไม่พบดอกเบี้ยนี้เสมอไป ในทางปฏิบัติของเรา มีกรณีที่เราต้องคำนึงถึงการพัฒนาผู้รับเหมาที่ไร้หลักจริยธรรมและประมาทเลินเล่อ มันแย่มาก: ไม่มีซอร์สโค้ดที่ทันสมัย ฐานโค้ดของระบบเดียวกันแตกต่างกันในการติดตั้งที่แตกต่างกัน เอกสารขาดหายไปบางส่วน และบางส่วนมีคุณภาพแย่มาก แน่นอนว่าลูกค้าไม่สามารถควบคุมซอร์สโค้ด การประกอบ การเผยแพร่ ฯลฯ
จนถึงตอนนี้ ไม่ใช่ทุกคนที่รู้เกี่ยวกับ DevOps แต่ทันทีที่เราพูดถึงข้อดีของมัน เกี่ยวกับการประหยัดทรัพยากรอย่างแท้จริง ลูกค้าทุกคนก็จับตามอง ดังนั้นจำนวนคำขอที่มี DevOps จึงเพิ่มขึ้นเมื่อเวลาผ่านไป ที่นี่ เพื่อที่จะพูดภาษาเดียวกันกับลูกค้าได้อย่างง่ายดาย เราจำเป็นต้องเชื่อมโยงปัญหาทางธุรกิจและแนวปฏิบัติ DevOps อย่างรวดเร็วซึ่งจะช่วยสร้างขั้นตอนการพัฒนาที่เหมาะสม
ดังนั้นเราจึงมีปัญหาในด้านหนึ่ง เรามีความรู้ DevOps แนวปฏิบัติ และเครื่องมือในอีกด้านหนึ่ง ทำไมไม่แบ่งปันประสบการณ์กับทุกคน?
การสร้างตัวสร้าง DevOps
Agile มีแถลงการณ์ของตัวเอง ITIL มีวิธีการของตัวเอง DevOps โชคดีน้อยกว่า - ยังไม่ได้รับเทมเพลตและมาตรฐาน แม้ว่า กำหนดวุฒิภาวะของบริษัทโดยพิจารณาจากการประเมินการพัฒนาและแนวปฏิบัติในการปฏิบัติงาน
โชคดีที่บริษัท Gartner ชื่อดังในปี 2014 และวิเคราะห์หลักปฏิบัติ DevOps และความสัมพันธ์ระหว่างสิ่งเหล่านั้น ด้วยเหตุนี้ ฉันจึงเผยแพร่อินโฟกราฟิก:
เราเอามันเป็นพื้นฐานของเรา . แต่ละพื้นที่จากสี่ด้านมีชุดเครื่องมือ - เรารวบรวมไว้ในฐานข้อมูล ระบุส่วนที่ได้รับความนิยมมากที่สุด ระบุจุดบูรณาการ และกลไกการปรับให้เหมาะสมที่เหมาะสม โดยรวมแล้วปรากฎว่า 36 แนวทางปฏิบัติและ 115 เครื่องมือหนึ่งในสี่เป็นโอเพ่นซอร์สหรือซอฟต์แวร์เสรี ต่อไป เราจะพูดถึงสิ่งที่เราประสบความสำเร็จในแต่ละด้าน และเป็นตัวอย่างเกี่ยวกับวิธีการนำไปใช้ในโครงการเพื่อสร้างการจัดการเอกสารทางเทคนิค ซึ่งเราเริ่มต้นโพสต์นี้
กระบวนการต่างๆ
ในโครงการ EDMS ที่โด่งดัง ระบบการจัดการเอกสารทางเทคนิคถูกปรับใช้ตามรูปแบบเดียวกันในแต่ละออบเจ็กต์ 10 รายการ การติดตั้งประกอบด้วยเซิร์ฟเวอร์ 4 ตัว ได้แก่ เซิร์ฟเวอร์ฐานข้อมูล แอปพลิเคชันเซิร์ฟเวอร์ การทำดัชนีข้อความแบบเต็ม และการจัดการเนื้อหา ในการติดตั้ง อุปกรณ์เหล่านี้ทำงานภายในโหนดเดียวและตั้งอยู่ในศูนย์ข้อมูลที่ศูนย์ข้อมูล ออบเจ็กต์ทั้งหมดมีความแตกต่างกันเล็กน้อยในโครงสร้างพื้นฐาน แต่สิ่งนี้ไม่รบกวนการโต้ตอบทั่วโลก
อันดับแรก ตามแนวทางปฏิบัติของ DevOps เราทำโครงสร้างพื้นฐานอัตโนมัติภายในเครื่อง จากนั้นจึงนำการส่งมอบไปยังวงจรทดสอบ และจากนั้นจึงส่งไปยังผลิตภัณฑ์ของลูกค้า แต่ละกระบวนการได้รับการดำเนินการทีละขั้นตอน การตั้งค่าสภาพแวดล้อมได้รับการแก้ไขในระบบซอร์สโค้ด โดยคำนึงถึงชุดการแจกจ่ายที่ได้รับการคอมไพล์สำหรับการอัพเดตอัตโนมัติ ในกรณีที่มีการเปลี่ยนแปลงการกำหนดค่า วิศวกรต้องทำการเปลี่ยนแปลงระบบควบคุมเวอร์ชันอย่างเหมาะสม จากนั้นการอัปเดตอัตโนมัติจะเกิดขึ้นโดยไม่มีปัญหา
ด้วยวิธีนี้ กระบวนการทดสอบจึงง่ายขึ้นมาก ก่อนหน้านี้ โปรเจ็กต์นี้มีผู้ทดสอบที่ไม่ได้ทำอะไรเลยนอกจากอัปเดตสแตนด์ด้วยตนเอง ตอนนี้พวกเขาเพิ่งมาเห็นว่าทุกอย่างทำงานได้ดีและทำสิ่งที่มีประโยชน์มากขึ้น การอัปเดตแต่ละครั้งได้รับการทดสอบโดยอัตโนมัติ ตั้งแต่ระดับพื้นผิวไปจนถึงระบบอัตโนมัติของสถานการณ์ทางธุรกิจ ผลลัพธ์จะถูกโพสต์เป็นรายงานแยกต่างหากใน TestRail
Культура
การทดลองอย่างต่อเนื่องจะอธิบายได้ดีที่สุดโดยใช้ตัวอย่างการออกแบบการทดสอบ การทดสอบระบบที่ยังไม่มีถือเป็นงานสร้างสรรค์ เมื่อเขียนแผนการทดสอบคุณต้องเข้าใจว่าจะทดสอบอย่างไรให้ถูกต้องและต้องปฏิบัติตามสาขาใด และยังหาสมดุลระหว่างเวลาและงบประมาณเพื่อกำหนดจำนวนเช็คที่เหมาะสมที่สุด สิ่งสำคัญคือต้องเลือกการทดสอบที่จำเป็น คิดว่าผู้ใช้จะโต้ตอบกับระบบอย่างไร โดยคำนึงถึงสภาพแวดล้อมและปัจจัยภายนอกที่เป็นไปได้ เป็นไปไม่ได้หากปราศจากการทดลองอย่างต่อเนื่อง
ตอนนี้เกี่ยวกับวัฒนธรรมของการมีปฏิสัมพันธ์ ก่อนหน้านี้มีสองฝ่ายที่ขัดแย้งกัน - วิศวกรและนักพัฒนา นักพัฒนากล่าวว่า: “เราไม่สนใจว่าจะเปิดตัวอย่างไร คุณเป็นวิศวกร คุณฉลาด ตรวจสอบให้แน่ใจว่าการทำงานไม่มีข้อผิดพลาด". วิศวกรตอบว่า: “นักพัฒนาของคุณประมาทเกินไป โปรดใช้ความระมัดระวังให้มากขึ้น แล้วเราจะเล่นเพลงที่คุณเผยแพร่ให้น้อยลง เพราะทุกครั้งที่คุณให้รหัสรั่วไหล มันไม่ชัดเจนสำหรับเราว่าจะโต้ตอบอย่างไร”. นี่เป็นปัญหาปฏิสัมพันธ์ทางวัฒนธรรมที่มีโครงสร้างแตกต่างจากมุมมองของ DevOps ที่นี่ ทั้งวิศวกรและนักพัฒนาเป็นส่วนหนึ่งของทีมเดียวที่มุ่งเน้นการเปลี่ยนแปลงอยู่ตลอดเวลา แต่ในขณะเดียวกันก็ซอฟต์แวร์ที่เชื่อถือได้
ภายในทีมเดียวกันผู้เชี่ยวชาญมุ่งมั่นที่จะช่วยเหลือซึ่งกันและกัน เหมือนเมื่อก่อน? ตัวอย่างเช่น มีการเตรียมคำแนะนำการใช้งานแบบหนาๆ ไว้ประมาณ 50 หน้า วิศวกรอ่านแล้วไม่เข้าใจอะไรบางอย่าง สาปแช่ง และขอให้นักพัฒนาตอนบ่ายสามโมงแสดงความคิดเห็น นักพัฒนาแสดงความคิดเห็นและสาปแช่ง - ท้ายที่สุดไม่มีใครมีความสุข นอกจากนี้ ยังมีข้อผิดพลาดอยู่บ้าง เนื่องจากคุณจำคำแนะนำทั้งหมดไม่ได้ และตอนนี้วิศวกรพร้อมกับนักพัฒนากำลังเขียนสคริปต์สำหรับการปรับใช้โครงสร้างพื้นฐานซอฟต์แวร์แอปพลิเคชันแบบอัตโนมัติ และพวกเขาคุยกันเป็นภาษาเดียวกันในทางปฏิบัติ
คน
ขนาดของทีมขึ้นอยู่กับขอบเขตของการอัพเดต ทีมงานจะถูกคัดเลือกระหว่างการเตรียมการส่งมอบซึ่งรวมถึงผู้ที่สนใจจากทีมงานโครงการทั่วไป จากนั้นจะมีการเขียนแผนอัปเดตร่วมกับผู้ที่รับผิดชอบในแต่ละขั้นตอน และทีมจะรายงานความคืบหน้า สมาชิกในทีมทุกคนสามารถใช้แทนกันได้ ในฐานะส่วนหนึ่งของทีม เรามีนักพัฒนาสำรองด้วย แต่เขาแทบจะไม่ต้องเชื่อมต่อเลย
เทคโนโลยี
ในแผนภาพเทคโนโลยี มีการไฮไลต์บางจุด แต่ด้านล่างมีเทคโนโลยีมากมาย - คุณสามารถตีพิมพ์หนังสือทั้งเล่มพร้อมคำอธิบายได้ ดังนั้นเราจะเน้นสิ่งที่น่าสนใจที่สุด
โครงสร้างพื้นฐานเป็นรหัส
ตอนนี้แนวคิดนี้อาจไม่ทำให้ใครแปลกใจ แต่ก่อนหน้านี้คำอธิบายของโครงสร้างพื้นฐานยังเหลืออีกมากที่ต้องการ สภาพแวดล้อมการทดสอบมีเอกลักษณ์เฉพาะตัว พวกเขาได้รับการดูแลเอาใจใส่ ฝุ่นละอองปลิวหายไป
ปัจจุบันไม่มีใครกลัวที่จะทดลอง มีอิมเมจพื้นฐานของเครื่องเสมือน และมีสถานการณ์จำลองที่พร้อมสำหรับการปรับใช้สภาพแวดล้อม เทมเพลตและสคริปต์ทั้งหมดจะถูกจัดเก็บไว้ในระบบควบคุมเวอร์ชันและได้รับการอัปเดตทันที ก่อนหน้านี้ เมื่อจำเป็นต้องจัดส่งพัสดุไปที่ขาตั้ง ช่องว่างการกำหนดค่าก็ปรากฏขึ้น ตอนนี้คุณเพียงแค่ต้องเพิ่มบรรทัดในซอร์สโค้ด
นอกเหนือจากสคริปต์โครงสร้างพื้นฐานและไปป์ไลน์แล้ว เอกสารประกอบเป็นแนวทางโค้ดยังใช้สำหรับเอกสารประกอบอีกด้วย ด้วยเหตุนี้ จึงเป็นเรื่องง่ายที่จะเชื่อมโยงผู้คนใหม่ๆ เข้ากับโปรเจ็กต์ แนะนำพวกเขาให้รู้จักกับระบบตามฟังก์ชันที่อธิบายไว้ เช่น ในแผนการทดสอบ และยังนำกรณีทดสอบกลับมาใช้ใหม่อีกด้วย
การส่งมอบและการตรวจสอบอย่างต่อเนื่อง
เกี่ยวกับ DevOps เราได้พูดคุยเกี่ยวกับวิธีที่เราเลือกเครื่องมือสำหรับการดำเนินการจัดส่งและการตรวจสอบอย่างต่อเนื่อง บ่อยครั้งไม่จำเป็นต้องเขียนอะไรใหม่ แค่ใช้สคริปต์ที่เขียนไว้ก่อนหน้านี้ สร้างการบูรณาการระหว่างส่วนประกอบต่างๆ อย่างถูกต้อง และสร้างคอนโซลการจัดการทั่วไปก็เพียงพอแล้ว และกระบวนการทั้งหมดสามารถเปิดใช้งานได้โดยใช้ปุ่มเดียวหรือกำหนดเวลา
ในภาษาอังกฤษมีแนวคิดที่แตกต่างกัน ได้แก่ Continuous Delivery และ Continuous Deployment ทั้งสองสามารถแปลได้ว่า "การจัดส่งอย่างต่อเนื่อง" แต่จริงๆ แล้วมีความแตกต่างกันเล็กน้อย ในโครงการของเราสำหรับการไหลของเอกสารทางเทคนิคของบริษัทพลังงานแบบกระจาย จะใช้การจัดส่งแทน - เมื่อการติดตั้งสำหรับการผลิตเกิดขึ้นตามคำสั่ง ในการปรับใช้ การติดตั้งจะเกิดขึ้นโดยอัตโนมัติ การส่งมอบอย่างต่อเนื่องในโครงการนี้โดยทั่วไปกลายเป็น ส่วนกลางของ DevOps.
โดยทั่วไปแล้ว การรวบรวมพารามิเตอร์บางอย่างจะทำให้คุณเข้าใจได้อย่างชัดเจนว่าเหตุใดแนวทางปฏิบัติ DevOps จึงมีประโยชน์ และถ่ายทอดสิ่งนี้ให้กับผู้บริหารที่รักตัวเลขจริงๆ จำนวนการเปิดตัวทั้งหมด, เวลาดำเนินการของขั้นตอนสคริปต์, ส่วนแบ่งของการเปิดตัวที่ประสบความสำเร็จ - ทั้งหมดนี้ส่งผลโดยตรงต่อเวลาที่ทุกคนชื่นชอบในการออกสู่ตลาด นั่นคือ เวลาตั้งแต่การคอมมิตไปจนถึงระบบควบคุมเวอร์ชันไปจนถึงการเปิดตัวเวอร์ชันบน สภาพแวดล้อมการผลิต ด้วยการใช้เครื่องมือที่จำเป็น วิศวกรจะได้รับตัวบ่งชี้อันมีค่าทางไปรษณีย์ และผู้จัดการโครงการจะเห็นตัวบ่งชี้เหล่านั้นบนแดชบอร์ด วิธีนี้ทำให้คุณสามารถประเมินประโยชน์ของเครื่องมือใหม่ๆ ได้ทันที และคุณสามารถลองใช้มันบนโครงสร้างพื้นฐานของคุณได้โดยใช้ตัวออกแบบ DevOps
ใครจะต้องการของเรา ?
อย่าเสแสร้ง: ในตอนแรกเขามีประโยชน์สำหรับเรา ดังที่เราได้กล่าวไปแล้ว คุณต้องพูดภาษาเดียวกันกับลูกค้า และด้วยความช่วยเหลือจากนักออกแบบ DevOps เราจึงสามารถร่างพื้นฐานสำหรับการสนทนาดังกล่าวได้อย่างรวดเร็ว ผู้เชี่ยวชาญทางธุรกิจจะสามารถประเมินตนเองว่าต้องการอะไรและพัฒนาได้เร็วยิ่งขึ้น เราพยายามทำให้นักออกแบบมีรายละเอียดมากที่สุดเท่าที่จะเป็นไปได้ โดยเพิ่มคำอธิบายมากมายเพื่อให้ผู้ใช้เข้าใจถึงสิ่งที่เขาเลือก
รูปแบบของนักออกแบบช่วยให้คุณคำนึงถึงการพัฒนาที่มีอยู่ของบริษัทในกระบวนการสร้างและระบบอัตโนมัติ ไม่จำเป็นต้องรื้อทุกอย่างแล้วสร้างใหม่หากคุณสามารถเลือกได้เฉพาะโซลูชันที่ผสานรวมเข้ากับกระบวนการที่มีอยู่ได้ดีและสามารถเติมเต็มช่องว่างได้
บางทีการพัฒนาของคุณอาจก้าวไปสู่ระดับที่สูงขึ้นแล้ว และเครื่องมือของเราก็จะดูเหมือนเป็น "กัปตัน" เช่นกัน แต่เราพบว่ามีประโยชน์สำหรับตัวเราเองและหวังว่าจะเป็นประโยชน์กับผู้อ่านบางส่วน เราเตือนคุณ ถึงผู้ออกแบบ - หากมีสิ่งใด คุณจะได้รับไดอะแกรมทันทีหลังจากป้อนข้อมูลเริ่มต้น เราจะขอบคุณสำหรับข้อเสนอแนะและการเพิ่มเติมของคุณ
ที่มา: will.com