กลยุทธ์การแตกแขนงที่ดีที่สุดเมื่อทำการบูรณาการอย่างต่อเนื่อง?


100

กลยุทธ์การแตกแขนงที่ดีที่สุดที่จะใช้เมื่อคุณต้องการผสานรวมอย่างต่อเนื่องคืออะไร?

  1. การแตกกิ่งก้าน:พัฒนาบนลำต้นเก็บกิ่งไว้สำหรับแต่ละรุ่น
  2. การแยกคุณสมบัติ:พัฒนาคุณลักษณะแต่ละอย่างในสาขาที่แยกจากกันผสานเพียงครั้งเดียวที่เสถียร

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


2
หมายเหตุด้านข้าง: บางคนอาจโต้แย้งว่าแม้จะมีการใส่คุณสมบัติใหม่ทุกอย่างก็ควรมีเสถียรภาพเสมอ ในทางกลับกันนั่นอาจเป็นเรื่องเพ้อฝัน
Keith Pinson

คำตอบ:


21

ฉันคิดว่าหัวข้อนี้น่าสนใจมากเนื่องจากฉันพึ่งพาสาขาในงานประจำวันของฉันเป็นอย่างมาก

  • ฉันจำได้ว่า Mark Shuttleworth เสนอแบบจำลองเกี่ยวกับการรักษาสาขาหลักให้คงอยู่ในขณะที่ก้าวไปไกลกว่า CI ทั่วไป ผมโพสต์เกี่ยวกับเรื่องนี้ที่นี่
  • เนื่องจากฉันคุ้นเคยกับ Cruise Control ฉันจึงบล็อกเกี่ยวกับสาขางานและ CI ที่นี่ด้วย มันเป็นขั้นตอนโดยขั้นตอนการสอนการอธิบายวิธีการทำด้วยพลาสติก SCM
  • ในที่สุดฉันก็พบบางหัวข้อเกี่ยวกับ CI (และอาจพูดถึงการแตกแขนง) ในหนังสือของ Duvall เรื่อง CI ก็น่าสนใจเช่นกัน

หวังว่าลิงก์จะน่าสนใจ


เราได้เพิ่มการสนับสนุนให้กับ Bamboo เพื่อทำสาขาต่องานcodicesoftware.blogspot.com/2012/02/…และดูเหมือนว่าเวอร์ชันใหม่ล่าสุดของพวกเขาจะทำได้โดยใช้การควบคุมเวอร์ชันต่างๆรวมถึง dvcs ด้วย
pablo

20

คำตอบขึ้นอยู่กับขนาดของทีมและคุณภาพของการควบคุมแหล่งที่มาของคุณและความสามารถในการรวมชุดการเปลี่ยนแปลงที่ซับซ้อนได้อย่างถูกต้อง ตัวอย่างเช่นในการควบคุมแหล่งที่มาของสาขาแบบเต็มเช่นการผสาน CVS หรือ SVN อาจเป็นเรื่องยากและคุณอาจจะทำได้ดีกว่ากับรุ่นแรกในขณะที่ถ้าใช้ระบบที่ซับซ้อนกว่าเช่น IBM ClearCase และด้วยทีมที่มีขนาดใหญ่ขึ้นคุณอาจทำได้ดีกว่าในรุ่นที่สอง แบบจำลองหรือการรวมกันของทั้งสอง

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

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

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

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

โมเดลข้างต้นไม่สมเหตุสมผลกับทีมที่อยู่ภายใต้นักพัฒนา 50 คนและระบบควบคุมแหล่งที่มาโดยไม่มีสาขาที่กระจัดกระจายและความสามารถในการผสานที่เหมาะสมเช่น CVS หรือ SVN ซึ่งจะทำให้ทั้งโมเดลนี้กลายเป็นฝันร้ายในการตั้งค่าจัดการและผสานรวม


5
ฉันไม่แน่ใจว่าฉันยอมรับว่าสิ่งที่คุณอธิบายนั้นไม่สมเหตุสมผลสำหรับทีมที่มีอายุต่ำกว่า 50 ปี ฉันเห็นประโยชน์สำหรับทีมที่เล็กกว่ามากเช่นกัน +1
Aardvark

