การควบคุมแหล่งที่มา: บทบาทและความรับผิดชอบ

10

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

ให้ฉันอธิบายสิ่งที่ฉันกำลังเผชิญ ฉันเป็นผู้พัฒนานำ (เจ้าของ) ของแอปพลิเคชันเฉพาะ บริษัท ของเราเพิ่งย้ายจาก VSS (ที่ฉันเป็นผู้ดูแลระบบฐานข้อมูล VSS ที่เก็บใบสมัครของฉัน) เป็น TFS (ที่ฉันมีสิทธิ์ในสาขาการพัฒนาที่สร้างขึ้นโดยทีม "การดำเนินงาน" ของเรา) ในงานก่อนหน้านี้ฉันเป็นผู้ดูแลระบบ TFS ดังนั้นฉันรู้วิธีของฉันเกี่ยวกับ TFS และ MSBuild

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

ฉันไม่สามารถสร้างสาขาของตัวเอง ฉันต้องสร้างงาน TFS เพื่อให้สมาชิกในทีม "ปฏิบัติการ" สร้างสาขาให้ฉัน
ฉันไม่สามารถผสานจากหลักไปยังสาขาการพัฒนาของฉัน ฉันต้องสร้างงาน TFS เพื่อให้สมาชิกในทีม "การดำเนินการ" ทำการผสานและหวังว่าเขาจะไม่ "ก้าวเข้าสู่" การเปลี่ยนแปลงใด ๆ ในทีมของฉันตั้งแต่ "ops guy" อาจหรืออาจไม่ใช่นักพัฒนาและแน่นอนมี ไม่มีความรู้เกี่ยวกับรหัสที่เขารวมเข้าด้วยกัน
ฉันไม่สามารถผสานจากการพัฒนาไปยังหน้าหลักได้ ฉันต้องสร้างงาน TFS อีกครั้งเพื่อให้ "ops guy" ทำการผสานโดยหวังว่าเขาจะทำอย่างถูกต้อง จากนั้นฉันต้องสร้างงาน TFS อื่นเพื่อรวมกลับไปที่สาขาของฉันเพื่อให้ฉันสามารถแก้ไขปัญหาใด ๆ ที่เกิดขึ้นได้โดยการรวมที่ไม่ใช่ผู้พัฒนาไปยังหน้าหลัก
ฉันไม่สามารถสร้างหรือแก้ไขสคริปต์ MSBuild ฉันต้องทำงานกับทีม "ops" อีกครั้งซึ่งเป็นเรื่องใหม่สำหรับ MSBuild ดังนั้นจึงสามารถสร้างงานพื้นฐานได้เท่านั้น (ลืมเกี่ยวกับสิ่งที่ซับซ้อนหรือสวรรค์ห้ามงานที่กำหนดเอง)
ฉันไม่สามารถเรียกใช้งานสคริปต์ MSBuild มีเพียงทีม "ops" เท่านั้นที่สามารถทำได้
ไปด้านบนปิดทั้งหมดนี้มักจะเป็นทรัพยากร "นอกชายฝั่ง" ซึ่งดำเนินการงานที่ร้องขอดังนั้นแม้ว่าฉันจะสร้างงานไปที่ (สาขา / ผสาน / สร้าง) ในตอนเช้าก็อาจจะไม่เสร็จ จนถึงค่ำวันนั้น

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

ความเห็นของฉันคือว่าผู้นำทางด้านเทคนิค (เช่นฉัน) ควรรับผิดชอบในการบำรุงรักษาลำต้น ("หลัก") และการรวมเข้ากับ / จากสาขาการพัฒนา หัวหน้าทีมควรมีความสามารถในการสร้างสคริปต์ MS Build เพื่อสร้างและปรับใช้กับสภาพแวดล้อมการทดสอบการรวมระบบ

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

version-control team-foundation-server branching

— Michael Chatfield
แหล่งที่มา

WHO should be performing said branching/merging.เป็นการตัดสินใจขององค์กรภายใน ไม่ใช่บางอย่างที่เราสามารถช่วยคุณได้ ...

— yannis

2

อยากบอกเหตุผลที่บอกเล่าสำหรับขั้นตอนไบเซนไทน์ดังกล่าวหรือไม่? ฉันเดาว่า "การปฏิบัติตาม CMM ระดับ N" หรือ "Sarbanes Oxley"

