คำถามติดแท็ก team-foundation-server

อัพเดท ฉันทำงานกับทีม devs เล็ก ๆ 4 คน พวกเขามีการควบคุมแหล่งที่ใช้ทั้งหมด ส่วนใหญ่ไม่สามารถควบคุมแหล่งที่มาและเลือกที่จะไม่ใช้แทน ฉันเชื่อมั่นอย่างยิ่งว่าการควบคุมแหล่งข้อมูลเป็นส่วนที่จำเป็นในการพัฒนาวิชาชีพ ปัญหาต่าง ๆ ทำให้ยากต่อการโน้มน้าวใจให้ใช้ตัวควบคุมแหล่งที่มา: ทีมที่ไม่ได้ใช้ในการใช้TFS ฉันมีการฝึกอบรม 2 ครั้ง แต่ได้รับการจัดสรรเพียง 1 ชั่วโมงเท่านั้นซึ่งไม่เพียงพอ สมาชิกในทีมปรับเปลี่ยนรหัสบนเซิร์ฟเวอร์โดยตรง สิ่งนี้จะทำให้รหัสไม่ซิงค์กัน ต้องการการเปรียบเทียบเพื่อให้แน่ใจว่าคุณกำลังทำงานกับรหัสล่าสุด และปัญหาการรวมที่ซับซ้อนเกิดขึ้น การประเมินเวลาที่นักพัฒนาซอฟต์แวร์นำเสนอไม่รวมเวลาที่ต้องใช้ในการแก้ไขปัญหาเหล่านี้ ดังนั้นถ้าฉันบอกว่าไม่ใช่จะใช้เวลานานกว่า 10 เท่า ... ฉันต้องอธิบายปัญหาเหล่านี้อย่างต่อเนื่องและเสี่ยงตัวเองเพราะตอนนี้ผู้บริหารอาจมองฉันว่า "ช้า" ฟิสิคัลไฟล์บนเซิร์ฟเวอร์แตกต่างกันในวิธีที่ไม่รู้จักมากกว่า ~ 100 ไฟล์ การผสานต้องการความรู้เกี่ยวกับโครงการในมือและดังนั้นความร่วมมือของนักพัฒนาซอฟต์แวร์ซึ่งฉันไม่สามารถทำได้ โครงการอื่น ๆ หลุดออกจากกัน นักพัฒนายังคงมีความไม่ไว้วางใจในการควบคุมแหล่งที่มาและทำให้เกิดปัญหาโดยไม่ได้ใช้ตัวควบคุมแหล่งที่มา นักพัฒนาให้เหตุผลว่าการใช้การควบคุมแหล่งที่มานั้นสิ้นเปลืองเพราะการผสานนั้นเกิดข้อผิดพลาดได้ง่ายและยาก นี่เป็นจุดที่ยากที่จะโต้แย้งเนื่องจากเมื่อการควบคุมแหล่งที่มานั้นไม่ถูกต้องใช้อย่างไม่ถูกต้องและการควบคุมแหล่งที่มาข้ามอย่างต่อเนื่องมันเป็นข้อผิดพลาดได้ง่ายแน่นอน ดังนั้นหลักฐาน "พูดเพื่อตัวเอง" ในมุมมองของพวกเขา นักพัฒนายืนยันว่าการปรับเปลี่ยนรหัสเซิร์ฟเวอร์โดยตรงการเลี่ยง TFS จะช่วยประหยัดเวลา นี่เป็นเรื่องยากที่จะโต้แย้ง เนื่องจากการรวมที่จำเป็นในการซิงโครไนซ์รหัสที่จะเริ่มต้นนั้นใช้เวลานาน …

62 version-control  teamwork  team-foundation-server  cowboy-coding 

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

53 code-quality  source-code  team-foundation-server 