2
แน่นอนว่ามีประโยชน์สำหรับทีมทุกขนาด คำถามอยู่ที่ขนาดของทีมที่ผลประโยชน์มีมากกว่าค่าใช้จ่ายที่เกี่ยวข้องกับกระบวนการที่หนักหน่วง
Jiri Klouda

ซึ่งคล้ายกับ GitFlow และ / หรือ GitHubFlow แบบจำลอง ฉันไม่คิดว่าโมเดลเหล่านี้ช่วยในการผสานรวมอย่างต่อเนื่อง (CI) ในความคิดของฉัน Trunk Based Development เป็นการปรับปรุงที่สำคัญสำหรับโมเดลเหล่านี้
ยานี

คุณจะเห็นได้ว่าความคิดเห็นนี้เป็นจริงก่อนวันที่เผยแพร่ต้นฉบับของ git flow ไม่ค่อยแน่ใจว่า "ดีกว่า" หมายถึงอะไร ฉันสนับสนุนทีมนักพัฒนา 1, 5, 25, 150, 1,000 และ 20,000 ที่ทำงานในโครงการที่รวมเข้าด้วยกัน ข้อกำหนดแตกต่างกันไปและ "ดีกว่า" เป็นคำที่สัมพันธ์กันมาก คุณจำเป็นต้อง backport code หรือไม่? แก้ไขความปลอดภัย? ถ้าไม่เช่นนั้นชีวิตของคุณก็เรียบง่าย SaaS เป็นผลโดยตรงจากข้อ จำกัด ที่กำหนดโดยการพัฒนาตามลำต้น แฟล็กคุณลักษณะซับซ้อนพอ ๆ กับสาขาคุณลักษณะ ยกเว้นคุณจะหาข้อมูลจากลูกค้าเมื่อการเปลี่ยนแปลงของพวกเขาแตก
Jiri Klouda

9

โดยส่วนตัวแล้วฉันพบว่ามันสะอาดกว่ามากที่จะมีลำต้นที่มั่นคงและมีลักษณะแตกแขนง ด้วยวิธีนี้ผู้ทดสอบและผู้ที่ชอบจะอยู่ใน "เวอร์ชัน" เดียวและอัปเดตจาก trunk เพื่อทดสอบฟีเจอร์ใด ๆ ที่เป็นโค้ดที่สมบูรณ์

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

เป็นโบนัสเพิ่มเติมมีการทดสอบการผสานรวมบางระดับที่มาโดยอัตโนมัติ


นอกจากนี้คุณยังแยกสาขาและแท็กสำหรับแต่ละรุ่นหลัก ๆ หรือไม่ หรือแค่แท็ก?
KingNestor

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

@king ฉันจะบอกว่าอาจขึ้นอยู่กับสิ่งที่คุณเรียกว่ารุ่นหลัก แต่ไม่ว่าในกรณีใดคุณสามารถแท็กและแยกสาขาได้ในภายหลังเมื่อคุณต้องการ (ตามแท็ก :))
eglasius

5

ฉันคิดว่ากลยุทธ์อย่างใดอย่างหนึ่งสามารถใช้กับการพัฒนาอย่างต่อเนื่องได้หากคุณจำหนึ่งในหลักการสำคัญที่นักพัฒนาแต่ละคนให้คำมั่นสัญญากับ trunk / mainline ทุกวัน

http://martinfowler.com/articles/continuousIntegration.html#EveryoneCommitsToTheMainlineEveryDay

แก้ไข

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

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

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

แก้ไขอีกครั้ง

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

http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/


น่าสนใจหาโพสต์นี้ไม่ได้อีกแล้ว
Jirong Hu

5

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

สาขาคุณลักษณะยังสะดวกมากโดยเฉพาะอย่างยิ่งหากนักพัฒนารายหนึ่งต้องการเปลี่ยนแปลงครั้งใหญ่ในขณะที่คนอื่น ๆ ยังคงออกเวอร์ชันใหม่

ดังนั้นสำหรับฉันการใช้กลไกทั้งสองเป็นกลยุทธ์ที่ดีมาก

