เราจะรวมเฉพาะฟีเจอร์ที่พร้อมวางจำหน่ายในการผลิตของเราทุกสัปดาห์ได้อย่างไร

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

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

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

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

ในขณะที่แนวคิด "QA freeze" ประสบความสำเร็จเพียงบางส่วน แต่ก็ยากที่จะประสานงานและผู้คนมักสับสนว่าพวกเขาได้รับอนุญาตให้รวมกับ QA หรือไม่ นอกจากนี้ยังยากที่จะกำหนดเส้นตาย "แช่แข็ง QA" - ทุกคนชอบความคิดของห้องหายใจในระหว่างการแช่แข็งและการเปิดตัว แต่ในทางปฏิบัติพวกเขาต้องการมีคุณลักษณะของพวกเขาในการเปิดตัวต่อไปกว่าเคารพกำหนด

มีวิธีที่ดีกว่าเพื่อให้แน่ใจว่าเรามีงานสร้างที่สะอาดสำหรับการเผยแพร่ของเราทุก ๆ สัปดาห์หรือไม่?

มีปัญหาเล็กน้อยที่เกิดขึ้นในที่นี้ซึ่งทำให้เกิดปัญหาที่คุณกำลังประสบอยู่

ที่แรกก็คือสาขา QA ที่ใช้เวลานาน การมีสาขาที่ใช้เวลานานซึ่งขนานกับการพัฒนาอาจเป็นแหล่งของความสับสนเนื่องจากมีความพยายามที่แตกต่างกันซึ่งจำเป็นต้องทำซ้ำทั้งในสาขา QA และการฉีด หมายความว่าคุณกำลังตรวจสอบการแก้ไขในสาขา QA ที่จำเป็นต้องรวมเข้ากับการฉีดยา (ไม่ใช่เรื่องเลวร้าย) หรือคุณกำลังเช็คอินกับการฉีดที่ได้รับการรวมเข้ากับสาขา QA (แหล่งที่มาของข้อบกพร่องที่เป็นไปได้) .

ปัญหาอื่น ๆ ที่มีสาขายาวขนานกันนั้นเป็นไปได้ที่ไฟล์จะไม่สามารถซิงค์ได้ตลอดเวลา การแก้ไขรหัสที่ไม่เคยได้รับการรวมกลับหรือการกำหนดค่าที่จำเป็นสำหรับการสร้างงานสร้างที่ไม่เคยทดสอบและเป็นส่วนหนึ่งของการพัฒนา

ต่อไปคุณจะได้รับบทบาทที่จะเริ่มขึ้น ซึ่งหมายความว่าบทบาทของบรรจุภัณฑ์ (เพิ่มเติมในภายหลัง) ไม่ได้รับการแยกอย่างเพียงพอ

ในโมเดลgit-flowสาขาที่วางจำหน่ายจะแยกออกจากการพัฒนา ( ไม่ใช่การพัฒนาที่รวมเข้ากับ QA) และการแก้ไขทั้งหมดจะถูกตรวจสอบในสาขาที่วางจำหน่ายแล้วรวมกลับไปที่สาขาการพัฒนา

ปรัชญาการแตกแขนงบางอย่างสามารถพบได้ในAdvanced SCM Branching Strategies (ฉันถือว่าเป็นการอ่านที่ยอดเยี่ยม) สิ่งนี้จะเน้นไปที่บทบาทที่แต่ละสาขาอาจดำเนินการ สาขาที่วางจำหน่ายมีบทบาทในการบรรจุ

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

• สาขาจากจุดพัฒนาไปยังสาขาที่วางจำหน่าย สาขาที่วางจำหน่ายที่ QA สร้างจากรับสาขาเดียวและไม่มีการรวมจากการพัฒนา
  • หากคุณต้องการลงไปตามถนนด้วยการตั้งชื่อและ hooks ที่สอดคล้องกันเป็นไปได้ที่จะป้องกันไม่ให้มีการรวมเข้าในสาขาที่วางจำหน่าย
• แก้ไขทุกสิ่งที่จำเป็นต้องได้รับการแก้ไขในสาขาปล่อยและรวมการเปลี่ยนแปลงเหล่านั้นกลับไปที่การฉีด
• เมื่อสิ้นสุดความพยายามเผยแพร่ให้รวมสาขาย่อยลงในสาขา "release go here" และติดแท็กดังกล่าว
  • บางไซต์ไม่มีสาขา "รุ่นวางจำหน่ายที่นี่" และเพียงปล่อยให้สิ้นสาขาสายห้อยที่มีแท็ก

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

