ปวดหัวโดยใช้การควบคุมเวอร์ชันแบบกระจายสำหรับทีมดั้งเดิม?

แม้ว่าฉันจะใช้และชอบ DVCS สำหรับโครงการส่วนบุคคลของฉันและสามารถเห็นได้อย่างชัดเจนว่ามันช่วยให้คุณจัดการการสนับสนุนโครงการของคุณจากผู้อื่นได้ง่ายขึ้น (เช่นสถานการณ์ Github ทั่วไปของคุณ) แต่ดูเหมือนว่าสำหรับทีม "ดั้งเดิม" อาจมีปัญหามากกว่า วิธีการรวมศูนย์ที่ใช้งานโดยโซลูชันเช่น TFS, Perforce เป็นต้น (โดย "ดั้งเดิม" ฉันหมายถึงทีมนักพัฒนาในสำนักงานที่ทำงานในโครงการหนึ่งที่ไม่มีใคร "เป็นเจ้าของ" โดยทุกคนอาจสัมผัสรหัสเดียวกัน)

ปัญหาเหล่านี้สองสามอย่างที่ฉันเห็นล่วงหน้าด้วยตัวเอง แต่โปรดพูดสอดแทรกกับข้อควรพิจารณาอื่น ๆ

ในระบบดั้งเดิมเมื่อคุณพยายามตรวจสอบการเปลี่ยนแปลงของคุณในเซิร์ฟเวอร์หากมีคนอื่นตรวจสอบก่อนหน้านี้ในการเปลี่ยนแปลงที่ขัดแย้งกันแล้วคุณจะถูกบังคับให้รวมก่อนที่คุณจะสามารถตรวจสอบของคุณในรุ่น DVCS นักพัฒนาแต่ละคนตรวจสอบ การเปลี่ยนแปลงในท้องถิ่นและในบางจุดผลักไปที่ repo อื่น ๆ repo นั้นมีสาขาของไฟล์นั้นที่ 2 คนเปลี่ยน ดูเหมือนว่าตอนนี้บางคนต้องรับผิดชอบในการจัดการกับสถานการณ์นั้น บุคคลที่ได้รับมอบหมายในทีมอาจไม่มีความรู้เพียงพอเกี่ยวกับ codebase ทั้งหมดเพื่อให้สามารถจัดการกับการรวมความขัดแย้งทั้งหมด ดังนั้นตอนนี้จึงมีการเพิ่มขั้นตอนพิเศษที่บางคนต้องเข้าหาหนึ่งในผู้พัฒนาบอกให้เขาดึงและทำการรวมแล้วกดอีกครั้ง (หรือคุณต้องสร้างโครงสร้างพื้นฐานที่ทำงานโดยอัตโนมัติ)

นอกจากนี้เนื่องจาก DVCS มีแนวโน้มที่จะทำงานในพื้นที่ให้สะดวกจึงมีความเป็นไปได้ที่นักพัฒนาจะสามารถสะสมการเปลี่ยนแปลงบางอย่างใน repos ท้องถิ่นของพวกเขาก่อนที่จะผลักดันทำให้ความขัดแย้งดังกล่าวเป็นเรื่องธรรมดาและซับซ้อนมากขึ้น

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

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

เราใช้ Mercurial ประมาณหนึ่งปี ในขณะที่อาการปวดหัวที่คุณพูดถึงนั้นมีอยู่ความท้าทายที่ยิ่งใหญ่ที่สุดในการยอมรับอย่างเต็มที่สำหรับเราคือการเข้าสู่ความคิด DVCS ของที่เก็บในท้องที่ (= กระทำบ่อย ๆ ) ความคิดเก่า ๆ ของ "Commit เมื่อคุณขัดรหัส" อาจเป็นเรื่องยาก ไป.

คุณพูดว่า:

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

การติดตั้งเริ่มต้นของ Mercurial บล็อกพฤติกรรมนี้ มันจะไม่อนุญาตให้มีการผลักหากมีมากกว่าหนึ่งหัวจะถูกสร้างขึ้นใน repo ระยะไกลโดยไม่มีการยืนยันเป็นพิเศษ สำหรับกิจกรรมประจำวันเราหลีกเลี่ยงสิ่งนั้น (Git ได้รับการตั้งชื่อเป็นเฮดเดอร์และแต่ละคนสามารถอัปเดตได้ก็ต่อเมื่อผสานเวอร์ชันก่อนหน้าทั้งหมดโดยไม่ต้องมีการยืนยันเพิ่มเติมดังนั้นจึงไม่สามารถเกิดสถานการณ์ได้อีก DVCS อื่นมีการป้องกันที่คล้ายคลึงกันเช่นกัน)

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

