การเลือกกลยุทธ์การแยกสาขาที่เหมาะสมสำหรับการเผยแพร่

เริ่มต้นด้วยทีม dev ใหม่ในโครงการใหม่และเราต้องกำหนดกลยุทธ์การแบ่งสาขาสำหรับแหล่งเก็บข้อมูลของเรา ( เช่น Microsoft Team Foundation Server 2010 ) เราได้ทำการอภิปรายกันอย่างเหนียวแน่นว่าจะ ...

ก . มีสาขาReleaseหนึ่งสาขาที่เราผลิตงานสร้างและจากนั้นLabelเมื่อมีบางอย่างออกวางจำหน่ายจริง

หรือ

ข . มีสาขาReleaseใหม่สำหรับแต่ละ Release ใหม่เข้าสู่การผลิต ( เช่นเวอร์ชัน 1, 2, 3, ฯลฯ ... )

ตัวเลือกAดูเหมือนจะตรงไปตรงมา แต่เราไม่แน่ใจว่าสิ่งนี้จะนำไปสู่ปัญหาในระยะยาวหรือไม่ ตัวเลือกBดูเหมือนว่าจะเป็นเพียงการสร้างกิ่งไม้ที่มีอายุยืนยาวจำนวนมากเพียงครั้งเดียว

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

ตัวเลือก A. เพียงแค่ใช้การฉีดและการติดแท็กสำหรับการเปิดตัว

ข้อดี:

• คุณหลีกเลี่ยงการรวมนรก
• การรักษาหลักแหลมนั้นเป็นการส่งเสริมแนวทางปฏิบัติที่ดีที่สุดเช่นการวางแผนการปล่อยอย่างเหมาะสมไม่แนะนำ WIP มาก ๆ โดยใช้การแยกสาขาโดยใช้นามธรรมเพื่อจัดการกับงานระยะยาวนอกวงและใช้ระบบปิดแบบเปิดและคุณสมบัติที่กำหนดค่าได้สำหรับจัดการงาน กำลังดำเนินการซึ่งอาจ; หรืออาจไม่; จำเป็นต้องปิดการใช้งานในขณะนี้หรือในอนาคตเพื่อที่จะปล่อยหรือหลีกเลี่ยงการย้อนกลับแบบเต็ม

จุดด้อย:

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

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

เมื่อคุณไม่ทำเช่นนี้คุณจะเริ่มพบว่าตัวเองกำลังจัดการกับปัญหาการรวมรหัสค้างคุณลักษณะที่ไม่เคยได้รับการเผยแพร่ ฯลฯ

ตัวเลือก B. สาขาตามรุ่น

ข้อดี:

• คุณสามารถเริ่มทำงานในการทำซ้ำครั้งถัดไปในขณะที่การทำซ้ำปัจจุบันเสร็จสิ้นการทดสอบการยอมรับรอบ
• สิ่งอื่น ๆ ที่ฉันแน่ใจ

จุดด้อย:

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

ฉันไม่ใช่แฟนตัวยงของการแก้ปัญหานี้ ^ _ ^

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

เป็นการดีที่ฉันคิดว่าคุณต้องการให้มันเป็นกระบวนการยกเว้นไม่ใช่กฎ

ตัวเลือก C. ตัวเลือกโบนัสบ้า

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

ในอดีตที่ผ่านมาฉันดำเนินการด้านล่างสำหรับทีมบำรุงรักษานายจ้างก่อนหน้านี้ซึ่งทำงานกับฐานรหัสดั้งเดิมที่ไม่สามารถนำไปใช้กับ Mercurial จาก svn ได้อย่างง่ายดาย งานที่ไม่จำเป็นจำนวนมากเกี่ยวข้องกับการตอบสนองความต้องการทางธุรกิจของการฉีดยาที่เป็นไปได้เสมอมากกว่าการประสานงานการปล่อยที่ดีกว่า . .