ทีมของฉันใช้ Team Foundation Server สำหรับการควบคุมแหล่งที่มาและวันนี้ฉันแก้ไขข้อบกพร่องและแอปพลิเคชันทดสอบควันก่อนที่ฉันจะตรวจสอบ แต่ฉันลืมที่จะแสดงความคิดเห็นรหัสบางอย่าง (รหัสนี้ทำให้ UI แปลกเล็กน้อย) ฉันต้องการทราบวิธีปฏิบัติที่ดีก่อนที่จะตรวจสอบรหัสใน - ฉันไม่ต้องการทำผิดประเภทนี้อีกครั้ง

47 version-control  team-foundation-server  configuration-management 

ความระมัดระวังมักเพียงพอที่จะป้องกันปัญหา แต่บางครั้งฉันต้องตรวจสอบสาขาที่ฉันกำลังทำงานอยู่ ( เช่น "อืม ... ฉันอยู่ในdevสาขาใช่มั้ย") โดยการตรวจสอบเส้นทางการควบคุมของแหล่งสุ่ม ไฟล์. ในการมองหาวิธีที่ง่ายขึ้นฉันคิดว่าตั้งชื่อไฟล์โซลูชันตามนั้น ( เช่น MySolution_Dev.sln ) แต่ด้วยชื่อไฟล์ที่แตกต่างกันในแต่ละสาขาฉันไม่สามารถรวมไฟล์โซลูชันได้ มันไม่ได้เป็นเรื่องใหญ่ แต่มีวิธีการหรือ "เคล็ดลับเล็ก ๆ " ที่คุณใช้เพื่อให้แน่ใจว่าคุณอยู่ในสาขาที่ถูกต้องหรือไม่? ฉันใช้ Visual Studio 2010 กับ TFS 2008

27 version-control  visual-studio  team-foundation-server  branching 

คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Software Engineering Stack Exchange อพยพ 6 ปีที่แล้ว ฉันได้พบกับความท้าทายนี้สองสามครั้งและฉันหวังว่าบางคนสามารถให้การอ้างอิงการฝึกอบรมหรือคำแนะนำเกี่ยวกับวิธีการอธิบายความแตกต่างระหว่างรายการที่ค้างสินค้ากับงานใน TFS ฉันเข้าใจและได้อธิบายว่ารายการสินค้าค้างคือ "อะไร" และภารกิจคือ "อย่างไร" ฉันได้อธิบายด้วยว่า PBI เป็นข้อกำหนดและภารกิจเป็นไปตามข้อกำหนด ฉันได้พบกับจ้องมองที่ว่างเปล่าและรอยขีดข่วนหัวบ่อยครั้งเมื่อฉันอธิบายสิ่งนี้ ดูเหมือนว่าวิศวกรซอฟต์แวร์ที่ฉันอธิบายเรื่องนี้จะไม่สามารถแยกความแตกต่าง มันเหมือนกันทั้งหมดสำหรับพวกเขา ฉันเชื่อว่าความท้าทายอื่น ๆ ของฉันคือฉันไม่สามารถอธิบายได้อย่างมีประสิทธิภาพว่าทำไมจึงเป็นสิ่งสำคัญที่จะทำให้ความแตกต่าง

22 team-foundation-server  scrum  agile 

