มาพร้อมกับกลยุทธ์การควบคุมเวอร์ชันสำหรับ SVN


9

นอกเวลาฉันจะพยายามหากลยุทธ์ในการควบคุมเวอร์ชันสำหรับ บริษัท ของฉัน ปัจจุบันเราใช้ SVN แต่ไม่มีโครงสร้าง - โดยพื้นฐานแล้วเรามีลำตัวและมุ่งมั่นเท่านั้น เมื่อเร็ว ๆ นี้ผู้จัดการฝ่ายพัฒนาเริ่มต้นพื้นที่เก็บข้อมูลที่สองซึ่งทำหน้าที่เป็น "แท็ก" ของเรา แต่จะต้องรวมเข้ากับ "ลำต้น" ด้วยตนเองเนื่องจากไม่ได้เป็นส่วนหนึ่งของพื้นที่เก็บข้อมูลเดียวกัน แต่แยกต่างหากโดยสิ้นเชิง ในความเป็นจริงมีเพียงโฟลเดอร์เดียวที่เรียกว่า "Dev" (จริง ๆ แล้วมีโฟลเดอร์ "Dev" ที่แตกต่างกันตามวันที่ที่แตกต่างกัน แต่เพียงแค่ "Dev" เป็นโฟลเดอร์หลัก) และภายใต้นั้นเป็นทุกอย่างอื่น โครงการอื่น ๆ ทั้งหมด มันไม่ได้จัดโดยโปรเจคเลยมันไม่มีคอนเซ็ปต์ของ branch / tag / trunk หรืออะไรเลย คนที่ตั้งขึ้นครั้งแรก (หายไปนาน แน่นอน) ดูเหมือนจะไม่รู้วิธีตั้งค่า SVN เลยและตั้งแต่นั้นมาก็ไม่มีใครใส่ใจที่จะเรียนรู้วิธีการทำสิ่งต่าง ๆ อย่างถูกต้องเพราะกลัวว่าจะทำลายบางสิ่งบางอย่าง เราไม่ใช้ CI ใด ๆ (หรือการทดสอบอัตโนมัติโชคไม่ดี)

ก่อนอื่นเราควรแยกมันเป็นโครงการหรือไม่ ตัวอย่างเช่นเรามี: เว็บไซต์ ASP.NET สองแห่ง (ไม่ใช่เว็บแอปพลิเคชั่น, เว็บไซต์), บริการเว็บ, โฟลเดอร์การปรับใช้สำหรับสคริปต์ตารางทั้งหมดและขั้นตอนการจัดเก็บ, ไคลเอนต์บรรทัดคำสั่งสองรายการสำหรับโครงการภายนอกที่เรียกโดย เว็บไซต์และโฟลเดอร์ที่ใช้ร่วมกันที่มีวัตถุทางธุรกิจทั่วไปและสิ่งที่คล้ายกัน หากสิ่งเหล่านี้เป็นโครงการของตัวเองโดยมีการติดตั้ง branch / tag / trunk หรือควรเป็นดังนี้:

dev/
  branches/
  tags/
  trunk/
      Site1/
      Site2/
      WebService/
      SharedCode/

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

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


5
นอกกรอบกลยุทธ์: เปลี่ยนเป็นคอมไพล์
Rein Henrichs

หากเป็นตัวเลือกฉันจะทำ (หรือ Mercurial เนื่องจากเราเป็นร้านค้าของ Windows) ฉันคิดว่าฉันต้องเผชิญกับการต่อต้านมากขึ้นพยายามที่จะย้ายไปยังระบบควบคุมแหล่งใหม่ทั้งหมดกว่าพยายามอย่างน้อยก็จะสร้างสภาพแวดล้อมที่เหมาะสมให้กับ SVN
Wayne Molina

