แนะนำนโยบายการแยกการควบคุมเวอร์ชันให้กับทีมเล็ก ๆ


17

ฉันเป็นผู้รับเหมาที่เพิ่งเริ่มต้นกับ บริษัท

ทีมคือนักพัฒนา 3 คนซึ่งประกอบด้วยผู้พัฒนา 2 คนถึงระดับกลางและอีกคนในระดับเดียวกันเริ่มเร็ว ๆ นี้และตัวฉันเอง (6 ปี xp) สำหรับนักพัฒนาทั้งสองที่มีอยู่มันเป็นงานแรกของพวกเขาที่ออกจากมหาวิทยาลัย / วิทยาลัยและพวกเขาไม่เคยมีนักพัฒนาอาวุโสที่ดูแลงานของพวกเขามาก่อน

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

ฉันกำลังเปลี่ยนแปลงทั้งหมดนี้และแนะนำเซิร์ฟเวอร์ CI, การทดสอบ TDD / การจัดเตรียม / การผลิต ฯลฯ พร้อมกับนโยบายการควบคุมเวอร์ชันเพื่อชมเชยสิ่งนี้

ระบบควบคุมแหล่งที่มาคือ TFS ซึ่งฉันไม่เคยใช้มาก่อน มันถูกกำหนดค่าให้เป็นแหล่งเก็บข้อมูลขนาดยักษ์

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

นโยบายการควบคุมเวอร์ชัน

การพัฒนาจะทำบนลำต้น

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

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

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

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

ถ้าเราใช้สาขาแยกต่อกลยุทธ์การปล่อยแล้วลำตัวไม่เคยถูกรวมเข้ากับสาขาการปล่อย

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


ฉันวางแผนที่จะมีสามเซิร์ฟเวอร์ สภาพแวดล้อมการทดสอบที่ใช้รหัสล่าสุดใน repo เสมอ สภาวะแวดล้อมการเตรียมใช้ซึ่งเรียกใช้ตัวเลือกรีลีสล่าสุดสำหรับการจัดเตรียม / การทดสอบรหัสผู้สมัครและวัตถุประสงค์ UAT และสภาพแวดล้อมการใช้งานจริง

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

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


ในอดีตฉันคิดว่าสาขาคุณลักษณะเป็นขั้นตอนที่ไกลเกินไปและฉันจะลบมัน

ดังนั้นโดยพื้นฐานแล้วมันจะลงไปที่ a) ไม่มีการแตกแขนงเลย b) สาขาย่อยและลำตัวและ c) สาขาย่อยต่อปล่อยและลำตัว

ฉันเอนตัวไปข้างหลัง ความคิดเริ่มต้นของฉันคือฉันจะมีทั้งตัวเลือกการเปิดตัวและการเปิดตัวที่จะเผยแพร่บนเซิร์ฟเวอร์ที่แยกต่างหาก (UAT / การผลิต) ในเวลาเดียวกัน การเปิดตัวจะเอนไปทางบ้า ความคิดเดียวของฉันคือถ้าเราไม่ต้องการให้ผู้มีส่วนได้ส่วนเสียของเราเห็นรหัสการพัฒนาเราอาจต้องการสาขาผู้สมัครแยกต่างหาก แต่ YAGNI และทั้งหมดนั้น .....


3
คุณพิจารณาเพิ่มคำอธิบายว่าทำไมคุณถึงเลือกวิธีนี้ พูดในทำนองเดียวกันกับวิธีการที่จะทำที่นี่ นอกจากนี้คุณได้ตรวจสอบ "คำแนะนำการแบ่งสาขาของเซิร์ฟเวอร์ Microsoft Team Foundation" (อ้างอิงเช่นที่นี่ ) หรือไม่
ริ้น

3
ลองอันนี้
gbjbaanb

1
โปรดจำไว้ว่าฉันใช้ TFS ไม่ใช่ DVCS เช่น GIT ดูเหมือนว่าเฉพาะคอมไพล์เล็กน้อย
MrBliz

