แนวปฏิบัติที่เหมาะสมกับซอร์สโค้ดการแยกและวงจรชีวิตของแอปพลิเคชัน

เราเป็นร้าน ISV ขนาดเล็กและเรามักจะจัดส่งผลิตภัณฑ์รุ่นใหม่ทุกเดือน เราใช้การโค่นล้มเป็นที่เก็บรหัสและ Visual Studio 2010 เป็น IDE ของเรา ฉันรู้ว่าผู้คนจำนวนมากกำลังสนับสนุน Mercurial และระบบควบคุมแหล่งข้อมูลแบบกระจายอื่น ๆ แต่ ณ จุดนี้ฉันไม่เห็นว่าเราจะได้ประโยชน์จากสิ่งเหล่านี้อย่างไร แต่ฉันอาจผิด

ปัญหาหลักของเราคือวิธีการทำให้สาขาและลำต้นหลักตรงกัน

นี่คือวิธีที่เราทำสิ่งต่าง ๆ ในวันนี้:

1. ปล่อยเวอร์ชันใหม่ (สร้างแท็กในการโค่นล้มโดยอัตโนมัติ)
2. ทำงานต่อในลำตัวหลักที่จะเปิดตัวในเดือนหน้า

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

ในกรณีเช่นนี้เราจะทำสิ่งต่อไปนี้:

1. สร้างสาขาจากแท็กที่เราสร้างในขั้นตอน (1)
2. แก้ไขข้อผิดพลาด
3. ทดสอบและปล่อย
4. ผลักดันการเปลี่ยนแปลงกลับไปที่ลำต้นหลัก (ถ้ามี)

ปัญหาที่ใหญ่ที่สุดของเราคือการรวมสองสิ่งนี้ (สาขากับหลัก) ในกรณีส่วนใหญ่เราไม่สามารถพึ่งพาการรวมอัตโนมัติได้เช่น:

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

ดังนั้นสิ่งที่คุณคิดว่าเป็นแนวทางปฏิบัติที่ดีที่สุดในการทำให้ทั้งสองเวอร์ชันแตกต่างกัน (สาขาและหลัก) ในการซิงค์ คุณทำอะไร?

ฉันคิดว่าวิธีการของคุณในการแยกและรวมกันนั้นก็โอเค แต่ถ้าปัญหาหลักคือรหัสฐานนั้นค่อนข้างไม่เสถียรนั่นคือสิ่งที่คุณต้องมุ่งเน้นและย่อเล็กสุด

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

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

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

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

ฉันมักจะมองจากทางตรงกันข้าม:

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

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

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

วิธีการที่วางจำหน่ายบนหลักการมีระเบียบวินัยทำงานได้ดี

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