1. คุณสมบัติได้รับการพัฒนาโดย devs ในสาขา dev ทีมของพวกเขา
2. เมื่อสถานที่พร้อมที่จะให้เพื่อนตรวจสอบ devs จะรวมเข้าด้วยกันในการผสานเดียวจากสาขา Dev ไปยังสาขา CR และรวมถึงคุณสมบัติ id / เรื่องราวของผู้ใช้ในชื่อเรื่อง * บังคับใช้โดยการส่งฮุคล่วงหน้า *
3. หลังจากผ่าน CR เครื่องมือการดูแลระบบจะใช้ในการโปรโมตคุณลักษณะลงในสาขา QA (ฉันเขียนแอปพลิเคชันเทอร์มินัลเล็ก ๆ ที่ระบุเรื่องราวของผู้ใช้ที่มีอยู่ในขั้นตอนการยอมรับต่าง ๆ และอนุญาตให้ผู้ดำเนินการส่งเสริมหรือลดระดับระหว่างขั้นตอนการยอมรับเหล่านั้น)
4. QA ดำเนินการทดสอบระบบอัตโนมัติและใช้งานด้วยตนเอง หากคุณสมบัติดีผลักเข้าไปในสาขาการปล่อย (ฉีด) หากคุณสมบัตินั้นถูกปฏิเสธถูกลดระดับ / เปลี่ยนเป็นสาขา QA จนกว่า devs จะสามารถแก้ไขปัญหาที่เกิดขึ้นระหว่างการทดสอบและเพิ่มส่งแพตช์ไปยังสาขา CR
5. หากรหัสถูกเปลี่ยนกลับจากสาขา QA และการแก้ไขถูกนำไปใช้เครื่องมือเทอร์มินัลจะนำการเปลี่ยนแปลงที่จำเป็นไปใช้เพื่อนำคุณลักษณะนี้กลับไปยังสาขา QA จากสาขา CR เพื่อให้ QA อาจทบทวนรหัสและเลื่อนขั้นหรือ ลดระดับอีกครั้ง
6. ณ เวลาใดก็ตามสาขาที่วางจำหน่ายควรอยู่ในสถานะ releasable ที่เสถียร
7. หลังจากปล่อย Dev, QA และ CR ใหม่ออกมาจากการฉีด

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

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

นอกจากนี้ยังทำให้การเปรียบเทียบการวางจำหน่ายนั้นง่ายขึ้นมากเมื่อคุณค้นหาเมื่อมีข้อผิดพลาดหรือคุณลักษณะถูกนำมาใช้

ไม่ต้องกังวลกับจำนวนสาขาหรือเวลาที่ไปโดยไม่มีการเปลี่ยนแปลง ระบบการกำหนดเวอร์ชันของคุณคือให้การควบคุมและจัดทำประวัติของการพัฒนาโครงการของคุณ ประวัติศาสตร์มีแนวโน้มที่จะไม่เปลี่ยนแปลง ... และไม่ต้องกังวลกับ CV ของคุณที่ไม่สามารถรับมือได้ เราใช้ไฟล์ Perforce, 9000+ ไฟล์ในสาขาการพัฒนา, สาขาการพัฒนาสูงสุด 50 สาขาสำหรับการเปิดตัวที่เรากำลังดำเนินการอยู่และตามที่ได้กล่าวไปแล้วสาขาเดียวต่อการเผยแพร่ที่เราเผยแพร่ Perforce ไม่แม้แต่จะหายใจแรงขึ้น

ในระยะสั้น: ทำให้ชีวิตของคุณในฐานะนักพัฒนา / ผู้ดูแล / แก้ไขข้อผิดพลาด / นักล่าปัญหาง่ายขึ้นและไม่ต้องกังวลกับจำนวนสาขาหรือจำนวนไฟล์ cvs ใด ๆ ที่เคารพตนเองจะรับมือ

แก้ไข:

เราไม่ได้สับสนอะไรเลยเกี่ยวกับจำนวนสาขาที่เรามี รูปแบบการตั้งชื่อของเราสำหรับสาขาที่วางจำหน่ายและนโยบายสาขา 1 ฉบับที่ 1 ของเราสำหรับการพัฒนา (หรือที่ทำงาน) สาขาอาจมีสิ่งที่ต้องทำ

สาขาที่วางจำหน่ายมีชื่อสำหรับการเปิดตัวของพวกเขาเช่น: R2011SP1 สำหรับ Release 2011 Service Pack 1 สาขาการทำงานของเรามีชื่อที่ฉลาดน้อยกว่า: sub01, sub02, sub03 เป็นต้น "sub" มาจากข้อเท็จจริงที่ว่าสาขางานทั้งหมดเป็นสาขาย่อย ของสาขาการยอมรับ สาขาการยอมรับเป็นสาขาหนึ่งที่รวบรวมปัญหาทั้งหมดที่พร้อมให้เผยแพร่

