DVCSes ไม่สนับสนุนการรวมอย่างต่อเนื่องหรือไม่?

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

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

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

ในสถานการณ์สมมตินี้ทีม SVN จะรวมกันอย่างต่อเนื่องบ่อยขึ้นและค้นพบปัญหาการรวมเร็วกว่าทีม git

นี่หมายความว่า DVCS นั้นไม่เหมาะสำหรับทีมต่อเนื่องมากกว่าเครื่องมือรวมศูนย์แบบเก่าหรือไม่ พวกคุณรู้ปัญหานี้ได้อย่างไร

ข้อจำกัดความรับผิดชอบ: ฉันทำงานให้กับ Atlassian

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

ตามเนื้อผ้ามีสองปัญหากับ DVCS และ CI:

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

ใน Bamboo เราแนะนำความสามารถในการสร้างเซิร์ฟเวอร์เพื่อตรวจจับสาขาใหม่ตามที่สร้างโดยนักพัฒนาและตั้งค่าการสร้างโดยอัตโนมัติตามการกำหนดค่าการสร้างสำหรับต้นแบบ (ดังนั้นถ้าคุณเปลี่ยนการกำหนดค่าการสร้างต้นแบบมันจะเปลี่ยนการกำหนดค่าสาขา เพื่อสะท้อนการเปลี่ยนแปลง)

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

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

ทีมเล็ก ๆ ของฉันเปลี่ยนเป็น DVCS เมื่อหนึ่งหรือสองปีก่อนและ บริษัท อื่น ๆ ของฉันก็ปฏิบัติตามเมื่อสองสามเดือนก่อน จากประสบการณ์ของฉัน:

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

เมื่อเร็ว ๆ นี้ฉันสังเกตเห็นโครงการประมาณ 19 โครงการที่ใช้ Mercurial over SubVersion (ฉันเป็นคนที่ถูกโค่นล้ม ): นักพัฒนาเริ่มที่จะกลายเป็นนักปัจเจกนิยมจริง ๆ โดยทำงานในสาขาของตัวเอง สิ่งนี้ทำให้เกิดปัญหาและข้อกังวลอย่างมากในการรวม

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

ดูเหมือนว่า Martin Fowler เขียนเกี่ยวกับมันบนเว็บไซต์ของเขา

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

นักพัฒนาซอฟต์แวร์ยังคงอยู่ในความดูแลโดยไม่คำนึงถึง VCS ที่ใช้

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

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

พูดว่าสำหรับ VCS แบบกระจายอย่าง Mercurial คุณสามารถค้นหาคำแนะนำที่แข็งแกร่งสำหรับการรวมบ่อย :

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

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

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

• ^{ฉันเคยเห็นการรวมที่เกิดขึ้นล่าช้าอย่างรุนแรง (สนับสนุนโดยการจัดการคนพิการ) กับ VCS จากส่วนกลางรวมถึงการผสานที่เกิดขึ้นกับ DVCS บ่อยครั้งเมื่อทีม / ผู้บริหารคิดว่ามันเป็นวิธีที่ถูกต้อง ฉันเคยเห็นว่าไม่มีใครใส่ใจถ้า VCS ถูกแจกจ่ายหรือรวมศูนย์ในการตัดสินใจไม่ทางใดก็ทางหนึ่ง}

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

VCS ที่เผยแพร่หรือไม่มีผลกระทบอย่างมากต่อเรื่องนั้น

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

ไม่เคยมีปัญหานี้กับ Git / Gitorious

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

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

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

การตั้งค่า Jenkins / Hudson เพื่อติดตามสาขาที่ใช้งานอยู่ทั้งหมดในที่เก็บ Git นั้นง่ายมากเช่นกัน เราได้รับแรงฉุดมากขึ้นด้วย CI และข้อเสนอแนะบ่อยขึ้นเกี่ยวกับสถานะของที่เก็บเมื่อเราย้ายไป Git จาก SVN

เซิร์ฟเวอร์บิลด์ราคาถูก เพียงแค่ให้เซิร์ฟเวอร์ CI ของคุณรับสาขาทั้งหมดที่คุณรู้จัก

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

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

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

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

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

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

ฉันว่า DVCS เอื้อต่อการรวมระบบอย่างต่อเนื่อง การควบรวมจะไม่เกิดการระคายเคืองกับพวกเขา มันต้องมีวินัยมากขึ้น คุณควรปฏิบัติตามคอมมิทท้องถิ่นด้วยการดึงจากฐานเพื่อรวมแล้วดันเมื่องานของคุณเสร็จสมบูรณ์ (ก่อนที่จะไปต่อไป)

เมื่อทีมของฉันเปลี่ยนไปใช้ Git เราได้กำหนดกระบวนการของเราไว้อย่างชัดเจนว่าการผลักดันนั้นจะต้องได้รับการปฏิบัติเหมือนกับการกระทำใน VCS ที่เก่ากว่าและความมุ่งมั่นในท้องถิ่นสามารถทำได้บ่อยครั้ง / ไม่บ่อยเท่าที่แต่ละคนเลือก ด้วยเหตุนี้จึงไม่มีความแตกต่างกับระบบ CI ไม่ว่าเราจะใช้ DVCS หรือ VCS ส่วนกลาง

คำตอบคือใช่และไม่ใช่

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

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

(และหากผู้ใช้ SVN ของคุณไม่ได้กระทำทุกคืนบอกให้พวกเขา - มันเป็นปัญหาเดียวกันแน่นอน)

Git ไม่ได้ป้องกันการรวมระบบอย่างต่อเนื่อง เวิร์กโฟลว์แบบอิงลำตัวของคุณคือ

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

ฉันยืนยันว่าเวิร์กโฟลว์ที่อิงตามสไตล์ Google นั้นต่อต้านการทำงานของ VCS เช่น Git ซึ่งการผสานนั้นง่าย นี่คือสิ่งที่ฉันต้องการให้คำแนะนำแทน:

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

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

มีวิธีแก้ไขปัญหาทางเทคนิคที่ยอดเยี่ยมอย่าง @jdunay ที่กล่าวถึง แต่สำหรับพวกเราแล้วมันเป็นปัญหาของคน - ในลักษณะเดียวกับที่ส่งเสริมสภาพแวดล้อมที่ผู้คนให้ความสนใจกับ svn บ่อยครั้งเป็นปัญหาของคน

สิ่งที่ใช้ได้ผลสำหรับเราคือ: (แทนที่ 'master' ด้วยสาขา dev ที่ใช้งานในปัจจุบัน)

1. การรวม / rebases บ่อยครั้งจากต้นแบบ
2. บ่อยครั้งพอที่จะผลักดันให้ต้นแบบ

3. การรับรู้ของสิ่งต่าง ๆ ที่ทำให้เกิดการรวมนรกเช่น refactorings บางอย่างและบรรเทาสิ่งนี้โดยการสื่อสาร ตัวอย่างเช่น:

   • ตรวจสอบให้แน่ใจว่าทุกคนดันก่อนอาหารกลางวัน
   • ดำเนินการและผลักดันการปรับโครงสร้างใหม่ในช่วงอาหารกลางวัน
   • ตรวจสอบให้แน่ใจว่าทุกคนดึงหลังอาหารกลางวัน