2
ในตอนท้ายของลิงค์นั้นบอกว่า: "ทุกคนทำงานได้จากลำต้นสาขาเมื่อคุณปล่อยรหัสสาขาออกมาเมื่อคุณต้องการสร้างการแก้ไขข้อบกพร่องสำหรับรหัสที่วางจำหน่ายแล้วสาขาสำหรับต้นแบบ" ฉันขอแนะนำว่าสำหรับการเริ่มต้นง่ายๆคุณเพียงแค่ติดป้ายประชาสัมพันธ์เมื่อคุณแน่ใจว่าเสร็จแล้ว นอกจากว่าคุณจะมีนักพัฒนาหลายคนที่ทำงานในหลาย ๆ คุณสมบัติก็ไม่จำเป็นต้องมีมากกว่า 1 สาขา ทุกคนเพิ่มคุณสมบัติทุกคนแก้ไขตัวเลือกการเปิดตัวทุกคนตกลงเมื่อพร้อมที่จะแท็ก นั่นหมายความว่าคุณจะต้องทำการแยกสาขาเพื่อแก้ไขข้อบกพร่องในภายหลัง
TafT

1
ฉันรู้สึกไม่สะดวกใจที่จะใส่คำตอบนี้เพราะมันมีพื้นฐานจากความคิดเห็น แต่ฉันประสบความสำเร็จอย่างมากในการโน้มน้าวให้ผู้คนใช้แท็ก "รู้จักกันดี" (LKG) ซึ่งเป็นแท็กที่เคลื่อนไหวบนลำตัวเพื่อระบุคนสุดท้าย "รุ่น (CCB การทดสอบ ฯลฯ ) นักพัฒนาซอฟต์แวร์จะบอกว่าการเผยแพร่จะทำจากแท็ก LKG นี้ไม่ใช่ส่วนหัวของลำตัวและนอกเหนือจากนั้นพวกเขามีอิสระที่จะใช้วิธีการที่เหมาะสมกับพวกเขาในเวลานั้น ฉันได้พบรูปแบบนี้เพื่อสร้างฟีเจอร์ - สาขาโดยอัตโนมัติเมื่อถึงเวลาโดยไม่ต้องใช้ความพยายามมากขึ้นหรือทำงานพิเศษในส่วนของนักพัฒนา
Cort Ammon - Reinstate Monica

คำตอบ:


16

สำหรับทีม 3-4 devs คุณกำลังเสนอสาขามากเกินไป

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

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

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

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

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

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

เรามีทีมงานของนักพัฒนา 4 คนที่ทำงานบนโค้ดเบสของ 1+ ล้านบรรทัดและนี่คือวิธีการทำงานของเรา:

  • สาขาหลักที่การพัฒนาทั้งหมดเสร็จสิ้น
  • หนึ่งสาขาต่อสาขาใหญ่ (ทำประมาณปีละครั้ง)

กฎหลักข้อหนึ่งคือ: อย่าเช็คอินโค้ดที่ไม่ได้สร้าง

แค่นั้นแหละ. เรียบง่ายเข้าใจง่ายได้รับการแยกที่เราต้องการ (ทุกเวลาที่เราสามารถสร้างรุ่นสร้างสำหรับรุ่นใด ๆ )

การเพิ่มขึ้นของการพัฒนางานทั้งหมดในสาขาเดียว:

  1. นักพัฒนาจะซิงค์กันเสมอ ไม่มีการรวมที่เจ็บปวดเพราะนักพัฒนาสองคนปิดสาขาของตนเองเป็นเวลาหลายสัปดาห์เพื่อสร้างการเปลี่ยนแปลงที่เข้ากันไม่ได้
  2. งานสร้างที่เสียหายจะพบในวันเดียวกัน เรามีบิลด์ยามค่ำคืนที่รันโค้ดล่าสุดบนเมน หากมีคนตรวจสอบรหัสที่ไม่ได้สร้างด้วยเหตุผลบางอย่างเราจะรู้ได้ทันที
  3. เมื่อทุกคนทำงานกับรหัสเดียวกันจะเพิ่มโอกาสในการพบข้อผิดพลาดได้เร็วกว่าในภายหลัง
  4. ไม่มีการรวมค่าโสหุ้ยอื่นนอกจากการแก้ไขเป้าหมายเพื่อปล่อยสาขา ในทีมเล็ก ๆ นี่เป็นทีมที่ยิ่งใหญ่