ลิงค์ที่น่าสนใจจากหนังสือของ SVN


4

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

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


2

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

ต้องบอกว่า ...

  • ไม่มีเหตุผลว่าทำไมไม่สามารถใช้ CI ในทั้งสองวิธีที่คุณอธิบาย
  • แนวทางเหล่านี้ทำงานร่วมกันได้ค่อนข้างดี
  • ทั้งสองอย่างไม่ "ดี" กว่าอีกอย่าง
  • CI เหมาะสมกับลำต้นที่ไม่เสถียร

ทั้งหมดนี้ได้รับคำตอบในคำถามที่สี่ในหน้าที่คุณนำไดอะแกรมมาจาก: http://blogs.collab.net/subversion/2007/11/branching-strat/


2

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

สำหรับข้อมูลเบื้องต้นที่ดีที่สุดเกี่ยวกับ Mainline Model โปรดอ่านสิ่งนี้: https://web.archive.org/web/20120304070315/http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

อ่านลิงค์ เมื่อคุณมีพื้นฐานแล้วให้อ่านบทความต่อไปนี้โดย Henrik Kniberg ที่เคารพนับถือ จะช่วยให้คุณเชื่อมโยง Mainline Model ด้วยการผสานรวมอย่างต่อเนื่อง

http://www.infoq.com/articles/agile-version-control


ไม่สามารถเข้าถึงบทของ O'Reilly ได้อีกต่อไป
Jason S

1

เมื่อเราเริ่มต้นทีมเราได้รับการสืบทอดกลยุทธ์ตามรุ่นจากผู้ขายที่พัฒนาระบบเดิมที่เรากำลังจะรับผิดชอบ มันใช้งานได้จนถึงเวลาที่ลูกค้าของเราร้องขอว่าไม่ควรรวมคุณสมบัติที่พัฒนาแล้วหลายอย่างในรุ่น (fyi ~ 250k บรรทัดของโค้ด, ~ 2500 ไฟล์, Scrum with XP SDLC)

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

"ตะปูในโลงศพ" ขั้นสุดท้ายของกลยุทธ์ SC บริสุทธิ์เกิดขึ้นเมื่อเราตัดสินใจว่าเราควรมี 1. ลำต้นที่มั่นคงและ 2. การผลิตควรมี ST, UAT และการถดถอยที่ทดสอบ BINARIES (ไม่ใช่แค่แหล่งที่มา - คิดว่า CC)

สิ่งนี้ทำให้เราคิดค้นกลยุทธ์ที่เป็นลูกผสมระหว่างคุณลักษณะและกลยุทธ์ SC ตามรุ่น

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

ในระยะสั้นสาขาตามคุณลักษณะใช้ในการพัฒนาทดสอบระบบและฟังก์ชันการทำงานของ UAT sprint branch (จริงๆคือ release branch) ถูกใช้เพื่อเลือกผสานคุณสมบัติตามต้องการและการทดสอบการรวม

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


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

0

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

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

ps คุณได้รับการอ้างอิงแนวทางเหล่านั้นมาจากไหน? - ไม่รู้สึกว่ากราฟเหล่านั้นแสดงถึงตัวเลือกทั้งหมด

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


มันมีบางอย่างมากขึ้นเช่นกัน แต่ฉันรู้สึกว่าการแยกส่วนฟีเจอร์และการแตกแขนงเผยแพร่เป็น 2 อย่างที่พบบ่อยที่สุด
KingNestor

0

Dave Farleyผู้เขียนContinuous Deliveryอ้างถึงTrunk Based Development (TBD)ว่าเป็นรากฐานที่สำคัญของ Continuous Integration (CI) และ Continuous Delivery (CD) เขาพูดว่า:

การแตกแขนงรูปแบบใด ๆ นั้นตรงกันข้ามกับการรวมแบบต่อเนื่อง

เขายังบอกอีกว่า

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

