รูปแบบสำหรับการรวมอย่างต่อเนื่องและ DVCS

ขณะนี้เราใช้การโค่นล้มและ TeamCity เราจะย้ายไปใช้ Mercurial (โดยเฉพาะ Kiln เนื่องจากเราเป็นผู้ใช้ FogBugz)

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

ด้วย SVN เราให้บริการพื้นที่เก็บข้อมูลส่วนกลางจำนวน จำกัด - มีประสิทธิภาพต่อหนึ่งโครงการ (หนึ่งหรือน้อยกว่าหนึ่งโซลูชัน Visual Studio) ดังนั้นจึงง่ายต่อการเปิดใช้งานบิลด์และรับความมั่นใจว่าไฟล์ทั้งหมดได้รับการยอมรับและไม่มี Stray dependencies ฯลฯ แต่ถ้าเราจะใช้ความได้เปรียบ Mercurial ที่เหมาะสมเราจะต้องการที่เก็บอินสแตนซ์ที่มากขึ้น - ที่ซึ่งฉันคาดว่าการเปลี่ยนแปลงจะไหลไปสู่ ​​repo "live" ที่ชัดเจน ปัญหาที่ฉันดิ้นรนคือ repo สดดูเหมือนว่าฉันจะ "สาย" เกินกว่าที่จะกระตุ้นให้ CI ของฉันสร้าง OTOH หนึ่ง CI build ต่อโครงการต่อผู้พัฒนาน่าจะมากเกินไป (และทำให้เกิดปัญหาอื่น ๆ )

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

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

ขั้นแรกการมีหลายบิลด์ต่อโปรเจ็กต์ใน TeamCity เป็นหนทางที่จะไป ลักษณะของแพลตฟอร์มทำให้ง่ายมาก - ปุ่มคัดลอกมีไว้สำหรับเหตุผล

ไม่ว่าในกรณีใดเมื่อเราอยู่บน SVN เรามักจะรัน 2 บิลด์สำหรับแต่ละโครงการ - หนึ่งชี้ไปที่สายการพัฒนาหลัก (ในกรณีของเราลำตัว) และอีกหนึ่งชี้ไปที่สาขาการเปิดตัวของเรา เราดำเนินการติดตั้งนี้สร้างไป HG ขณะนี้รูปแบบการแตกแขนงคล้ายกับคนนี้ มีเพียงความท้าทายที่แท้จริงเท่านั้นที่ได้รับการค้นหา funk schwea ใหม่เกี่ยวกับหมายเลขบิลด์ตอนนี้ซึ่งเราไม่สามารถใช้หมายเลขการแก้ไข SVN ปัจจุบันได้อีก

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

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

• แทร็กเริ่มต้นการพัฒนา "เสร็จสมบูรณ์"
• คุณลักษณะสาขาติดตามงานที่กำลังดำเนินอยู่
• ปล่อยจุดติดตามสาขาที่เราปล่อยจากค่าเริ่มต้น

ดังนั้นงานเริ่มต้นด้วยการสร้างสาขาฟีเจอร์จากค่าเริ่มต้นปัจจุบัน เมื่อสาขาคุณลักษณะจะทำ * สาขาจะถูกปิดและกลับเข้ามารวมเป็นค่าเริ่มต้น

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

สำหรับการรวมอย่างต่อเนื่องเราทำสองสิ่ง:

• การรวม "ตลอดเวลา" ที่ตรวจสอบสถานะของการเริ่มต้น
• การรวมใหม่สำหรับแต่ละสาขาที่วางจำหน่าย

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

_{* คำจำกัดความของ "ทำ" คือคุณสมบัตินี้เป็นข้อมูลล่าสุดพร้อมการรวมจากค่าเริ่มต้นและได้รับการอนุมัติในการตรวจสอบโค้ด}

หากคุณย้ายไปที่ DVCS เช่น Hg คุณไม่เพียง แต่ได้รับ "ส่วนที่กระจาย" คุณยังได้รับพลังจากการแตกแขนงและการผสานที่ดี

พิจารณาว่าตอนนี้คุณจะมีตัวติดตามปัญหาที่ดีและ SCM ที่ดี ... ทำไมไม่สร้างสาขาสำหรับแต่ละงาน

รูปแบบ "branch per task" ไม่ใช่เรื่องใหม่ (ตรวจสอบหนังสือของ Berczuk) แต่มันเป็นสิ่งที่ควรลอง

ผมอธิบายในรายละเอียดที่นี่และข้อดีข้อเสียของ CI VS "ควบคุม" ที่นี่