ปัญหาดูเหมือนว่าสำหรับฉันว่าคุณมีสาขา QA เดียว

สำหรับแต่ละรุ่นให้ทำการแยก QA แยกจาก trunk / master การพัฒนาหลัก จากนั้นผสานในเพียงการแก้ปัญหาสำหรับข้อบกพร่องสำหรับคุณสมบัติในสาขานั้น - คุณสมบัติใหม่ที่ไม่เคย มีการทดสอบ QA สาขานั้น

วิธีนี้ "หยุด" ค่อนข้างชัดเจน - มันอยู่ในชื่อสาขา คุณสามารถใช้บางสิ่งเช่นฉันไม่ได้, release/26/10/2015. เห็นได้ชัดว่าไม่มีใครควรผสานคุณสมบัติใหม่หลังจากนี้

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

ไม่มีสาขา QA ที่ใช้งานมานานเพียงอย่างเดียวนั่นเป็นเพียงการขอให้มีปัญหา แยกจากสาขาการพัฒนาหลักสำหรับแต่ละรุ่นและ QA สาขานั้น

คุณค่อนข้างได้รับการแมปกับโมเดลการแยกสาขาการพัฒนาที่สำคัญด้านล่าง พื้นที่เหนือ MAIN ถูกกล่าวว่าเป็นพื้นที่พัฒนา พื้นที่ด้านล่างหลักคือพื้นที่การผลิต

ไฮไลท์ของรุ่นนี้ซึ่งฉันคิดว่าเกี่ยวข้องกับคุณ:

• ผู้พัฒนาของคุณจำเป็นต้องส่งต่อการรวม (FI) (FI = รวมออกจากหลัก) บ่อยครั้ง (2-3 ครั้งต่อสัปดาห์) ในสาขา DEV ของพวกเขาเพื่อให้แน่ใจว่าการเปลี่ยนแปลงล่าสุดของพวกเขาพิจารณาการพัฒนาโดยรวมล่าสุดเสมอ
• ผู้พัฒนาของคุณจำเป็นต้องย้อนกลับการผสานรวม (RI) (RI = รวมเข้ากับ MAIN) ในสาขาการทดสอบเฉพาะเมื่อพวกเขามาถึงเหตุการณ์สำคัญที่ทำให้เสร็จสมบูรณ์ซึ่งพวกเขาต้องการเปิดเผยต่อ QA และที่พวกเขาพร้อมที่จะแก้ไขปัญหา ตอบสนองต่อข้อเสนอแนะ QA การแก้ไขจะดำเนินการในสาขา TEST และ FI ทันทีในสาขา DEV ของพวกเขา
• ไม่เคย RI จากสาขา DEV ใด ๆ เข้าสู่ MAIN
• RI เสมอจากสาขา TEST เป็น MAIN โดยเฉพาะเมื่อ QA ของคุณพิจารณาคุณภาพของการทดสอบว่าตกลง รักษาเกณฑ์คุณภาพสูงไว้สำหรับการรวมเข้ากับ MAIN อย่างน้อยที่สุดผู้จัดการผลิตภัณฑ์ของคุณจะต้องสามารถสาธิตเวอร์ชันการทำงานของผลิตภัณฑ์ของคุณจากการกระทำล่าสุดใน MAIN
• สร้างสาขาในพื้นที่การผลิตตามต้องการเท่านั้น เซิร์ฟเวอร์การสร้างของคุณควรติดแท็กสาขาทั้งหมดรวมถึงจากพื้นที่พัฒนาและแหล่งที่มาของการสร้าง / วางจำหน่ายใด ๆ ที่สามารถระบุได้ตลอดเวลาโดยไม่คำนึงถึงสาขาที่มาจาก
• รับการเผยแพร่เพื่อการผลิตจาก MAIN หรือพื้นที่การผลิตเท่านั้น หากภายหลังคุณต้องระบุการแก้ไขสำหรับรุ่นที่วางจำหน่ายที่แน่นอน (เช่นคุณไม่สามารถให้รุ่นล่าสุดจาก MAIN ได้) ให้สร้างสาขาในพื้นที่การผลิตจากแท็ก MAIN ของการปล่อยความผิดพลาดเมื่อต้องการการแก้ไข แก้ไขปัญหาในสาขา HotFix เสมอจากนั้น RI เป็น MAIN และ FI ไปยัง TEST ทันที

