เมื่อพูดถึงการส่งมอบการต่อสู้ ผู้คนมักจะคาดหวังให้ดำเนินการปล่อยหลังจากสิ้นสุดการวิ่ง ซึ่งหมายถึงโดยตรงหลังจากการนำเสนอการสาธิตแก่ลูกค้าสำเร็จ
แต่ฉันสงสัยเสมอว่าสิ่งนี้จะเป็นความคาดหวังโดยอัตโนมัติได้อย่างไร โดยเฉพาะอย่างยิ่งหากคุณพิจารณากิจกรรมที่เป็นไปได้ด้านล่างที่ต้องเกิดขึ้นก่อนหรือหลัง
- พัฒนาและเติมเต็มเรื่องราวทั้งหมดภายในการวิ่ง บางเรื่องอาจเสร็จสิ้นเร็วกว่านั้น แต่ส่วนใหญ่แล้ว เรื่องราวจะเสร็จสิ้นก่อนสิ้นสุดการวิ่ง อาจจะเปิดหลังจากการนำเสนอตัวอย่างแล้วที่นี่
- ทำการทดสอบตามกำหนดเวลาทั้งหมดบนเนื้อหา sprint เพื่อให้แน่ใจว่ารหัสที่จะเผยแพร่นั้นพร้อมสำหรับการผลิต
- ติดตามข้อบกพร่องที่ค้นพบและแก้ไขได้ทันเวลาก่อนที่จะเผยแพร่
- ตรวจสอบให้แน่ใจว่าไปป์ไลน์การปรับใช้ได้รับการอัปเดตด้วยเนื้อหาล่าสุด และไปป์ไลน์นั้นเชื่อถือได้ในการดำเนินการ
- เรียกใช้ไปป์ไลน์ในสภาพแวดล้อมที่เกี่ยวข้องทั้งหมดเพื่อให้เข้าสู่สถานะล่าสุดจากโค้ดและเปอร์สเปคทีฟข้อมูล
- เตรียมบันทึกประจำรุ่นและสื่อสารกับลูกค้าถึงผลกระทบของรุ่นและสิ่งที่จะเปลี่ยนแปลงในภายหลัง
- หากเกี่ยวข้อง ให้ซิงโครไนซ์กับทีมต่อสู้แบบคู่ขนานอื่นๆ เพื่อให้แน่ใจว่าเนื้อหาที่เกี่ยวข้องจะได้รับการเผยแพร่พร้อมกัน ไม่มีอะไรขาดหายไปเพื่อให้แน่ใจว่าเนื้อหาที่เผยแพร่ของคุณจะทำงานตามที่คาดไว้
- เหนือสิ่งอื่นใด ต้องผ่านพิธีการต่อสู้ทั้งหมด ไม่เพียงแต่เกี่ยวข้องกับการวิ่งปัจจุบันเท่านั้น แต่ยังรวมถึงเป้าหมายสำหรับการวิ่งครั้งต่อไปด้วย (เช่น เซสชันการปรับแต่งเรื่องราว)
ตอนนี้ลองนึกภาพการวิ่งมีสองสัปดาห์
ปล่อยกิจกรรมด้วยตัวเองต้องใช้เวลาและคนในการดำเนินการ แต่ใช้เวลามากเกินไปไม่ได้ หลังจากวันสุดท้ายของการวิ่งมาถึงวันแรกของการวิ่งครั้งต่อไป และวงกลมจะเริ่มใหม่อีกครั้ง
ความคาดหวังในการออกตัวหลังจากการวิ่งแต่ละครั้งยังดูอัตโนมัติอยู่ไหม?
ปล่อยการประมวลผลเนื้อหา
หากกระบวนการทั้งหมดภายในสปรินต์เป็นแบบอัตโนมัติ มีความเป็นไปได้ที่จะ “ดึงทริกเกอร์” และติดตั้งรหัสเวอร์ชันล่าสุดในการผลิตเมื่อสิ้นสุดแต่ละสปรินต์ ปัญหาคือฉันไม่เคยมีประสบการณ์ในทีมการต่อสู้ที่สมบูรณ์แบบเช่นนี้มาก่อน
หากเป็นกรณีนี้ในธุรกิจส่วนตัวขนาดเล็กบางแห่ง ฉันอิจฉาพวกเขาจริงๆ แต่ความเป็นจริงในโลกธุรกิจก็คือทีมต่อสู้จะไม่บรรลุวุฒิภาวะในระดับนั้น ในทางตรงกันข้าม กระบวนการรีลีสมักจะเชื่อมโยงกับกิจกรรมที่ใช้เวลานานซึ่งเข้าถึงสปรินต์ส่วนใหญ่ต่อไปนี้ ซึ่งส่งผลต่อสปรินต์นั้นจากเนื้อหาและมุมมองเมตริกทั้งหมด การปล่อยตัวเป็นเพียงการกระทำที่ตึงเครียดซึ่งไม่มีใครในทีมพอใจที่จะผ่านมันไป
ดังนั้นฉันจึงได้ค้นพบสถานการณ์ที่ดีที่สุดลำดับถัดไปสำหรับการจัดการกับการเผยแพร่
ข้อสรุปคือให้ทุกวินาทีวิ่งเป็น Release Sprint นี่คือความหมาย
เวอร์ชันโค้ดแยกต่างหากสำหรับรีลีสถัดไป
นี่เป็นเรื่องเกี่ยวกับการจัดการสาขาแยกต่างหากในที่เก็บ GIT มีหลายวิธีในการแก้ปัญหาเดียวกันและทุกวิธีสามารถประสบความสำเร็จได้ แต่สำหรับจุดประสงค์ของบทความนี้ ฉันจะทำสิ่งต่างๆ ให้เรียบง่ายเพื่อแสดงให้เห็นถึงแนวทางและผลกระทบของมัน
เพื่อให้ส่งผลกระทบต่อกิจกรรมการพัฒนาที่กำลังดำเนินอยู่ให้น้อยที่สุด สิ่งสำคัญคือต้องแยกเนื้อหาสำหรับรุ่นถัดไปออกเป็นสาขาแยกต่างหาก เรียกมันว่า Release Branch ด้วยวิธีนี้ ต่อไปนี้จะได้รับการแก้ไข:
- ทีมพัฒนาสามารถทำกิจกรรมต่อไปและรวมเข้ากับเรื่องราวใหม่ของสาขาหลักได้โดยไม่หยุดชะงัก
- ไม่มีความเสี่ยงที่เนื้อหาของการเปิดตัวจะได้รับผลกระทบจากการแก้ไขโค้ดที่ไม่คาดคิดจากทีมการต่อสู้
- กิจกรรมการทดสอบสามารถดำเนินการในพื้นที่แยกได้ ที่นี่ จะแนะนำเฉพาะการเปลี่ยนแปลงที่จำเป็นสำหรับการแก้ไขการทดสอบเท่านั้น
- เนื่องจากขั้นตอนการเผยแพร่จะนำไปใช้ในการผลิตเฉพาะเนื้อหาจาก Release Branch เราจึงมีกระบวนการที่ชัดเจนและควบคุมเนื้อหาที่จะเผยแพร่ได้อย่างเต็มที่ ไม่สามารถเกิดขึ้นได้ที่การคอมมิตที่ไม่คาดคิดในสาขา Git จะทำให้โค้ดที่ทดสอบแล้วเสียหาย
ดังนั้นเพียงแค่เก็บเนื้อหาของรุ่นถัดไปไว้และปล่อยให้เนื้อหาเข้าสู่สถานะที่เสถียรพร้อมสำหรับการเผยแพร่
กำหนดเวลาเผยแพร่เพื่อให้ทำงานซ้ำๆ
ฉันละทิ้งความทะเยอทะยานที่จะปล่อยตัวหลังจากวิ่งเสร็จทุกครั้ง เห็นได้ชัดว่าสิ่งนี้จะไม่มีโอกาสทำงาน อย่างน้อยก็ไม่มีผลข้างเคียงเช่น:
- ส่งผลกระทบต่อเนื้อหาการพัฒนาการวิ่งครั้งต่อไป
- ไม่สามารถทำให้เนื้อหาที่เผยแพร่มีความเสถียร
- ติดตามกิจกรรมการทดสอบที่จำเป็นทั้งหมด ฯลฯ
ดังนั้นเป้าหมายคือดำเนินการปล่อยตัวเมื่อสิ้นสุดการวิ่งทุกๆ วินาที นั่นจะหมายถึงสิ่งต่อไปนี้:
- รีลีสจะมีเรื่องราวจากสองสปรินต์สุดท้ายที่ทำเสร็จแล้วเสมอ เนื่องจากรีลีสดำเนินการภายในปัจจุบัน (แอคทีฟสปรินต์) เนื้อหาสปรินต์นี้จึงยังไม่รวมอยู่ในรีลีส
- มีเวลาวิ่งในครั้งเดียวสำหรับกิจกรรมการทดสอบที่จำเป็นและการแก้ไขจุดบกพร่องให้เสร็จสิ้น
- เจ้าของรีลีสมีเวลามากพอที่จะรวบรวมข้อมูลที่เกี่ยวข้องกับรีลีส (กรณีทดสอบ บันทึกรีลีส ฯลฯ) ด้วยการวิ่งแบบไม่รีลีส ด้วยวิธีนี้ พวกเขาสามารถทำงานแบบสแตนด์อโลนได้โดยทั่วไป และทำให้ทีมพัฒนาที่เหลือสามารถทำงานเกี่ยวกับเรื่องราวใหม่ๆ ได้
- ในกรณีที่พบจุดบกพร่อง เจ้าของ Release สามารถเชื่อมต่อกับผู้พัฒนาที่เป็นรูปธรรมได้อย่างรวดเร็วเพื่อแก้ไขปัญหาและกลับไปยังเนื้อหา Sprint ปัจจุบัน ดังนั้นควรมีการจัดสรรเวลาเป็นเปอร์เซ็นต์จากความสามารถของทีมเพื่อรองรับการแก้ไขจุดบกพร่องนี้ สามารถค้นพบได้มากแค่ไหนเมื่อเวลาผ่านไป
เห็นได้ชัดว่าผู้ใช้จะไม่ได้รับเนื้อหาการวิ่งล่าสุดในรีลีสล่าสุด แต่เมื่อเวลาผ่านไปสิ่งนี้จะไม่เกี่ยวข้อง พวกเขาจะได้รับเนื้อหาสองสปรินต์ในการเผยแพร่ครั้งต่อไปหลังจากแต่ละสปรินต์ที่สอง
ดูเหมือนว่าเป็นการประนีประนอมที่ดีระหว่างความพึงพอใจในการจัดส่งที่รวดเร็วและการติดตามกิจกรรมการต่อสู้โดยไม่มีการรบกวนอย่างมีนัยสำคัญ
ดำเนินการปรับใช้เผยแพร่
เมื่อการทดสอบ การแก้ไขจุดบกพร่อง และกิจกรรมความพร้อมไปป์ไลน์เสร็จสมบูรณ์แล้ว การดำเนินการไปป์ไลน์การผลิตและการนำออกใช้ไปสู่การผลิตให้เสร็จสมบูรณ์นั้นเป็นกระบวนการที่ค่อนข้างตรงไปตรงมา
เนื่องจากมีการปรับใช้จากสาขาแบบสแตนด์อโลน สิ่งนี้จึงเป็นกิจกรรมที่ไม่มีใครสังเกตเห็นและมองไม่เห็น ไม่มีใครจำเป็นต้องรู้ หากเป็นกรณีนี้ การดำเนินการปรับใช้รีลีสที่ดีที่สุดเท่าที่จะเป็นไปได้
ข้อกำหนดเบื้องต้นสำหรับสิ่งนั้นคือการสร้างไปป์ไลน์ DevOps อัตโนมัติที่มั่นคง ไม่เพียงใช้เพื่อปรับใช้กับสภาพแวดล้อมการผลิต แต่ยังรวมถึงสภาพแวดล้อมระดับล่างอื่นๆ ทั้งหมดด้วย ซึ่งอาจรวมถึง dev, sandbox, การทดสอบ, การรับประกันคุณภาพ, สภาพแวดล้อมด้านประสิทธิภาพ ฯลฯ ซึ่งจะเป็นการคลิกเพียงครั้งเดียวเพื่อปรับใช้โซลูชันทั้งหมดสำหรับทุกสภาพแวดล้อมเดียว
การปล่อยวางไม่ควรเป็นความเจ็บปวดหรือความเครียด หรือฝันร้ายที่ทุกคนหวาดกลัวและเตรียมพร้อมสำหรับวันนั้นเป็นเวลาหนึ่งสัปดาห์ ไม่ – หากไม่มีใครสังเกตเห็นเลย นี่เป็นสัญญาณที่ดีที่สุดของการเปิดตัวที่ประสบความสำเร็จ
รวมสาขาที่วางจำหน่ายกลับเข้าไปในสาขาการพัฒนา
ตอนนี้ Release Branch มีเนื้อหาพิเศษบางอย่างที่ไม่มีอยู่ใน Branch การพัฒนาที่กำลังดำเนินอยู่ตามปกติ ซึ่งเกี่ยวข้องกับการแก้ไขทั้งหมดที่ดำเนินการในช่วงทดสอบ เนื้อหานี้จำเป็นต้องรวมกลับเข้าไปในสาขาการพัฒนาเพื่อให้แน่ใจว่าการแก้ไขจะยังคงอยู่แม้หลังจากรุ่นถัดไป
เมื่อถึงจุดนั้น Release Branch ล่าสุดจะทำหน้าที่เป็นรหัสการผลิตที่พร้อมสำหรับการปรับใช้ในกรณีฉุกเฉิน หากปัญหาเร่งด่วนที่มีลำดับความสำคัญสูงจำเป็นต้องได้รับการแก้ไขหลังการปรับใช้จริงไม่นาน ก็สามารถใช้สาขานี้ได้ มันง่ายที่จะใช้รหัสนี้และใช้การแก้ไขภายใน นี่ยังคงเป็นสำเนาที่ถูกต้องของรหัสการผลิตปัจจุบันโดยไม่มีเนื้อหาใหม่ที่ยังไม่ได้เผยแพร่
สุดท้ายนี้ เมื่อช่วงทดสอบใหม่เริ่มต้นขึ้น สามารถลบสาขารุ่นก่อนหน้าและแทนที่ด้วยสาขาใหม่ได้ ใหม่ถูกสร้างขึ้นอีกครั้งเป็นสำเนาจากสาขาการพัฒนาปัจจุบัน
สร้างการเผยแพร่เป็นประจำ
และตอนนี้เราก็มีแล้ว 😀 ซึ่งเป็นกระบวนการที่มั่นคงสำหรับการเปิดตัว สิ่งเดียวที่ขาดหายไปคือการมุ่งมั่นที่จะทำให้เป็นปกติ ในกรณีนี้ หลังจากวิ่งทุกๆ วินาที
ด้วยการทำให้สม่ำเสมอ เราได้วางรากฐานเพื่อให้บรรลุผลสำเร็จได้ง่ายขึ้น สาเหตุหลักมาจาก:
- หากปล่อยหลังจากนั้นไม่นาน ก็จะไม่มีเนื้อหาใหม่ให้ติดตั้งในเวอร์ชันที่ใช้งานจริงมากนัก เพิ่มขึ้นเล็กน้อยและถือว่าคงที่
- ตอนนี้เนื้อหาใหม่มากมายไม่ได้หมายความถึงกิจกรรมการทดสอบและการสร้างกรณีทดสอบมากนัก ลดการสื่อสาร การเรียกข้อตกลง และการทำงานร่วมกันกับผู้มีส่วนได้ส่วนเสียเกี่ยวกับสิ่งที่ทุกอย่างจำเป็นต้องได้รับการตรวจสอบอีกครั้ง พวกเขาจะเห็นด้วยว่ามันไม่นานนักตั้งแต่การเปิดตัวครั้งล่าสุด จึงให้ความสำคัญน้อยลงในการกระทำนี้
- ทีมจะชินกับวงจรนี้ เมื่อเวลาผ่านไป มันจะเป็นส่วนหนึ่งของทีมโดยธรรมชาติ
- ผลข้างเคียง สภาพแวดล้อมการพัฒนาและการทดสอบมักจะได้รับการรีเฟรชข้อมูล ซึ่งจำเป็นสำหรับรอบการทดสอบใหม่แต่ละรอบ ดังนั้นมันจะไม่เป็นเพียงกิจกรรมตามกำหนดเวลาอื่นที่ต้องทำ แต่เป็นการกระทำที่เป็นส่วนหนึ่งของกระบวนการที่กำหนดไว้แล้ว การเปลี่ยนแปลงมุมมองนี้มีอิทธิพลอย่างมากต่อบรรยากาศของทีม ใครจะไม่เชื่ออย่างนั้น
บทสรุป
บทนี้สรุปโพสต์ก่อนหน้าของฉันเกี่ยวกับหัวข้อของวงจรชีวิตการต่อสู้ นอกจากนี้ยังเกี่ยวกับสิ่งที่พิสูจน์แล้วว่าได้ผลในชีวิตจริง
บ่อยครั้งที่ทีมเริ่มต้นด้วยวิธีที่คล่องตัวและทำหลายสิ่งหลายอย่างผิดพลาด จากนั้นพวกเขาก็พัฒนาในที่สุดและเริ่มทำสิ่งต่าง ๆ ชุดข้อมูลนี้อาจช่วยให้บางคนทำการเปลี่ยนแปลงนี้ได้เร็วขึ้น
แนวทางการเผยแพร่นี้ไม่ใช่วิธีเดียวที่ใช้การได้ และไม่ใช่ว่าจะไม่มีปัญหา สิ่งเหล่านั้นจะยังคงอยู่และทีมต้องจัดการกับพวกเขา จากนั้นปรับปรุงสิ่งที่เป็นไปได้และลืมสิ่งที่ไม่มีเหตุผล
แต่จากสิ่งที่ฉันรู้ วิธีการนี้แม้จะเป็นวิธีที่ง่าย แต่ก็พิสูจน์ได้ว่าการเปลี่ยนแปลงนั้นเป็นไปได้ ตั้งแต่การวิ่งที่วุ่นวายและคาดเดาไม่ได้ไปจนถึงการส่งมอบที่เสถียรยิ่งขึ้นด้วยการเผยแพร่เป็นประจำที่ใคร ๆ ก็วางใจและวางแผนได้ และไม่จำเป็นต้องมีระเบียบวิธีพิเศษที่ซับซ้อนมาก เพียงแค่มีกฎง่ายๆ และเต็มใจที่จะทำตามแผน