นโยบายสาขาที่ทำงาน 1 ฉบับที่ 1 ของเรารวมกับความจริงที่ว่าระบบติดตามปัญหาของเราได้รับการปรับแต่งด้วยฟิลด์ "สาขา" เพื่อให้แน่ใจว่าเรารู้เสมอว่าปัญหาใดได้รับการพัฒนาในสาขาใด เมื่อปัญหาถูกรวมเข้ากับสาขาการยอมรับฟิลด์นี้จะถูกอัพเดต นี่หมายความว่าเรารู้อยู่เสมอว่ามีปัญหาใดบ้างที่จะพร้อมปล่อย (เมื่อทำการทดสอบการยอมรับ) ในทำนองเดียวกันเราอัปเดตฟิลด์นี้เมื่อมีการสร้างสาขาที่วางจำหน่ายและด้วยวิธีนี้เราสามารถติดตามได้ว่าจะปล่อยปัญหาใดออกมา

มันเกี่ยวกับบริบท: คุณปล่อยบ่อยแค่ไหนและมีอะไรบ้างในรุ่น

นี่เป็นกรณีศึกษาเล็กน้อยที่ฉันมีกับงานเก่าโดยใช้วิธีB (เราเรียกมันว่าสาขาตามวัตถุประสงค์ )

เพื่อนำเรื่องราวมาสู่บริบท

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

การพัฒนาหลักถูกสร้างขึ้นในลำตัวจนกว่าเราจะถึงสถานะสมบูรณ์คุณลักษณะสำหรับรุ่นที่แน่นอน ณ จุดนั้นเราจะสร้างสาขากล่าวว่าprojectname-january2012และทำการทดสอบคุณภาพและแก้ไขข้อบกพร่องในสาขานั้น เมื่อเราพร้อมสำหรับการเปิดตัวสู่สาธารณะเราจะติดแท็กรหัสในสาขานั้นและปล่อย

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

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

ดังนั้นคำถามที่คุณต้องถามตัวเองคือ:

• ฉันจะปลดปล่อยบ่อยแค่ไหน?
• รุ่นของฉันจะเข้ากันได้ย้อนหลัง 100% หรือไม่
• ลูกค้าของฉันจะโอเคกับการอัพเกรดอย่างสมบูรณ์เพื่อแก้ไขข้อบกพร่อง?

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

ฉันชอบตัวเลือก A. พัฒนาบนลำตัวและรีลีสของสาขาเมื่อมันเสถียร สิ่งนี้ จำกัด งานในการรวมฮอตฟิกซ์ที่ใช้กับรีลีสการผลิต

ฉันได้รับสัญญาว่าจ้างให้ช่วยเหลือทีมที่พยายามตัวเลือก B กลับมาสู่เส้นทางเดิม

สิ่งที่ควรพิจารณา

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

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

โดยเฉพาะอย่างยิ่งถ้าเรารู้ว่าลูกค้ามีรุ่นที่แน่นอนอะไรเรารู้แน่ ๆ ว่าซอร์สโค้ดถูกสร้างจากอะไรและสามารถทำซ้ำได้อย่างแน่นอนเพื่อให้เราเห็นว่าเกิดอะไรขึ้น สิ่งนี้สำคัญมากสำหรับการสนับสนุน! แต่ในระดับนอกสุดของสาขา, เวอร์ชั่น API ที่เราปล่อยออกมาในขณะนี้, พวกมันพัฒนาไปตามกาลเวลา (ด้วยการพัฒนาหลัก ๆ เพื่อให้ได้ฟีเจอร์ใหม่ ๆ ) นอกจากนี้เมื่อเราทำการเปิดตัว API ใหม่ที่สำคัญเราจะทำการเปิดสาขาใหม่สำหรับการสนับสนุนจาก (เพื่อให้ trunk สามารถใช้การพัฒนาแบบ hard-core ได้เสมอ) และเราพิจารณาว่าเราควรจะจบชีวิตของการสนับสนุนที่เก่าแก่ที่สุดในปัจจุบัน สาขา.

ดังนั้นผมขอแนะนำสิ่งที่เป็นจริงที่มีส่วนผสมของทั้งและB ; ทั้งสองมีลักษณะที่ดี แต่ไม่สมบูรณ์ในตัวเอง ใช้สิ่งที่ดีที่สุดของทั้งสองโลก

ฉันเคยใช้ TFS เพื่อใช้งานตัวเลือก (B) ในอดีตอย่างมีประสิทธิภาพ

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

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

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

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