ฉันเพิ่งย้ายไปยัง บริษัท ใหม่และพวกเขากำลังใช้ TFS 2010 (สองสามเดือน) เป็นระบบควบคุมเวอร์ชันและเพิ่งเริ่มใช้เป็นระบบติดตามการทำงานสำหรับนักพัฒนา อย่างไรก็ตามดูเหมือนว่าจะไม่มีระบบติดตามบั๊กสำหรับใช้งานโดยผู้ที่อยู่นอกการพัฒนาและทดสอบ การสนับสนุนการผลิตกำลังได้รับรายงานปัญหาแก้ไขได้ทันทีและรายงานกลับไปยังผู้ใช้ในขณะนี้ สิ่งนี้จำเป็นต้องเปลี่ยน แต่ฉันไม่ต้องการให้มีระบบที่หลากหลายสำหรับการติดตามบั๊กและการติดตามการพัฒนา มีวิธีที่ฉันสามารถสร้างวิธีที่มีน้ำหนักเบามากในการป้อนข้อบกพร่องลงใน TFS เช่นเดียวกับที่ FogBugz ทำหรือไม่? การเข้าสู่ระบบ TFS เพื่อกรอกรายงานบั๊กดูเหมือนจะหนักกว่ามากและคุณต้องเชื่อมโยงกับแอปพลิเคชันเฉพาะ ฝ่ายสนับสนุนอาจสามารถทำสิ่งนี้ได้ แต่ฉันต้องการที่จะสามารถทดสอบไอเท็มและอาจเปลี่ยนความสัมพันธ์เป็นสิ่งอื่นนอกเหนือจากแอปพลิเคชัน ฉันเคยใช้ FogBugz ในอดีตและเมื่อเพิ่มข้อผิดพลาดคุณสามารถเพิ่มมาก / น้อยได้ตามที่คุณต้องการในรายการดังนั้นอย่างน้อยก็มีการบันทึกและในภายหลังคุณสามารถตีกลับได้เพื่อรับข้อมูลเพิ่มเติมเมื่อคุณมาถึงตั๋ว .

18 issue-tracking  team-foundation-server 

ฉันเป็นผู้รับเหมาที่เพิ่งเริ่มต้นกับ บริษัท ทีมคือนักพัฒนา 3 คนซึ่งประกอบด้วยผู้พัฒนา 2 คนถึงระดับกลางและอีกคนในระดับเดียวกันเริ่มเร็ว ๆ นี้และตัวฉันเอง (6 ปี xp) สำหรับนักพัฒนาทั้งสองที่มีอยู่มันเป็นงานแรกของพวกเขาที่ออกจากมหาวิทยาลัย / วิทยาลัยและพวกเขาไม่เคยมีนักพัฒนาอาวุโสที่ดูแลงานของพวกเขามาก่อน ไม่มีนโยบายการควบคุมเวอร์ชันที่ชัดเจน นักพัฒนาทำการพัฒนาทั้งหมดบนลำตัวแล้วนำไปใช้กับการผลิตโดยตรงจากเครื่องพัฒนาของพวกเขา ทีมที่มีอยู่ไม่คุ้นเคยกับการแตกแขนง ฉันกำลังเปลี่ยนแปลงทั้งหมดนี้และแนะนำเซิร์ฟเวอร์ CI, การทดสอบ TDD / การจัดเตรียม / การผลิต ฯลฯ พร้อมกับนโยบายการควบคุมเวอร์ชันเพื่อชมเชยสิ่งนี้ ระบบควบคุมแหล่งที่มาคือ TFS ซึ่งฉันไม่เคยใช้มาก่อน มันถูกกำหนดค่าให้เป็นแหล่งเก็บข้อมูลขนาดยักษ์ ฉันได้เขียนพอยน์เตอร์ให้กับพวกเขาแล้ว แต่มีอะไรอีกบ้างที่ฉันควรเพิ่ม / แก้ไขโดยคำนึงถึงประสบการณ์ของทีม นโยบายการควบคุมเวอร์ชัน การพัฒนาจะทำบนลำต้น หากการเปลี่ยนแปลงคาดว่าจะใช้เวลานานกว่าหนึ่งสัปดาห์ก็ควรจะทำในสาขาที่มีการผสานปกติจากลำตัวเข้าไปในสาขาเพื่อหยุดทั้งสองออกจากซิงค์ สร้างสาขาย่อยสำหรับรหัสการผลิต สาขานั้นควรมีรหัสที่มั่นคงเท่านั้น เราสามารถมีสาขาย่อยหนึ่งสาขาที่ได้รับการอัพเดตจากลำตัวหนึ่งครั้งต่อการวิ่งหรือเราสามารถสร้างสาขาย่อยแยกต่างหากสำหรับแต่ละสัปดาห์ หากจำเป็นต้องแก้ไขข้อบกพร่องเร่งด่วนที่มีผลกระทบต่อรหัสการผลิตรหัสนั้นจะถูกสร้างขึ้นในสาขาที่วางจำหน่ายและผสานกลับเข้าไปในลำต้น หากเรานำกลยุทธ์การเปิดตัวสาขาหนึ่งมาใช้ลำต้นจะถูกรวมเข้ากับสาขาที่วางจำหน่ายหนึ่งครั้งต่อการวิ่งไปยังจุดสิ้นสุดของการวิ่ง ถ้าเราใช้สาขาแยกต่อกลยุทธ์การปล่อยแล้วลำตัวไม่เคยถูกรวมเข้ากับสาขาการปล่อย ในบางสถานการณ์อาจจำเป็นต้องทำการแก้ไขข้อบกพร่องสองครั้งในสาขาที่แตกต่างกันหากสาขาแยกกันมากเกินไป หากเรากำลังวิ่งสั้น ๆ สิ่งนี้ไม่ควรเกิดขึ้นบ่อยเกินไป ฉันวางแผนที่จะมีสามเซิร์ฟเวอร์ …