— Bruce Ediger

SOX แต่เพียงบางส่วน เมื่อเราไป TFS ครั้งแรกนักพัฒนาสามารถเข้าถึง Main และ Dev แต่จากนั้นผู้พัฒนา "บางคน" (ไม่มีในทีมของฉัน) ตัดสินใจที่จะทำงานพัฒนาบน Main ไม่ใช่ใน Dev Dev ดังนั้นตอนนี้ทุกทีมจะถูกลงโทษ

— Michael Chatfield

8

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

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

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

b) ทำความรู้จักกับ Ops - อาจมีเหตุผลสำหรับนโยบายนี้ บางทีการให้เหตุผลอาจแก้ไขได้ในลักษณะที่มีประสิทธิภาพมากกว่า

หวังว่านี่จะช่วยได้

— ไวแอตต์บาร์เน็ตต์
แหล่งที่มา

3

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

— เจมี่ F

ฉันวางแผนที่จะมีการประชุมดังกล่าว แต่มันจะช่วยถ้าฉันสามารถแสดงนโยบายนี้ขัดกับ "แนวปฏิบัติที่ดีที่สุด" ของอุตสาหกรรม

— Michael Chatfield

Gotcha ไม่แน่ใจว่ามีอะไรเฉพาะในนั้นหรือไม่ แต่บิตบนตัวควบคุมแหล่งข้อมูลใน The Pragmatic Programmer อาจมีอัญมณีอยู่บ้าง จากสิ่งที่ดูเหมือนว่าเป็นการตอบสนองขั้นต้นต่อผู้พัฒนาที่ไม่ดีบางคนแทนที่จะตัดสินใจออกนโยบายหรือการเมือง ฉันจะตัดสินข้อตกลงที่ Ops เป็นเจ้าของรวมเข้ากับ Main ฉันยังต้องผลักดันให้ ops รับผิดชอบในการทำให้แน่ใจว่าการผสานไม่ทำลายอะไรเลยซึ่งอาจจบลงด้วยการที่พวกเขาออกไป . .

— ไวแอตต์บาร์เน็ตต์

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

— softveda

2

วิธีปฏิบัติที่ฉันเคยเห็นคือ:

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

— Jan Hudec
แหล่งที่มา

ฉันจะเป็น "ผู้รวมระบบที่กำหนด" ทั้งหมดตราบใดที่มันเป็นนักพัฒนาในทีม นั่นคือเส้นทางที่ฉันหวังไว้ มันเป็นทีมเล็ก ๆ (4 คนรวมถึงตัวเองด้วย) หวังว่าฉันจะสามารถเข้าถึงเพื่อสร้าง / ดำเนินการสคริปต์ MS Build ได้เช่นกันฉันจะสร้างสคริปต์ nAnt สำหรับการปรับใช้เพื่อการพัฒนาและจากนั้นสำหรับทีม "ops" เพื่อสร้างสคริปต์เดียวกันสำหรับ MSBuild แต่นั่นคือสิ่งที่ฉันจะทำถ้าต้องการ

— Michael Chatfield

2

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

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

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

และอย่าคาดคั้นมากเกินไป - เท่าที่คุณต้องการรู้ว่าทำไมข้อ จำกัด ถึงเกิดขึ้นเหตุผลคืออะไร ...

— Murph
แหล่งที่มา

1

ใช่พยายามอย่างหนักที่จะไม่เผชิญหน้า ... มาจากผู้ชายที่ภรรยาซื้อเขามา "ฉันเห็นด้วยกับคุณ แต่แล้วเราทั้งคู่ก็ผิด" T-Shirt :)

— Michael Chatfield

มันเป็นนักฆ่าที่สมบูรณ์แบบเมื่อคุณพูดถูก (-: และในกรณีนี้มันยากที่จะเถียงว่าคุณไม่ได้ ... แต่คุณต้องมีการจัดการสายงานของคุณด้านข้างถ้ามีอะไรจะเปลี่ยนแปลง

— Murph

การควบคุมแหล่งที่มา: บทบาทและความรับผิดชอบ - แนวทางปฏิบัติที่ดีที่สุด