นักพัฒนาหยุดการคอมมิชชันที่ผิดสาขาบน DVCS

ปัญหา

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

ซึ่งส่งผลให้เวลาที่ใช้ในการสำรองการกระทำผิดหรือรหัส (อาจไม่ใช่ -QAd) การเข้าถึงและการปรับใช้ในสาขาที่ไม่ถูกต้องหากเราไม่สังเกตเห็นว่ารหัสผิดไป

สาขาและผสานการออกแบบ / วิธีการของเรา

               v1-test   v1-patch1   v1-patch2
               ^---------^-----------^                v1-prod
              /         / \           \
-----------------------/   \           \              v1-dev
              \             \           \
               --------------------------\            v2-dev
                             \       \    \ 
                              ^-------^-------------  v2-prod
                              v2-test v2-patch1      

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

สิ่งที่มีแนวโน้มจะเกิดขึ้นก็คือนักพัฒนาซอฟต์แวร์จะต้องทำงานเนื่องจากสาขา v2-dev เป็น v1-dev หรือ v1-prod หรือแย่กว่านั้นพวกเขารวม v2-dev เข้ากับ v1-prod (หรือข้อผิดพลาดที่คล้ายกัน)

เราบอกนักพัฒนาซอฟต์แวร์ส่วนใหญ่ว่าไม่ควรเข้าถึงสาขา-prodแต่รหัสยังแอบย่องเข้ามากลุ่มนักพัฒนาอาวุโสอีกหลายคนคอยดูแลสาขา -prod

ควรสังเกตว่าในขณะที่ v2 เพิ่งเริ่มพัฒนาอาจยังมีบางส่วนที่ค่อนข้างหนักไปสู่ ​​v1 เพื่อแก้ไขปัญหา Ie v1 อาจไม่เพียง แต่ได้รับแพตช์เล็ก ๆ แปลก ๆ

สิ่งที่เราได้ลองมาแล้ว

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

สาเหตุที่เป็นไปได้ที่ฉันเห็นสำหรับนักพัฒนาที่ยอมรับผิดสาขา

• ซับซ้อนเกินไปการออกแบบสาขา
• มีการพัฒนาเชิงรุกในหลายสาขาพร้อมกัน (โครงการจะแสดงอาการของการใช้แบบจำลองหิมะถล่ม )
• นักพัฒนาไม่เข้าใจ DVCS ดีพอ

คำถามที่ฉันอ่านซึ่งค่อนข้างเกี่ยวข้อง

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

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

คำถาม

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

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

ปัญหาคือคุณกำลังเปลี่ยนสิ่งที่ความหมายของสาขาเป็นส่วนหนึ่งของกระบวนการ

เริ่มแรกv1 devสาขาเพื่อการพัฒนา คุณสมบัติใหม่ทั้งหมดไปที่นั่น ในบางจุดในอนาคตมันจะกลายเป็นสาขาการบำรุงรักษาสำหรับv1 releaseสาขา นี่คือปมของปัญหา

ไม่ใช่ว่านักพัฒนาจะเลอะเทอะ แต่การอนุญาตและบทบาทของสาขานั้นไม่เป็นระเบียบและอาจมีการเปลี่ยนแปลง

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

ตัวอย่างเช่น:

 developer
  commits    |   |  |   |    |     |   |     |
             v   v  v   v    v     v   v     v
 dev  +--+---------------------+------------------->
         |           ^    ^    |           ^    ^
         |           |    |    |           |    |
 v1      +----+------+----+    |           |    |
           prod  patches       |           |    |
                               |           |    |
                               |           |    |
 v2                            +-----+-----+----+
                                  prod  patches

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

บทความหนึ่งที่คุณควรอ่าน (และอาจเป็นเพราะการพูดถึง 'ควร') คือกลยุทธ์การแยกทาง SCM ขั้นสูงโดยสตีเฟ่นแวนซ์

^{ในบทความนี้ฉันแรกกำหนดสาขาในความหมายทั่วไป จากนั้นฉันจะหารือกลวิธีต่าง ๆ สำหรับการแตกแขนงเริ่มต้นด้วยสิ่งที่ชัดเจนและขยับไปสู่หลายวิธีที่เหมาะสมกว่าสำหรับความพยายามในการพัฒนาที่ใหญ่กว่า ระหว่างทางฉันพูดถึงข้อดีข้อเสียของแต่ละกลยุทธ์ใช้พวกเขาเพื่อกระตุ้นการเปลี่ยนแปลงที่ประกอบด้วยกลยุทธ์ที่ซับซ้อนมากขึ้น ...}

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

บทบาทเหล่านี้คือ:

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

ในตัวอย่างของคุณคุณมีการฉีดแบบเรียงซ้อน (นี่เป็นปัญหา - ทำให้การผสานยากขึ้น - จะเกิดอะไรขึ้นถ้าคุณต้องการผสานการแก้ไขสำหรับ v1 เข้ากับ v2 และ v3?) สาขา dev ที่กลายเป็นสาขาการบำรุงรักษา ( การเปลี่ยนแปลงนโยบายนี่เป็นปัญหา)

ตกลงคุณพูดได้ว่าเยี่ยมมาก แต่นี่ถูกเขียนขึ้นเพื่อความจำเป็นซึ่งเป็น VCS ส่วนกลาง - ฉันกำลังใช้ DVCS

ให้ดูที่โมเดล git-flowและดูว่ามันใช้งานอย่างไร

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

ในขณะที่นโยบายบทบาทไม่ตรงกันทั้งหมด (แต่ละผลิตภัณฑ์มีวงจรชีวิตที่แตกต่างกันเล็กน้อย) แต่เป็นนโยบายที่ตรงกัน

การทำเช่นนี้ควรทำให้นโยบายการแยกสาขาของคุณง่ายขึ้นและทำให้ทุกคนที่เกี่ยวข้องง่ายขึ้น

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

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

และตามกฎทั่วไปให้ใช้มีดโกนของ Occam: โครงสร้าง repo ทั้งหมดควรง่ายที่สุดเท่าที่จะทำได้

ดูความเห็นของฌอนด้วย

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

ฉันขอแนะนำให้คุณมีปัญหากับความจริงที่ว่าทุกคนทำงานในสาขาเหล่านี้เป็นประจำ

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

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

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

เครื่องมือไม่ดีพอที่จะเลือกการเปลี่ยนแปลงที่จะต้องคัดลอกไปยังสาขาอื่นและเมื่อต้องเกิดขึ้น Git-flow พยายามที่จะแก้ปัญหานี้โดยการสร้างกลยุทธ์การแยกสาขาซึ่งหมายความว่าเมื่อมีการรวมสาขาแล้วการเปลี่ยนแปลงทั้งหมดจะถูกรวมเข้าด้วยกัน

ในพื้นที่เก็บข้อมูลเดียวที่นักพัฒนาทั้งหมดกำลังทำงานในหนึ่งโครงการที่มีเธรดการปล่อยเดี่ยว git flow แก้ปัญหาได้ แต่ชีวิตนั้นไม่ง่ายสำหรับหลาย ๆ บริษัท

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

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

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

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