17 version-control  development-process  team-foundation-server 

ในงานของเราเรามีแอปพลิเคชั่น. net ที่แตกต่างกันมากมายซึ่งมีฟังก์ชั่นพื้นฐานมากมาย เราได้สร้างแอปพลิเคชันเหล่านี้โดยใช้สถาปัตยกรรมระดับ n ที่สะอาด แต่เราได้พบกับช่วงเวลาที่เราตระหนักว่าเราได้ใช้ฟังก์ชั่นเดิมซ้ำหลายครั้ง เห็นได้ชัดว่านี่เป็นการละเมิด DRY และเราต้องการแก้ไขให้ถูกต้อง เรากำลังใช้ Nuget เพื่อความสำเร็จสำหรับรหัสกาวทั่วไป (เดินสาย IoC บันทึกการตั้งค่า) แต่เราต้องการแบ่งปันข้อมูลและชั้นธุรกิจระหว่างแอปพลิเคชันทั้งหมดของเรา แนวคิดก็คือ UI จะจัดการกับส่วนต่างๆของชั้นธุรกิจที่ต้องการจริงๆเท่านั้น สิ่งนี้ดูเหมือนว่าจะเป็นปัญหาตรงไปตรงมาในตอนแรก แต่การพัฒนาอย่างต่อเนื่องอาจทำให้เกิดข้อผิดพลาดบางอย่างและเราไม่แน่ใจว่าจะดำเนินการอย่างไร สมมติว่าเราสร้างหนึ่งชั้นธุรกิจของเราเพื่อปกครองพวกเขาทั้งหมด ฉันจะเรียกมันว่า "รากฐาน" เราแจ้งแอปพลิเคชันของเราเพื่อใช้งานมูลนิธิและทุกอย่างก็ยอดเยี่ยมมาก รากฐานถูกแจกจ่ายไปยังเลเยอร์ UI แบบแสงผ่านทาง nuget และเราดูดี แต่แล้วเราก็เริ่มเพิ่มคุณสมบัติให้กับแอปพลิเคชันของเราและเราประสบปัญหา สมมติว่าเรากำลังทำงานในโครงการ A และเราเพิ่มคุณสมบัติใหม่ที่ต้องมีการเปลี่ยนแปลงในมูลนิธิ เราทำการเปลี่ยนแปลงรากฐาน (Foundation-A) และผลักดันพวกเขาออกไปยังฟีด nuget เป็นแพ็กเกจที่ไม่เสถียร Project A ได้รับแพ็คเกจ nuget ล่าสุดและทั้งหมดนั้นดี ในขณะเดียวกันผู้พัฒนารายอื่นกำลังทำงานในโครงการ B. เขาได้รับพื้นฐานล่าสุดจากการควบคุมแหล่ง แต่นำมาจากสาขาที่มีเสถียรภาพดังนั้นจึงไม่มีการเปลี่ยนแปลงโครงการ A …