10
"โปรดทราบว่าประโยชน์ที่แท้จริงเพียงอย่างเดียวของสาขาคือการแยกรหัสซึ่งหมายความว่าคุณต้องมีเหตุผลที่ชัดเจนที่ต้องการแยกรหัส" - แล้วรีวิวโค้ดล่ะ? ฉันคิดว่านั่นเป็นเหตุผลที่ดีแม้จะมี devs เพียงสองตัว
BlueRaja - Danny Pflughoeft

2
การตรวจสอบโค้ดและการแตกแขนงไม่เกี่ยวข้องกันจริงๆ คุณกำลังบอกว่าคุณไม่ต้องการให้มีการตรวจสอบรหัสในสาขาใดสาขาหนึ่งก่อนที่จะทำการตรวจสอบ?
17 ของ 26

5
@ 17of26 ใช่ การตรวจสอบรหัสโดยทั่วไปจะใช้เป็นสิ่งที่จำเป็นต้องมีในการฉีด ดังนั้นคุณจะต้องแสดงรหัสด้วยวิธีใดวิธีหนึ่งก่อนหน้านี้: บนจอภาพของคุณในอีเมลหรือในหลาย ๆ การตั้งค่า วิธีนี้ใช้ได้ผลดีที่สุดกับเครื่องมือการจัดการ repo เช่น GitHub หรือ gerrit
พอลเดรเปอร์

3
TFS รองรับการตรวจสอบโค้ดผ่านชั้นวางซึ่งเป็นพื้นที่เก็บชั่วคราวในการควบคุมแหล่งที่มา รหัสสามารถอยู่ที่นั่นได้จนกว่าจะได้รับการตรวจสอบแล้วเช็คอิน
17 จาก 26

2
ฉันคิดว่าประเด็นคือสาขาไม่ใช่กลไกที่เหมาะสมที่จะใช้สำหรับการทำรีวิวโค้ด
17 ของ 26

31

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

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

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

  • นักพัฒนาต้องคิดว่าการเปลี่ยนแปลงควรจะอยู่ที่ไหน

  • ใครบางคนจะต้องจัดการสาขาและผสานจากสาขาไปยังลำตัว

  • การรวมสาขาระหว่างกันนั้นกระทำได้น้อยกว่าการกระทำซึ่งหมายความว่าใครบางคนต้องจัดการกับความขัดแย้งที่ใหญ่กว่าและยากต่อการจัดการมากกว่าความขัดแย้งระหว่างสองคอมมิชชัน

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

ความจริงที่ว่า:

ทีมที่มีอยู่ไม่คุ้นเคยกับการแตกแขนง

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


3
ในรุ่นนี้คุณจะหยุดการสร้างโค้ดที่ไม่เสถียรในการผลิตโดยไม่แยกสาขาได้อย่างไร
MrBliz

2
@MrBliz: ผ่านสวิตช์ คุณสามารถเปิดใช้งานคุณลักษณะสำหรับนักพัฒนา แต่ปิดการใช้งานสำหรับผู้ใช้หากยังไม่พร้อมสำหรับ RTM
Arseni Mourzenko

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

4
@MrBliz คุณหยุดการทำงานของโค้ดที่ไม่เสถียรโดยการแยกมันออกเป็นกิ่งก้านสาขา (นั่นคือจุดประสงค์ของพวกมัน) และโดยการทดสอบมัน สาขาฟีเจอร์ไม่ได้ช่วยในเรื่องนั้น อันที่จริงแล้วสิ่งเหล่านี้มีความเสี่ยงที่สูงขึ้นในการแนะนำความไม่แน่นอนของการควบรวมกิจการขนาดใหญ่ที่ไม่ได้บูรณาการและควบคุมได้ยาก
gnat

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

3

อย่างที่ Mainma พูดไว้ระวังด้วยการแตกกิ่ง คุณพูดถึงการแตกกิ่งทุกสองสามสัปดาห์จำเป็นต้องมีสาขามากมายหรือไม่?

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


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

สาขาเก่าจะถูกลบใน TFS หรือซ่อนอย่างถูกต้องมากขึ้น
MrBliz
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.