คุณพัฒนาต่อไปในสาขาหรือในลำตัว? [ปิด]

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

ฉันลองทั้งสองวิธีด้วยแอปพลิเคชันเชิงพาณิชย์ขนาดใหญ่

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

วิธีที่ดีกว่าโดยรวม (จากประสบการณ์ของฉัน): ลำต้นควรมีเสถียรภาพเสมอ

ต่อไปนี้เป็นแนวทางและประโยชน์ของวิธีนี้:

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

หากคุณพยายามทำสิ่งที่ตรงกันข้ามและทำการพัฒนาทั้งหมดในท้ายรถคุณจะพบปัญหาต่อไปนี้:

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

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

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

โดยวิธีการที่ระบบควบคุมเวอร์ชันที่กระจายนั้นมอบความยืดหยุ่นมากกว่าและฉันแนะนำให้เปลี่ยนเป็น hg หรือ git

ฉันทำงานกับทั้งสองเทคนิคแล้วฉันจะบอกว่าการพัฒนาบนลำตัวและแยกจุดที่มั่นคงออกเป็นวิธีที่ดีที่สุดที่จะไป

คนข้างบนที่คัดค้านว่าคุณจะต้อง:

• ปัญหาการสร้างอย่างต่อเนื่องสำหรับงานสร้างรายวัน
• การสูญเสียผลิตผลเมื่อนักพัฒนา aa ยอมรับปัญหาสำหรับคนอื่น ๆ ทั้งหมดในโครงการ

อาจไม่ได้ใช้เทคนิคการรวมอย่างต่อเนื่อง

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

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

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

ได้อ่านจากกระดาษมาร์ตินฟาวเลอร์บนบูรณาการอย่างต่อเนื่อง เราเปิดตัวระบบดังกล่าวสำหรับโครงการสำคัญ (3,000kSLOC) ใน Posix sh ประมาณ 2,000 บรรทัด

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

ฉันเข้าใจว่ามีวิธีอื่นที่จะทำ - นี่เป็นเพียงวิธีที่ฉันเคยทำในอดีต

ทั้งสอง

ลำต้นใช้สำหรับการพัฒนาส่วนใหญ่ แต่คาดว่าจะพยายามอย่างเต็มที่เพื่อให้แน่ใจว่าการเช็คอินที่ท้ายรถจะไม่ทำให้เกิดความเสียหาย (ตรวจสอบบางส่วนโดยระบบสร้างและทดสอบอัตโนมัติ)

รีลีสจะถูกเก็บรักษาไว้ในไดเรกทอรีของตัวเองโดยมีการแก้ไขข้อบกพร่องเท่านั้น

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

ฉันชอบและใช้วิธีการอธิบายโดยเฮนริก Kniberg ในการควบคุมเวอร์ชันสำหรับทีมเปรียวหลาย เฮนริกทำได้ดีมากในการอธิบายวิธีจัดการกับการควบคุมเวอร์ชันในสภาพแวดล้อมที่คล่องตัวด้วยหลายทีม (ทำงานสำหรับทีมเดียวในสภาพแวดล้อมแบบดั้งเดิมด้วย) และไม่มีประเด็นใดที่จะถอดความเขาดังนั้นฉันจะโพสต์ "สูตรโกง" อธิบายตนเอง) ด้านล่าง:

ฉันชอบมันเพราะ:

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

และในกรณีที่มันไม่ชัดเจนพอ: การพัฒนาเสร็จสิ้นใน "work branch (es)" ลำต้นจะใช้สำหรับรหัส DONE (releasable) ตรวจสอบการควบคุมเวอร์ชันสำหรับหลายทีม Agileสำหรับรายละเอียดทั้งหมด

การอ้างอิงที่ดีในกระบวนการพัฒนาที่ช่วยให้มีเสถียรภาพลำตัวและทำงานในสาขาที่เป็น Divmod ของระบบการพัฒนาคุณภาพที่ดีที่สุด สรุปอย่างรวดเร็ว:

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