15 c#  team-foundation-server  branching 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน6 ปีที่ผ่านมา ฉันทำงานกับเว็บแอปพลิเคชันโดยใช้ TFS ทุกครั้งที่ฉันสร้างเว็บไซต์มันใช้เวลาไม่นานในการเริ่มต้นใหม่อีกครั้ง ฉันต้องการมีการแมปไซต์ที่สองในไดรฟ์ c ซึ่งฉันจะได้รับล่าสุดและสร้างวันละครั้งดังนั้นรุ่นนี้จะรวดเร็ว นี่จะเป็นไดเรกทอรี "อ่านอย่างเดียว" เนื่องจากฉันจะไม่ทำการแก้ไขใด ๆ โปรดแจ้งให้เราทราบหากเป็นไปได้หรือหากคุณมีทางเลือกอื่น

14 team-foundation-server 

ฉันเป็นผู้พัฒนา. NET และฉันใช้ TFS (เซิร์ฟเวอร์พื้นฐานสำหรับทีม) เป็นซอฟต์แวร์ควบคุมซอร์สของฉันหลายครั้ง คุณสมบัติที่ดีของ TFS คือ: การรวมที่ดีกับ Visual Studio (ดังนั้นฉันทำเกือบทุกอย่างที่มองเห็นไม่มีคำสั่งคอนโซล) เช็คเอาท์ง่ายกระบวนการเช็คอิน การผสานและการแก้ไขข้อขัดแย้งได้ง่าย สร้างอัตโนมัติง่าย การแตกแขนง ตอนนี้ฉันต้องการใช้ Git เป็นตัวควบคุมพื้นที่เก็บข้อมูลและแหล่งที่มาของโครงการโอเพ่นซอร์สของฉัน โครงการของฉันอยู่ในภาษา C #, JavaScript หรือ PHP ที่มีฐานข้อมูล MySQL หรือ SQL Server เป็นกลไกการจัดเก็บ ฉันเพิ่งใช้ความช่วยเหลือของ github.com เพื่อจุดประสงค์นี้และฉันสร้างโปรไฟล์ที่นั่นและดาวน์โหลด GUI สำหรับ Git ในส่วนนี้นั้นง่ายมาก แต่ฉันเกือบติดอยู่อีกต่อไป ฉันแค่ต้องการดำเนินการง่ายๆ (ง่ายจริงๆ) รวมถึง: การสร้างโครงการบน Git และทำแผนที่ไปยังโฟลเดอร์บนแล็ปท็อปของฉัน การตรวจสอบ / ตรวจสอบในไฟล์และโฟลเดอร์ การแก้ไขข้อขัดแย้ง …

14 version-control  git  github  team-foundation-server 

