การแตกกิ่งแยกการบูรณาการอย่างต่อเนื่อง?


18

ฉันคิดว่าบทความนี้เป็นโมเดลการแยกสาขาที่ประสบความสำเร็จเป็นที่รู้จักกันดีในหมู่ผู้ใช้ DVCS ที่มีประสบการณ์

ฉันใช้hgเป็นส่วนใหญ่ แต่ฉันจะโต้แย้งการอภิปรายนี้เป็นสิ่งที่ดีสำหรับ DVCS ใด ๆ

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

ดังนั้นเราจึงต้องการติดตั้งเซิร์ฟเวอร์ CI เช่น Jenkins และปรับปรุงขั้นตอนการทำงานของเราด้วยระบบการจัดเตรียมในอนาคต

ส่วนจริง

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

Say Alice และ Bob กำลังทำงานกับคุณสมบัติสองอย่าง แต่อลิซเสร็จในวันรุ่งขึ้น คุณสมบัติของ Bob ใช้เวลาหนึ่งสัปดาห์ เมื่อถึงเวลาที่บ๊อบเสร็จสิ้นการเปลี่ยนแปลงของเขาล้าสมัย (อาจจะมีการปรับโครงสร้างใหม่ / เปลี่ยนชื่อคลาสบางส่วน)

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

  1. นี่เป็นวิธีที่ดีหรือไม่?
  2. ควรสาขาเหล่านี้มีอยู่ใน repo หลัก (ไม่ใช่โคลนแบบโลคอลหรือไม่) ความหมายของนักพัฒนาทุกคนควรให้สิทธิพิเศษแก่ repo หลักใน GitHub / Bitbucket เพื่อให้สามารถสร้างสาขาใหม่ได้หรือไม่ หรือสิ่งนี้ทำในท้องถิ่น?
  3. สุดท้ายนำเสนอรูปแบบโดยบทความควรแบ่ง CI origin/masterถ้าสาขาไม่ได้ซิงค์กับ เนื่องจากเราต้องการสร้างงานทุกคืนผู้พัฒนาควรดึงและผสานก่อนที่จะออกจากงานและให้ CI ทำงานในแต่ละสาขาของฟีเจอร์เช่นกัน

คำตอบ:


12

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

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

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

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

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


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

1
ที่จริงแล้วฉันคิดว่าเราต้องการสาขา "ส่วนกลาง" สองสาขา - สาขาหนึ่งเป็นสาขา"throwaway_integration"ที่มีอยู่อย่างหมดจดเป็นการตรวจสอบผสานและทดสอบอย่างรวดเร็วสำหรับคุณลักษณะที่อยู่ภายใต้การพัฒนาและสาขา "ต้นแบบ" หรือสาขา "เสถียร" อื่น ๆ มีคุณสมบัติหลังจากถึงระดับเสถียรภาพ / วุฒิภาวะที่แน่นอน นักพัฒนาดึงโค้ดที่เสถียรเพื่อทำงานต่อจากสาขา "เสถียร" / "มาสเตอร์" ที่สองและผสาน & ดันการเปลี่ยนแปลงบ่อยครั้งในสาขา "ไม่เสถียร" / "throwaway_integration" ครั้งแรก การทดสอบ CI ควรทำงานทั้งสองสาขาแน่นอน
William Payne

@ WilliamPayne: ฉันเชื่อว่าสาขาที่ "ไม่มั่นคง" มักจะถูกเรียกว่า "กำลังพัฒนา"
Bart van Ingen Schenau

5

ในการตอบสนองต่อ 1)

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

2)

ส่วนใหญ่สาขาจะถูกสร้างขึ้นใน Mercurial โดยการโคลนที่เก็บดังนั้นคุณไม่จำเป็นต้องให้สิทธิ์นักพัฒนาทุกคนมอบสิทธิพิเศษให้กับ repo หลัก อย่างไรก็ตามคุณอาจต้องการให้นักพัฒนาสามารถสร้าง repos ที่โคลนบนเซิร์ฟเวอร์รวมอย่างต่อเนื่องเนื่องจากไม่สามารถทำการทดสอบในเครื่องได้ (ฉันเคยมีระบบ CI ซึ่งการทดสอบหน่วยใช้เวลา 8 ชั่วโมงในการรันบน 128 คอร์หลัก) - ไม่จำเป็นต้องบอกว่านักพัฒนาไม่สามารถไม่สามารถทำการทดสอบในพื้นที่ได้

3)

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


1
"ส่วนใหญ่สาขาถูกสร้างขึ้นใน Mercurial โดยการโคลนที่เก็บ" - นี่อาจเป็นจริงในปี 2013 แต่ทุกวันนี้ที่คั่นหนังสือของ Mercurial นั้นมีหน้าที่เทียบเท่ากับสาขาของ Git ทั้งหมดยกเว้นชื่อ
เควิน

@ เควิน: คุณมีสิทธิ์มากที่สุด ฉันใช้ git (เกือบ) โดยเฉพาะตั้งแต่ ก.พ. '13 - ประมาณหนึ่งเดือนหลังจากที่ฉันเขียนคำตอบข้างต้น ... ดังนั้นฉันจึงไม่ได้รับข้อมูลล่าสุดเกี่ยวกับการเปลี่ยนแปลงที่เกิดขึ้นกับ Mercurial ตั้งแต่นั้นมา
William Payne

1

นี่คือวิธีที่คุณสามารถทำได้: ฟีเจอร์การแตกแขนง

  1. สำหรับงานใหม่ใด ๆ (แก้ไขข้อผิดพลาดคุณสมบัติ ฯลฯ ) เริ่มสาขาใหม่ (เช่น bugfix-ticket123-the_thingie_breaks)
  2. ในขณะที่คุณทำงานปรับปรุงอย่างต่อเนื่องและเริ่มต้นการผสาน (หรือหลักในการคอมไพล์) เข้ามาในสาขาคุณลักษณะของคุณ สิ่งนี้จะช่วยให้คุณอัปเดตสาขาโดยไม่ต้องทำงานในสาขาเริ่มต้น
  3. เมื่อคุณสมบัติของคุณพร้อมและหน่วยทดสอบของคุณผ่านแล้วดึงและผสานค่าเริ่มต้นในสาขาของคุณอีกครั้งปิดสาขาของคุณและผลักดันโดยไม่รวมผสานผู้รวบรวมของคุณจะสังเกตเห็นหัวใหม่และเป็นสาขาที่ปิดดังนั้นเขา / เธอ จะดูแลการบูรณาการมัน ถ้าคุณไม่มีบูรณาการสลับไปเริ่มต้นและผสานสาขาคุณลักษณะของคุณให้เป็นค่าเริ่มต้น

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

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


คุณผสมและแทนที่สิ่งที่เป็นฉากตั้ง 0 ผสานความขัดแย้ง! = 0 การทดสอบหน่วยผิดพลาดผสานสำเร็จ! = รหัสสำเร็จ
Lazy Badger

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