พวกเขาใช้ SVN สำหรับสิ่งนี้ แต่สามารถทำได้อย่างง่ายดายกับระบบควบคุมเวอร์ชันที่แจกจ่ายใด ๆ

ฉันคิดว่าวิธีการที่สองของคุณ (เช่นการติดแท็กการเผยแพร่และทำสิ่งทดลองในสาขาโดยพิจารณาจากความเสถียรของลำตัว) เป็นวิธีที่ดีที่สุด

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

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

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

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

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

ความงามของสิ่งนี้คือคุณสามารถทำสิ่งนี้ซ้ำ ๆ ได้: กิ่งก้านสาขาขนาดใหญ่อาจเป็นลำต้นของมันเองพร้อมกิ่งอื่น ๆ ที่หลุดออกมาถ้ามัน นอกจากนี้รุ่นสุดท้ายจะได้รับสาขาใหม่เพื่อให้คุณมีสถานที่สำหรับการบำรุงรักษาที่มั่นคง

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

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

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

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

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

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

คุณจะต้องทดสอบว่าคุณมีกลุ่มนักพัฒนาขนาดใหญ่และรู้สึกอย่างไรกับสถานการณ์ของคุณ นี่คือหน้าจาก Microsoft ที่อาจมีประโยชน์บ้าง: http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx

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

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

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

เราติดตาม trunk = กระแสการพัฒนาปัจจุบัน branch = release (s) เมื่อวางจำหน่ายให้กับลูกค้าเราแยกลำต้นและเก็บลำต้นไว้ด้านหน้า คุณจะต้องตัดสินใจว่าจะเตรียมการสนับสนุนจำนวนเท่าใด ยิ่งคุณสนับสนุนการรวมที่มากขึ้นคุณจะต้องทำการแก้ไขข้อบกพร่อง เราพยายามและรักษาลูกค้าของเราไว้ไม่เกิน 2 รุ่นที่อยู่ด้านหลังลำตัว (เช่น Dev = 1.3, รองรับ 1.2 และ 1.1)

ลำต้นโดยทั่วไปเป็นสายการพัฒนาหลัก

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

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

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

สำหรับฉันมันขึ้นอยู่กับซอฟต์แวร์ที่ฉันใช้

ภายใต้ CVS ฉันจะทำงานใน "trunk" และไม่ติดแท็ก / สาขาเพราะมันเจ็บปวดจริงๆที่จะทำอย่างอื่น

ใน SVN ฉันจะทำสิ่งที่ "ตกเลือดขอบ" ของฉันในท้าย แต่เมื่อถึงเวลาที่จะผลักดันเซิร์ฟเวอร์ได้รับการติดแท็กอย่างเหมาะสม

ฉันเพิ่งเปลี่ยนเป็นคอมไพล์ ตอนนี้ฉันพบว่าฉันไม่เคยทำงานในหีบ แต่ฉันใช้ชื่อแซนด์บ็อกซ์ "new-featurename" ชื่อแล้วรวมเข้ากับสาขา "การผลิตปัจจุบัน" ที่แน่นอน ตอนนี้ที่ฉันคิดเกี่ยวกับมันฉันควรจะทำให้สาขา "รุ่น -VERSIONNUMBER" ก่อนที่จะรวมกลับไปเป็น "ผลิตในปัจจุบัน" เพื่อให้ฉันสามารถกลับไปที่รุ่นที่มั่นคงเก่ากว่า ...

ขึ้นอยู่กับว่าองค์กร / ทีมของคุณจัดการเวอร์ชันและ SCM ที่คุณใช้ดีเพียงใด

