วิธีที่ดีที่สุด: ปรับโครงสร้างโซลูชัน Team Foundation Server (TFS) ที่มีอยู่


12

ในแผนกของฉันเรากำลังพัฒนา AddOns ที่เล็กกว่าหลายตัวสำหรับเซิร์ฟเวอร์การสื่อสารแบบรวม สำหรับการกำหนดเวอร์ชันและการพัฒนาแบบกระจายเราใช้ Team Foundation Server 2012

แต่: มีโซลูชัน TFS ขนาดใหญ่เพียงรายการเดียวสำหรับแอปพลิเคชันและห้องสมุดทั้งหมดของเรา:

  • ทางออกหลัก
    • การประยุกต์ใช้งาน
      • แอพ 1
      • แอพ 2
      • แอพ 3
    • externals
    • ห้องสมุด
      • Lib 1
      • Lib 2
    • เครื่องมือ

เส้นทาง "แอปพลิเคชัน" มีแอปพลิเคชันหลักทั้งหมด สิ่งเหล่านี้ไม่ได้ขึ้นอยู่กับแต่ละอื่น ๆ แต่ขึ้นอยู่กับโครงการห้องสมุดและภายนอก

เส้นทาง "Externals" ประกอบด้วย DLLs ภายนอกบางตัวที่อ้างอิงใน Applications and Libraries ของเรา

เส้นทาง Libraries มี libs ที่ใช้กันทั่วไป (เทมเพลต UI, คลาส Helper และอื่น ๆ ) พวกเขาไม่ได้พึ่งพาซึ่งกันและกันและพวกเขาจะถูกอ้างอิงในโครงการห้องสมุดและเครื่องมือ

เส้นทางเครื่องมือประกอบด้วยโปรแกรมตัวช่วยบางอย่างเช่นตัวช่วยตั้งค่าอัปเดตบริการทางเว็บ ฯลฯ

ตอนนี้มีประเด็นสำคัญอยู่ว่าทำไมฉันถึงต้องการเปลี่ยนแปลงโครงสร้างนี้:

  • เราไม่สามารถใช้การสร้างเซิร์ฟเวอร์
  • มันไม่สะดวกในการจัดการการจัดการการต่อสู้ TFS ด้วย sprints, impediments ฯลฯ ด้วยโครงสร้างโซลูชันเช่นนั้น
  • นักพัฒนาทุกคนสามารถเข้าถึงโครงการทั้งหมดในโซลูชันได้เสมอ
  • งานสร้างที่สมบูรณ์นั้นใช้เวลานานเกินไปหากมีคนพบ [F6] ใน Visual Studio โดยไม่ตั้งใจ ...

คุณจะเปลี่ยนแปลงอะไรในโซลูชันนี้ คุณจะแบ่งโครงการเหล่านั้นเป็นโซลูชั่นที่มีขนาดเล็กลงได้อย่างไร

แนวทางแรกของฉันคือการสร้างโครงการ TFS หนึ่งโครงการสำหรับแต่ละแอพพลิเคชันห้องสมุดและเครื่องมือ แต่ฉันจะมั่นใจได้อย่างไรเช่นแอปที่ 2 มี Lib 1 รุ่นใหม่ล่าสุดอยู่เสมอ? ฉันต้องตรวจสอบการเปลี่ยนแปลงใน Lib 1 และอัปเดตแอป 2 ด้วยตนเองทันทีที่การเปลี่ยนแปลง Lib หรือไม่ หรือฉันสามารถบังคับให้ Visual Studio ใช้โครงการภายนอกรุ่นใหม่ล่าสุดได้หรือไม่

แก้ไข:บน TFS มีเพียงหนึ่งคอลเล็กชันโครงการ TFS ทีมซึ่งมีหนึ่งโครงการทีม TFS โครงการทีมประกอบด้วยโซลูชัน Visual Studio ขนาดใหญ่หนึ่งรายการซึ่งมีหลายโฟลเดอร์ที่มี (ดูโครงสร้างด้านบน) โดยแต่ละโครงการมีโครงการ VS หลายโครงการ

คำถามของฉันคือตอนนี้คุณจะจัดระเบียบใหม่ได้อย่างไร:

  1. โครงการทีม TFS
  2. โครงการ VS

1
เมื่อคุณพูดว่า "โซลูชัน TFS ขนาดใหญ่" คุณกำลังพูดถึงคอลเล็กชันโครงการ TFS ทีมหรือโครงการทีม TFS หรือโซลูชัน Visual Studio หรือไม่
Zugbo

ดังที่ Zugbo กล่าวฉันคิดว่าคุณต้องได้คำศัพท์ที่ถูกต้องก่อนที่ทุกคนจะสามารถช่วยตอบคำถามนี้ได้เนื่องจากคุณดูเหมือนจะผสมโครงการทีม TFS กับโซลูชัน Visual Studio คุณสามารถมีโครงการของทีมเดียวที่มีโซลูชันหลากหลาย
Tom Robinson

ขออภัยที่ให้รายละเอียดน้อยเกินไป ฉันจะแก้ไขคำถามเริ่มต้น
dhh

คำตอบ:


11

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

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

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

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

หากคุณมีไลบรารีภายในที่ใช้ร่วมกันให้สร้างแพ็คเกจ NuGet สำหรับพวกเขาและสร้างโซลูชัน vs เพียงแค่บรรจุไลบรารีนั้น เพิ่มคำสั่ง post build เพื่อสร้างแพ็กเกจ nuget หรือขยายเท็มเพลต tfs build ของคุณเพื่อทำ (มีเทมเพลตจำนวนมากที่ทำสิ่งนี้อยู่แล้ว)


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