มีบางอย่างผิดปกติกับวิธีที่เราใช้ควบคุมเวอร์ชันหรือไม่

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

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

ดูเหมือนจะค่อนข้างซับซ้อน - มีวิธีที่ดีกว่าในการจัดการสถานการณ์ประเภทนี้หรือไม่? เรากำลังใช้เซิร์ฟเวอร์มูลฐานทีมและ Visual Studio 2010

V2.0 ควรมีสิ่งที่เราใช้เรียก 'สาขาที่มั่นคง' (เราใช้ Perforce ไม่ใช่ TFS) ที่สร้างขึ้นเมื่อเปิดตัว การแก้ไขใด ๆ สำหรับ v2 จะเกิดขึ้นกับสาขานี้แล้วแพร่กระจายกลับเข้าไปในสาขาการพัฒนา v3 ในขณะที่การทำงานของฟีเจอร์ v3 นั้นก็เช่นกัน

การมีการเปลี่ยนแปลงอยู่ในเครื่องของนักพัฒนาเป็นเวลานานจะส่งผลให้เกิดฝันร้ายในการบูรณาการ

มีหลายวิธีในการจัดการกับปัญหาเช่นนั้นโดยทั่วไปแล้วจะครอบคลุมด้วยแท็ก 'การแตกแขนง'แต่ละอันมีประโยชน์และข้อเสีย

แต่นักพัฒนาของคุณเลือกวิธีการ ... gee ฉันจะพูดด้วยวาจาเพื่อให้แน่ใจว่าฉันไม่ได้อ่านผิด ...

รหัส ... จะถูกเก็บไว้ในเครื่องท้องถิ่นของผู้พัฒนาจนกว่าจะเสร็จสิ้น ...

... วิธีที่กล่าวมาน่าจะเป็นสิ่งเดียวที่ผิดทั้งหมด!

สิ่งที่ทำให้มันชายแดนทางอาญากับผมเป็นที่สำหรับ TFS มีความยอดเยี่ยมและง่ายต่อการเข้าใจMicrosoft ทีมมูลฐาน Server กิ่งแนะแนว - เอกสารขนาดใหญ่และรายละเอียดที่มีการแตกแขนงคำแนะนำกลยุทธ์ที่เหมาะอย่างรอบคอบและอธิบายสำหรับทุกชนิดของโครงการที่แตกต่างกัน ( HTML รุ่น ที่นี่ )

1. นักพัฒนาของคุณมีความเข้าใจผิดขั้นพื้นฐานเกี่ยวกับวิธีใช้การควบคุมเวอร์ชัน
2. อย่าพูดคุยเกี่ยวกับซอฟต์แวร์ควบคุมรุ่น "ถูกต้อง" นี่ไม่ใช่ปัญหา
3. การปรับแต่งโค้ดทุกครั้งจะทำให้ปัญหายากขึ้นในการแก้ไข
4. เมื่อคุณตัดสินใจทำสิ่งที่ถูกต้องคุณจะไม่สามารถดำเนินการเปลี่ยนแปลงรหัสต่อไปได้ในขณะที่คุณแก้ไขสิ่งต่าง ๆ คุณต้องหยุดการพัฒนาทั้งหมดและรับรหัสไปยังการควบคุมเวอร์ชัน
5. นักพัฒนาจะต้องรู้สึกเจ็บปวดอย่างน้อยพอที่จะนั่งลงและพูดคุยเกี่ยวกับมัน
6. ซอฟต์แวร์ควบคุมเวอร์ชันทั้งหมดรองรับแนวคิดพื้นฐาน:
   • รหัสทั้งหมดเข้าไปในที่เก็บข้อมูลการควบคุมเวอร์ชัน
   • ไฟล์รหัสทั้งหมดมีหมายเลขรุ่น ตัวเลขเหล่านี้จะเพิ่มขึ้นโดยอัตโนมัติเมื่อมีการตรวจสอบรหัสอีกครั้ง
   • แท็ก TAG ทำเครื่องหมายไฟล์รหัสทั้งหมดของ (โดยเฉพาะ) ดังนั้นเราสามารถ TAG ปล่อยซอฟต์แวร์เวอร์ชัน 1 ได้
   • สาขาคือ "หันไป" จากลำต้นหลัก
     • การเปลี่ยนแปลงใด ๆ ที่เกิดกับสาขาจะไม่ส่งผลกระทบต่อลำตัว
     • คุณอาจเลือกที่จะรวมการเปลี่ยนแปลงสาขากลับเข้าไปในลำต้นหลักในบางจุด
     • ดังนั้นเราอาจทดลองโดยไม่ต้องกลัวที่จะทำให้สับสน "สิ่งที่ดี"