ฉันสงสัยว่าคุณมีปัญหาเพราะ:

• devs RI ของคุณเป็นรหัสการทดสอบที่ยังไม่เสร็จสมบูรณ์
• devs RI ของคุณเป็น TEST โดยไม่ได้รับแสงสีเขียวจาก QA (เช่น QA ไม่ได้อยู่ในการควบคุมของสิ่งที่ถูกฉีดเข้าสู่ TEST)
• เมื่อ QA รายงานข้อบกพร่องเกี่ยวกับการทดสอบ dev ของคุณจะแก้ไขมันในสาขา DEV ของพวกเขาและจากนั้น RI เป็น TEST นี่คือการปฏิบัติที่ไม่ดีที่สำคัญเนื่องจากการผสานจะนำอึ dev ที่ไม่สมบูรณ์อื่น ๆ เสมอ พวกเขาควรแก้ไขใน TEST และ FI ในสาขา DEV เสมอ หากไม่สามารถแก้ไขได้ใน TEST พวกเขาจะส่งอึทั้งหมดตั้งแต่แรกและคุณมีปัญหาใหญ่กว่า
• ผู้พัฒนาของคุณไม่ได้รับ FI เพียงพอจากการทดสอบดังนั้นพวกเขาจึงไม่ทำให้การทดสอบเสถียรเมื่อใดก็ตามที่พวกเขาส่งมอบที่นั่น มันเป็นศิลปะการปรับความสมดุลของความถี่ในการ FI เข้าสู่ DEV เลื่อนมันมากเกินไปและจะมีค่าใช้จ่ายสูง & เสี่ยงมากก่อนส่งมอบซึ่งคุณไม่ต้องการ ทำบ่อยเกินไปและคุณจะไม่ได้รับงานพัฒนาจริงใด ๆ หากคุณซ้อนทับมากเกินไปกับงานที่คนอื่นส่งมาใน TEST ในเวลาเฉลี่ย

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

ไม่ว่าคุณจะใช้รูปแบบการแยกสาขาแบบใดของ SCM ฉันขอแนะนำให้คุณลองทำอย่างใดอย่างหนึ่งหรือทั้งสองอย่างต่อไปนี้:

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

ทางออกที่ง่ายมากอย่างหนึ่งที่ฉันเห็นว่าทำงานกับทีมใหญ่กว่าของคุณเล็กน้อยคือให้ทุกคนทำงานและปรับใช้จากสาขาเดียว

คุณบอกว่าทีมนั้นคล่องแคล่ว แต่ไม่ชัดเจนว่าคุณกำลังทำงานในการวิ่ง (เช่นการต่อสู้) หรือการไหลต่อเนื่องมากกว่า (เช่น Kanban) สมมติว่าคุณกำลังทำ sprints เป้าหมายสำหรับทีมคือการให้รหัส releasable ในตอนท้ายของแต่ละ sprint สำหรับการปล่อยรายปักษ์ของคุณ ไม่มีความสับสนว่าคุณลักษณะหนึ่งจะทำลายอีกอย่างหนึ่งได้หรือไม่เนื่องจากได้รับการพัฒนาร่วมกัน ผู้ทดสอบอาจสามารถเข้าถึงฟีเจอร์ที่มีขนาดเล็กลงเนื่องจากค่าใช้จ่ายของผู้พัฒนาเพื่อส่งมอบให้พวกเขานั้นต่ำกว่า และคุณไม่จำเป็นต้องมี QA-Freeze แทนทุกคนรู้ว่าเมื่อสิ้นสุดการวิ่งและไม่ควรทำงานพวกเขาไม่สามารถเสร็จหรือปล่อยให้อยู่ในสถานะใช้งานได้ (เช่นปิดใช้งาน)

เห็นได้ชัดว่ามีข้อดีข้อเสียกับวิธีการใด ๆ ฉันนำเสนอนี้เป็นตัวเลือกที่ไม่จำเป็นต้องเป็น 'วิธีที่ดีที่สุด'

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

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

ดังนั้นวิธีนี้ได้รับการออกแบบมาเพื่อปกป้องสาขา QA จากฟีเจอร์การพัฒนาที่เสียหาย - ไม่ว่าจะเป็นเพราะฟีเจอร์นั้นไม่ได้รับการเข้ารหัสดีพอหรือมีปัญหาการรวมที่ไม่คาดคิดไม่สำคัญ เฉพาะสาขา dev ที่ผ่านการทดสอบการรวมจะได้รับการเลื่อนระดับเป็น QA