2
แม้ว่าฉันจะตื่นเต้นกับ DVCS แต่การโค่นล้มเป็นเครื่องมือที่ดี CVS หรือโซลูชันอื่นที่ไม่มีเวอร์ชันโฟลเดอร์จะแย่กว่านั้น
Matthew Rodatus

2
@Wayne M - คุณอาจพบว่าเป็นวิธีอื่น ๆ มันอาจจะง่ายกว่าที่จะให้ผู้คนลงชื่อสมัครใช้โครงสร้างสภาพแวดล้อมที่เหมาะสมหากทำเช่นนั้นจะทำให้พวกเขาได้รับประโยชน์ทั้งหมดจากการใช้ DVCS ในช่วงการเปลี่ยนภาพคุณอาจต้องการรับ peopel เพื่อลองใช้การเข้าถึงสาขา / repo ในพื้นที่โดยใช้ gitsvn หรือ hgsubversion เมื่อพวกเขาติดยาเสพติดและคุ้นเคยกับเครื่องมืออาจมีความปรารถนาที่จะย้ายกลุ่มไปยัง DVCS สำหรับกลุ่มลูกค้าหลัก
Mark Booth

คำตอบ:


5

หากคุณต้องการกระบวนการบิลด์แบบรวมต้องแน่ใจว่าได้ใส่ branch / tags / trunk ที่ root เช่นนี้

branches/
tags/
trunk/
  dev/
    ...

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

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

branches/
  dev/
    Site1/
    Site2/
    WebService/
    SharedCode/
tags/
  release1/
    Site1/
    Site2/
    WebService/
    SharedCode/
trunk/
  Site1/
  Site2/
  WebService/
  SharedCode/

1
บิลด์แบบรวมมีข้อดีเช่นกำจัดความต้องการเผยแพร่คอมโพเนนต์ที่ใช้ร่วมกันระหว่างโครงการซึ่งเป็นส่วนหนึ่งของบิลด์
Matthew Rodatus

2
หากคุณต้องการการสร้างแบบรวมหลายรายการให้สร้างไดเรกทอรีภายใต้ trunk สำหรับแต่ละรายการ แต่ฉันจะไม่ตั้งชื่อ "dev" หนึ่งคน - นั่นสำเร็จได้ดีกว่ากับสาขา ตัวอย่างเช่นคุณอาจมีสององค์กร dev หลัก - องค์กรหนึ่งที่ทำงานบนไดรเวอร์อุปกรณ์และองค์กรหนึ่งที่ทำงานบนเว็บไซต์ของ บริษัท คุณอาจต้องการให้มีการสร้างแบบรวมสองแยกต่างหาก
Matthew Rodatus

1
  1. ตราบใดที่โครงสร้างโค้ดใน svn มีความเป็นส่วนตัวมาก

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

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

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

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


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

0

ต่อไปนี้เป็นวิธีที่ดีที่สุดในการจัดวางพื้นที่เก็บข้อมูลการโค่นล้ม

project_a
     - branches
     - tags
     - trunk
project_b
     - branches
     - tags
     - trunk
project_c
     - branches
     - tags
     - trunk
master
     - branches
     - tags
     - trunk       
         - svn:external project_a
         - svn:external project_b
         - svn:external project_c

วิธีนี้คุณสามารถตรวจสอบแต่ละโครงการด้วยตนเอง

หากคุณต้องการที่จะตรวจสอบทั้งหมด 3 โครงการและจะสร้างแบบครบวงจรกับบางเสาหินสร้างสคริปต์ / ระบบตรวจสอบแล้วโดยใช้ต้นแบบโมดูลกับSVN: externalsทำแผนที่ทุกโครงการอื่น ๆ เข้าไปในต้นแบบ trunk

นี่เป็นเรื่องที่ซับซ้อนมากขึ้นในแวบแรก แต่มันเป็นวิธีที่บำรุงรักษาได้และสำนวนที่สุดในการแก้ปัญหานี้ด้วยการโค่นล้ม


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