ขออภัยเกี่ยวกับโพสต์ที่ยาวนานนี้ แต่ฉันคิดว่ามันคุ้มค่า ฉันเพิ่งเริ่มต้นด้วยร้าน. NET ขนาดเล็กที่ทำงานค่อนข้างแตกต่างจากที่อื่น ๆ ที่ฉันเคยทำงาน ซอฟท์แวร์ที่เขียนตรงนี้ไม่ได้อยู่ในตำแหน่งก่อนหน้าใด ๆ ของฉันตรงที่มีลูกค้าหลายรายและไม่ใช่ลูกค้าทุกคนที่จะได้รับซอฟต์แวร์รุ่นล่าสุดพร้อมกัน ด้วยเหตุนี้จึงไม่มี "เวอร์ชันการผลิตปัจจุบัน" เมื่อลูกค้าได้รับการอัปเดตพวกเขายังได้รับคุณสมบัติทั้งหมดที่เพิ่มเข้ามาในซอฟต์แวร์ตั้งแต่การอัปเดตครั้งล่าสุดซึ่งอาจเป็นเวลานานแล้ว ซอฟต์แวร์สามารถกำหนดค่าได้อย่างมากและสามารถเปิดและปิดคุณสมบัติ: เรียกว่า "สลับคุณสมบัติ" วัฏจักรการวางจำหน่ายของที่นี่แน่นมากจริงๆแล้วมันไม่ได้อยู่ในกำหนดเวลา: เมื่อคุณสมบัติเสร็จสมบูรณ์ซอฟต์แวร์จะถูกปรับใช้กับลูกค้าที่เกี่ยวข้อง ทีมเมื่อปีที่แล้วย้ายจาก Visual Source Safe ไปยัง Team Foundation Server ปัญหาคือพวกเขายังคงใช้ TFS ราวกับว่ามันเป็น VSS และบังคับใช้ Checkout ล็อคในสาขารหัสเดียว เมื่อใดก็ตามที่การแก้ไขข้อผิดพลาดถูกนำออกสู่สนาม (แม้กระทั่งสำหรับลูกค้าเดี่ยว) พวกเขาเพียงแค่สร้างสิ่งที่อยู่ใน TFS ทดสอบข้อผิดพลาดได้รับการแก้ไขและปรับใช้ให้กับลูกค้า! (ตัวเองมาจากพื้นหลังของซอฟต์แวร์ยาและอุปกรณ์การแพทย์ซึ่งไม่น่าเชื่อเลย!) ผลที่ได้คือรหัส dev ที่อบออกมาครึ่งหนึ่งถูกนำไปผลิตโดยไม่ต้องมีการทดสอบ บั๊กมักจะลื่นไถลไปสู่รุ่นวางจำหน่าย แต่บ่อยครั้งที่ลูกค้าที่เพิ่งได้รับบิลด์จะไม่เห็นบั๊กเหล่านี้หากพวกเขาไม่ได้ใช้คุณสมบัติที่บั๊กนั้นอยู่ผู้อำนวยการรู้ว่านี่เป็นปัญหาเพราะ บริษัท เริ่มเติบโต ทันใดนั้นมีลูกค้ารายใหญ่บางรายเข้ามาและมีลูกค้าจำนวนน้อยกว่า ฉันถูกขอให้ดูที่ตัวเลือกการควบคุมแหล่งที่มาเพื่อกำจัดการปรับใช้ buggy หรือรหัสที่ยังไม่เสร็จ …

13 svn  continuous-integration  team-foundation-server 

ใน TFS เมื่อเราใส่ความคิดเห็นเพื่อแก้ไขสิ่งต่างๆในคำขอดึงก่อนที่เราจะยอมรับเราควรทำเครื่องหมายว่าปฏิเสธหรือรอผู้แต่งหรือไม่ ไหนดีกว่ากัน

13 team-foundation-server  pull-requests 