1. กระทำการเปลี่ยนแปลงในท้องถิ่น
2. ดึงจาก repo ส่วนกลาง
3. รวม (& กระทำการรวม)
4. กดไปที่ repo ส่วนกลาง

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

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

ปัญหาอื่นที่คุณพูดถึง:

นอกจากนี้เนื่องจาก DVCS มีแนวโน้มที่จะทำงานในพื้นที่ให้สะดวกจึงมีความเป็นไปได้ที่นักพัฒนาจะสามารถสะสมการเปลี่ยนแปลงบางอย่างใน repos ท้องถิ่นของพวกเขาก่อนที่จะผลักดันทำให้ความขัดแย้งดังกล่าวเป็นเรื่องธรรมดาและซับซ้อนมากขึ้น

สิ่งนี้ไม่ได้สร้างปัญหาการผสานสำหรับเรา แต่สามารถสร้างปัญหาอื่นได้:

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

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

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

นั่นคือเรื่องราวของฉันและฉันก็ติดอยู่กับมันอย่างน้อยสองสามนาที ...

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

เนื่องจากคำตอบที่ดีของ Jamie F - ขั้นตอนการทำงานของ Commit-Pull-Merge-Push ทำอย่างสม่ำเสมอ (ทุกวัน) หมายความว่าถ้าคุณกำลังเดินไปทำงานบางอย่างคุณจะเห็นได้เร็ว - ตราบใดที่มองเห็นได้ก็สามารถจัดการได้ .

ปัญหาที่คุณอธิบายมีมากขึ้นเกี่ยวกับวิธีการเลือกใช้เครื่องมือ

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

เมื่อฉันทำงานกับทีมที่ใช้คอมไพล์กฎของหัวแม่มือก็คือ: ทำงานในสาขาส่วนตัวจากนั้นเมื่อคุณพร้อมที่จะทำให้งานของคุณพร้อมใช้งานกับส่วนที่เหลือของทีม (จากนั้นตรวจสอบสาขาของคุณ)

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

เครื่องมืออย่าง SVN สนับสนุนวิธีการทำงานแบบบูรณาการอย่างแน่นหนา

นั่นคือการคอมมิชชันกับสาขาที่ใช้ร่วมกันบ่อยครั้ง (เช่น trunk หรือสาขา dev)

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

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

ความกังวลที่มักจะเกิดขึ้นที่ด้านหลังของจิตใจของฉันคือสิ่งนี้: ด้วยอิสรภาพอันยิ่งใหญ่สิ่งล่อใจให้ใช้เสรีภาพนั้น

แน่นอนจากประสบการณ์ (จำกัด ) ของฉันฉันใช้เวลาทำงานเป็นอิสระมากขึ้นในทีมปัจจุบันของฉัน (ใช้ Mercurial) มากกว่าที่ฉันทำในบทบาทก่อนหน้า (ที่เราใช้ SVN, CVS & P4)

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

นี่ไม่ใช่สิ่งเลวร้าย แต่ฉันเชื่อว่ามันเป็นสิ่งที่ต้องนำมาพิจารณา

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

1. กระทำในท้องถิ่นจำนวนมาก
2. ดึงจากเซิร์ฟเวอร์
3. กดไปที่เซิร์ฟเวอร์

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

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

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

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

หลักการทำงานกับที่เก็บแบบรวมศูนย์จะเหมือนกันเมื่อทำงานกับระบบแบบรวมศูนย์หรือแบบไม่ล็อค:

• ในระบบส่วนกลางคุณ:
  1. รับเวอร์ชันล่าสุดจากการฉีด ("ลำตัว" ในการโค่นล้ม "ปรมาจารย์" ในคอมไพล์, ... )
  2. แก้ไขไฟล์
  3. ผสานการแก้ไขด้วยเวอร์ชั่นล่าสุดจากการฉีดโดยใช้คำสั่ง "update"
  4. มุ่งมั่นที่จะฉีด
• ในระบบกระจายคุณ:
  1. รับเวอร์ชันล่าสุดจากการฉีด
  2. แก้ไขไฟล์
  3. กระทำในท้องถิ่น
  4. ผสานการแก้ไขด้วยเวอร์ชั่นล่าสุดจากการฉีดและส่งผลลัพธ์ในพื้นที่
  5. กดเพื่อฉีด

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

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

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

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