7. คุณต้องได้รับการควบคุมเวอร์ชัน "กระโดดแห่งศรัทธา" ตามที่ฉันเรียกมันว่า ไว้วางใจว่าการทำตามกฎพื้นฐานจะทำให้สิ่งต่าง ๆ ตรง ความไม่มีประสบการณ์ทำให้เราคิดอย่างอื่นเชื่อใจฉัน
8. นี่คือการสอนที่ดี เป็นเรื่องทั่วไปและสมบูรณ์พอที่คุณไม่จำเป็นต้องกัดเซาะแหล่งอื่น ๆ มากมาย
   • การควบคุมเวอร์ชันอธิบายได้ดีขึ้น

แก้ไข

• ใส่การควบคุมเวอร์ชันในคอมพิวเตอร์ที่ทำงานของคุณ
  • คุณสามารถทำสิ่งนี้ได้ทันทีโดยไม่ต้องประสานงานกับทีม
  • แม้จะมีการควบคุมเวอร์ชันทีมฉันขอแนะนำอย่างนี้
  • หากทีมของคุณใช้ Git หรือ Mercurial คุณกำลังใช้ที่เก็บข้อมูลอิสระในท้องถิ่น นั่นคือการทำงานของการควบคุมเวอร์ชันแบบกระจาย
  • คุณสามารถใช้ซอฟต์แวร์ VC ต่างจากทีมของคุณ ทีมของเราใช้การโค่นล้มฉันใช้ Mercurial ในพื้นที่ metafiles ซอฟต์แวร์ VC (".svn", ".mg", โฟลเดอร์ที่ซ่อนอยู่) จะไม่ขัดแย้งกัน

คุณไม่ได้ทำหน้าที่เป็นที่เก็บทีม de-facto มันมีไว้สำหรับจัดการงานของคุณเอง, การรีแฟคเตอร์ความพยายาม ฯลฯ และ CYAing ด้วยตัวคุณเองในขณะที่ทีมยังคงดำเนินการตาม FUBAR ต่อไป

สิ้นสุดการแก้ไข

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

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

คำตอบด่วน:ทีมพัฒนาควรมีสาขาการผลิตแยกต่างหากเพื่อให้การปรับใช้รหัสฐาน V2.0 แยกต่างหากจากลำต้นหลัก

ทั้งหมดการแก้ไขข้อบกพร่องที่ต้องทำในสาขาที่แรกและจากนั้นผ่านการทดสอบและนำไปใช้กับสาขาอื่น ๆ เพื่อที่จะให้รหัสในการซิงค์

โครงการของคุณควรมีหลายสภาพแวดล้อมfor health developmentเช่นProd, Staging, QA และ Dev (บางครั้ง UAT) ควรตั้งค่าสภาพแวดล้อมเหล่านี้ก่อนที่จะไปยังรุ่นผลิต

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

เนื่องจาก TFS ถูกกล่าวถึงว่าเป็นการควบคุมเวอร์ชันฉันได้รวบรวมรายการของบทความซึ่งจะเป็นประโยชน์ในการตั้งค่าสภาพแวดล้อมการพัฒนาสุขภาพ:

• การใช้ Team Foundation Server กับทีมพัฒนาขนาดเล็ก
• ยินดีต้อนรับสู่แพลตฟอร์มการรวม TFS!
• การพัฒนาทีมด้วยคำแนะนำ TFS
• การตั้งค่าสภาพแวดล้อมการพัฒนา

ไม่เพราะขณะที่คุณใช้ VCS คุณไม่ได้ทำการควบคุมเวอร์ชัน

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

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

ฉันเป็นนักพัฒนาและเราจะได้รับรหัสสาขาและฐานข้อมูลที่แตกต่างกันสำหรับการแก้ไขของเวอร์ชันปัจจุบันและที่แตกต่างกันสำหรับการปรับปรุงและสำหรับรุ่นที่ใหม่กว่า

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

ยิ่งกว่านั้นเรายังทำตามแบบฝึกหัดหากฉันมี 10 การแก้ไขสำหรับเวอร์ชันปัจจุบันของฉัน

ฉันเขียนเป็น

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

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

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+Fคำสั่งและพิมพ์//Start Iteration 2, Fix No-1, Branch No-"ABC" เพื่อค้นหาในโซลูชันทั้งหมดช่วยให้ค้นหาตำแหน่งที่แน่นอนไฟล์ที่มีการเปลี่ยนแปลงรหัสและรับโค้ดใหม่เฉพาะส่วนที่สามารถใช้ในการส่งมอบ