ในแผนกของฉันเรากำลังพัฒนา AddOns ที่เล็กกว่าหลายตัวสำหรับเซิร์ฟเวอร์การสื่อสารแบบรวม สำหรับการกำหนดเวอร์ชันและการพัฒนาแบบกระจายเราใช้ Team Foundation Server 2012 แต่: มีโซลูชัน TFS ขนาดใหญ่เพียงรายการเดียวสำหรับแอปพลิเคชันและห้องสมุดทั้งหมดของเรา: ทางออกหลัก การประยุกต์ใช้งาน แอพ 1 แอพ 2 แอพ 3 externals ห้องสมุด Lib 1 Lib 2 เครื่องมือ เส้นทาง "แอปพลิเคชัน" มีแอปพลิเคชันหลักทั้งหมด สิ่งเหล่านี้ไม่ได้ขึ้นอยู่กับแต่ละอื่น ๆ แต่ขึ้นอยู่กับโครงการห้องสมุดและภายนอก เส้นทาง "Externals" ประกอบด้วย DLLs ภายนอกบางตัวที่อ้างอิงใน Applications and Libraries ของเรา เส้นทาง Libraries มี libs ที่ใช้กันทั่วไป (เทมเพลต UI, คลาส …

12 project-management  team-foundation-server  projects-and-solutions 

เริ่มต้นด้วยทีม dev ใหม่ในโครงการใหม่และเราต้องกำหนดกลยุทธ์การแบ่งสาขาสำหรับแหล่งเก็บข้อมูลของเรา ( เช่น Microsoft Team Foundation Server 2010 ) เราได้ทำการอภิปรายกันอย่างเหนียวแน่นว่าจะ ... ก . มีสาขาReleaseหนึ่งสาขาที่เราผลิตงานสร้างและจากนั้นLabelเมื่อมีบางอย่างออกวางจำหน่ายจริง หรือ ข . มีสาขาReleaseใหม่สำหรับแต่ละ Release ใหม่เข้าสู่การผลิต ( เช่นเวอร์ชัน 1, 2, 3, ฯลฯ ... ) ตัวเลือกAดูเหมือนจะตรงไปตรงมา แต่เราไม่แน่ใจว่าสิ่งนี้จะนำไปสู่ปัญหาในระยะยาวหรือไม่ ตัวเลือกBดูเหมือนว่าจะเป็นเพียงการสร้างกิ่งไม้ที่มีอายุยืนยาวจำนวนมากเพียงครั้งเดียว ไม่มีใครมีประสบการณ์อย่างใดอย่างหนึ่งที่สามารถช่วยเราตัดสินใจได้ โดยเฉพาะฉันกำลังมองหาว่าจุดปวดอยู่ที่ใดสำหรับทางเลือกหนึ่ง อย่าลังเลที่จะมอบประสบการณ์เฉพาะที่เกี่ยวข้องกับ TFS และ / หรือนัยต่อการจัดการที่วางจำหน่าย

11 version-control  team-foundation-server  release-management  branching 

เรากำลังย้ายทีมงานโครงการของเราจากการใช้สาขาหลัก / ลำต้นเดียวไปยังสาขาการพัฒนา / การทำงานหลายสาขาที่ควรรวมเป็นหลักอย่างสม่ำเสมอ เรากำลังพิจารณากระบวนการใหม่ของเราในบทความนี้และคู่มือการแบ่งสาขาของ TFS (เรากำลังใช้ TFS และ Visual Studio 2010) ขณะนี้มีระหว่าง 1 ถึง 5 คนที่ทำงานในโครงการในเวลาใดก็ได้ หลักต้องมีความเสถียรตลอดเวลาเพราะเราต้องการให้ตัวเลือกที่จะปล่อยเมื่อใดก็ตามที่เราต้องการ เรายังไม่มี sprints คงที่ - อย่างน้อยยังไม่ได้ - และในขณะนี้ปล่อยทุก 1-2 สัปดาห์ ณ จุดนี้ในเวลาที่แต่ละคนกำลังแก้ไขข้อบกพร่องในใบสมัคร ในอีกไม่กี่สัปดาห์เราจะเริ่มพัฒนาส่วนประกอบใหม่ขนาดใหญ่สำหรับแอพ ผสานจุดหนึ่งที่เรากำลังมองหาคือเมื่อสาขาการพัฒนาควรจะสร้าง เราจะใช้เรื่องราวของผู้ใช้หลายคนพร้อมกันขึ้นอยู่กับชุดทักษะของนักพัฒนา เราคิดเกี่ยวกับการสร้างสาขาสำหรับนักพัฒนาแต่ละคน แต่มันก็ไม่สมเหตุสมผลเพราะจะต้องมีการร่วมมือกันในการทำงาน เราไม่สามารถผ่านสาขาการพัฒนาเดียวเพราะเราต้องการที่จะผสานกับหลักในขณะที่งานอื่นเสร็จสมบูรณ์ ใครบ้างมีคำแนะนำเกี่ยวกับเรื่องนี้?

11 development-process  team-foundation-server  branching