• หากสามารถวางแผนสิ่งต่อไป (ในรุ่นถัดไป) ได้อย่างง่ายดายคุณจะดีขึ้นเมื่อพัฒนาในลำตัว การจัดการสาขาต้องใช้เวลาและทรัพยากรมากขึ้น แต่ถ้าไม่สามารถวางแผนต่อไปได้อย่างง่ายดาย (เกิดขึ้นตลอดเวลาในองค์กรที่ใหญ่กว่า) คุณอาจจะจบลงด้วยการเลือกเก็บเชอร์รี่ (หลายร้อย / พันบาท) แทนที่จะเป็นสาขา (แยกหรือสิบ)
• ด้วย Git หรือ Mercurial การจัดการสาขาทำได้ง่ายกว่า cvs และการโค่นล้ม ฉันจะไปหาวิธีเก็บรักษาลำต้น / หัวข้อที่มั่นคง นี่คือสิ่งที่ทีม git.git ใช้ อ่าน: http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
• ด้วยการโค่นล้มฉันแรกใช้วิธีการพัฒนาในลำตัว มีงานบางอย่างเมื่อมันมาถึงวันที่วางจำหน่ายเพราะทุกครั้งที่ฉันต้องรับภาระเชอร์รี่ (บริษัท ของฉันไม่เก่งเรื่องการวางแผน) ตอนนี้ฉันเป็นผู้เชี่ยวชาญในการโค่นล้มและรู้ดีเกี่ยวกับการจัดการสาขาในการโค่นล้มดังนั้นฉันจึงย้ายไปยังวิธีการที่มั่นคงสาขา / หัวข้อ มันใช้งานได้ดีกว่า แต่ก่อนมาก ตอนนี้ฉันกำลังลองวิธีที่ทีม git.git ทำงานแม้ว่าเราจะติดอยู่กับการโค่นล้ม

นี่คือการออกแบบ SVN ที่ฉันชอบ:

• ราก
  • พัฒนาการ
    • สาขา
      • Feature1
      • feature2
      • ...
    • กระโปรงหลังรถ
  • เบต้า
    • แท็ก
    • กระโปรงหลังรถ
  • ปล่อย
    • แท็ก
    • กระโปรงหลังรถ

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

แท็กสามารถทำในสาขาเบต้าหรือสาขาที่วางจำหน่ายเพื่อให้เราสามารถติดตามการเปิดตัวที่เฉพาะเจาะจงสำหรับทั้งรุ่นเบต้าและรุ่น

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

วิธีที่เราใช้คือวิธี Perforce ซึ่งกล่าวถึงในหนังสือเล่มที่ยอดเยี่ยมของ Laura Wingerd:

http://oreilly.com/catalog/9780596101855/index.html

ในขณะที่หนังสือเล่มนี้เป็นศูนย์กลางอย่างแรง (Wingerd เป็นผู้จัดการผลิตภัณฑ์ Perforce) แนวคิดสามารถนำไปใช้กับ VCS ใด ๆ หรือทั้งหมด

วิธีการที่จำเป็น (และแพลตฟอร์ม) ได้ทำหน้าที่เราเป็นอย่างดี มันถูกใช้ในหลาย ๆ บริษัท (google, Intuit และฉันเคยได้ยินชื่อ Microsoft Windows)

หนังสือเล่มนี้คุ้มค่ากับการอ่าน

อ่านสิ่งนี้: http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

ไม่มีคำตอบที่เหมาะกับทุกขนาดสำหรับคำถามการโค่นล้มการประชุม IMHO

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

นอกจากนี้จากประสบการณ์ของฉันมันง่ายมากจากมุมมองการบริหารที่บริสุทธิ์เพื่อสลับไปมาระหว่างวิธี svn เมื่อคุณเลือก

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

@Brian R. Bondy: โปรดทราบว่านี่ไม่ใช่วิธีแก้ปัญหาเมื่อทีมของคุณถึงจำนวน ppl / งานที่จัดการในโครงการคู่ขนาน

เมื่อแผนก QA เกี่ยวข้องกับ qa ความพยายามที่จำเป็นในการติดตั้งหนึ่งครั้งต่อสาขาที่ดำเนินการอยู่นั้นสูงเกินไป คิดว่าSOA / ลูกค้า / เซิร์ฟเวอร์ / WebServices / ฐานข้อมูลทั้งหมดที่มีจะให้ต่อสาขา

โซลูชันนี้ขาดขั้นตอนการรวมเข้าด้วยกัน