Trunk Based Development (TBD)คือการรวมการเปลี่ยนแปลงโค้ดเข้ากับ trunk (aka, master, mainline) อย่างน้อยวันละครั้งโดยเฉพาะอย่างยิ่งหลายครั้งต่อวัน การบูรณาการแบบต่อเนื่อง (CI) เป็นแนวทางปฏิบัติที่คล้ายคลึงกันยกเว้นว่าจะเกี่ยวข้องกับการตรวจสอบการเปลี่ยนแปลงโค้ดโดยใช้การทดสอบอัตโนมัติ ที่ดีที่สุดของกลยุทธ์ที่แตกแขนงสำหรับเรื่องนี้คือการทำงานโดยตรงจากลำต้นและจะดำเนินการตรวจสอบรหัสผ่านคู่-การเขียนโปรแกรม หากคุณไม่สามารถจับคู่ด้วยเหตุผลบางอย่างหรือคุณแค่ต้องการแตกกิ่งก้านจริงๆให้ตรวจสอบให้แน่ใจว่ากิ่งก้านของคุณมีอายุสั้น (น้อยกว่าหนึ่งวัน)

ฉันทำงานกับ Trunk "master" ใน GIT repos ของฉัน ฉันมุ่งมั่นที่จะเชี่ยวชาญในพื้นที่และผลักดันทันทีเมื่อฉันเชื่อมต่อกับเครือข่ายไปยัง repo หลักของฉันที่ CI ทำงาน แค่นั้นแหละ!

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

ฉันใช้ branch โดยนามธรรมการปลดปล่อยความมืดและบางครั้งแฟล็กคุณลักษณะ สิ่งที่ฉันได้รับกลับมาคือข้อเสนอแนะที่รวดเร็วและชัดเจน (อย่างน้อยก็ต่อคุณภาพของการทดสอบของฉัน)


Dave Farley และ Jez Humble มีจุดยืนที่ไม่ถูกต้องในการแตกแขนง เหตุผลก็คือมันเข้ารหัสข้อสันนิษฐานที่สำคัญ "คุณจะไม่ต้องจัดการโค้ดในระดับฟีเจอร์และถ้าเป็นเช่นนั้นมันก็โอเคสำหรับการใช้งานที่มีราคาแพง" และพวกเขาใช้การประเมินตามสมมติฐานอื่น "การรวมมีราคาแพงเกินไปสำหรับระบบอัตโนมัติ การผสานแทบจะเป็นไปไม่ได้ในระดับเดียวกัน " หากสมมติฐานทั้งสองนั้นไม่เป็นความจริงหากคุณอาศัยอยู่ในโลกที่การรวมเข้าด้วยกันมีราคาถูก แต่จำเป็นต้องจัดการโค้ดในระดับคุณลักษณะสำหรับพอร์ตย้อนกลับและการแก้ไขความปลอดภัยคำแถลงของพวกเขาจะพังทลาย เป็นกรณีที่หายาก
Jiri Klouda

บาง บริษัท จำเป็นต้องย้ายคุณสมบัติไปข้างหน้าไปสู่การเปิดตัวในอนาคตหลังจากที่ฟีเจอร์เหล่านั้นเข้าสู่ Roadblock ในการนำไปใช้งานและกำลังรอการเปิดตัว บางครั้งอาจมีตัวเลือกในการฝากรหัสไว้เช่นเดียวกับในผลิตภัณฑ์ SaaS แต่หากปล่อยรหัสให้กับลูกค้าอาจไม่ใช่ทางเลือกเนื่องจากคู่แข่งสามารถวิเคราะห์ได้ โค้ดจำนวนมากในทุกวันนี้ไม่มีการคอมไพล์และแม้ว่าจะเป็นเช่นนั้นการกำหนดแฟล็ก / คุณลักษณะในโค้ดจะอยู่ในระดับความซับซ้อนเดียวกันกับสาขา
Jiri Klouda

-3

ฉันคิดว่าเครื่องมือที่คุณใช้เป็นปัจจัยสำคัญที่นี่

  • หากคุณกำลังใช้การโค่นล้มให้ใช้ตัวเลือก 1 และปล่อยจากกิ่งไม้
  • หากคุณใช้ GIT ตัวเลือกที่ 2 จะทำงานได้ดีสำหรับคุณ

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