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

ผมทำงานใน บริษัท ที่เขียนจำนวนมากของปลั๊กอินสำหรับLiferay พอร์ทัล ปลั๊กอินเหล่านี้ (พอร์ตเล็ต, ธีม ฯลฯ ) โดยปกติจะสามารถใช้ซ้ำได้และแน่นอนควรได้รับการอัปเดตสำหรับพอร์ทัลเวอร์ชันใหม่

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

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

ขณะนี้เรากำลังย้ายไปGitorious เราพยายามที่จะเข้าใจรูปแบบการแตกแขนงสำหรับสถานการณ์ดังกล่าว

โมเดลของฉัน

สิ่งที่ฉันเสนอคือ:

1. แต่ละปลั๊กอินจะมีพื้นที่เก็บข้อมูลของตัวเองใน Gitorious ภายในโครงการ ตัวอย่างเช่นพอร์ตเล็ตสำหรับแสดงลูกแมวจะมีkittens-portletพื้นที่เก็บข้อมูลภายในliferay-portletsโครงการ
2. เมื่อสร้างปลั๊กอินใหม่ให้สร้างขึ้นที่สาขาที่มีชื่อตามเวอร์ชัน Liferay (ตัวอย่างเช่นlf5.2)
3. ทุกครั้งที่มีการปรับปรุงจะทำบนปลั๊กอิน, อัพเดทได้รับการอนุมัติและนำไปใช้ในการผลิต, การติดแท็กปลั๊กอินที่มีรุ่น (ตัวอย่างเช่นlf5.2v1, lf5.2v2ฯลฯ .) *
4. ทุกครั้งที่มีการย้ายปลั๊กอินไปยัง Liferay เวอร์ชันใหม่เราจะทำการแยกสาขาเวอร์ชันล่าสุด (การสร้างเช่นสาขาlf6.0)
5. lf6.0v1เมื่อในการผลิตหัวของสาขาใหม่จะได้รับแท็กเช่น
6. ทุกครั้งที่เราต้องปรับแต่งปลั๊กอินในแบบเฉพาะลูกค้าเราสร้างสาขาที่มีชื่อลูกค้า (ตัวอย่างเช่นเราจะสร้างสาขาlf5.2clientcorpสำหรับลูกค้าของเรา "ClientCorp Inc. ")

นี่เป็นรูปแบบที่ผิดปกติ: มันจะไม่มีสาขาmasterและไม่รวมสาขาจำนวนมาก นี่คือวิธีที่ฉันคิดว่าที่เก็บที่มีรูปแบบดังกล่าวจะมีลักษณะดังนี้:

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

แบบจำลองของเพื่อนฉัน

จากนั้นเขาแนะนำโมเดลอื่น: เราจะมีที่เก็บสำหรับปลั๊กอินแต่ละอันในเวอร์ชัน Liferay (ดังนั้นเราจะเริ่มสร้าง a kittens-lf5.2-portletและจากนั้น a kittens-lf6.0-portlet) แต่ละอันมีmasterสาขาและdevelopสาขา masterจะพร้อมเสมอสำหรับการใช้งาน (หรืออาจเป็นวิธีอื่น ๆmasterและstableตามที่Steve Losh แนะนำ )

มันง่ายมาก แต่ฉันไม่ชอบระบบนี้:

1. มันอาจส่งผลให้มีแหล่งเก็บข้อมูลจำนวนมากในโครงการทำให้ Gitorious ยากต่อการเรียกดู
2. ชื่อของไดเรกทอรีของโครงการนั้นเกี่ยวข้อง หากมีคนโคลนที่เก็บไปยังkittens-lf6.0-portletdir และสร้าง WAR ด้วย ant (ตามปกติ) ชื่อ WAR ก็จะkittens-lf6.0-portletเหมือนกัน เวอร์ชันเก่าของพอร์ตเล็ตนี้ (ชื่อkittens-portletตัวอย่าง) จะถือว่าเป็นพอร์ตเล็ตอื่น (และอาจหายไป) ในพอร์ทัลที่อัปเกรด การดูแลเล็กน้อยสามารถหลีกเลี่ยงได้ แต่ฉันต้องการหลีกเลี่ยง
3. ปลั๊กอินรุ่นเดียวกันจะถูกแยกออกจากกัน ฉันทำลายหัวใจของฉัน :(
4. kittens-lf6.0-portlet ฉันคิดว่าเป็นชื่อที่น่าเกลียดสำหรับที่เก็บ

ฉันสงสัยว่าทั้งสองประเด็นสุดท้าย - ซึ่งเป็นอีกสองประเด็นส่วนตัวเช่นกัน - เป็นเหตุผลหลักสำหรับความไม่เต็มใจของฉัน อย่างไรก็ตามการคัดค้านทั้งสี่ยืน

OTOH ข้อเสนอของฉันดูเหมือนจะแปลกสำหรับฉันและฉันสงสัยว่ามีข้อบกพร่องซ่อนเร้นอยู่หรือไม่ OT3rdH git นั้นทรงพลังและยืดหยุ่นมากซึ่งฉันคิดว่าฉันไม่ควรรู้สึกละอายกับการสำรวจความเป็นไปได้ของมัน

ดังนั้นฉันถาม:

1. อะไรจะเป็นรูปแบบที่ดีที่สุด ข้อเสนอของฉัน? แบบจำลองของเพื่อนฉัน ระบบ Vincent Driessen ดั้งเดิมตอนนี้
2. คุณจะแนะนำรูปแบบการแยกสาขาอื่นใด
3. หากคุณคิดว่าแบบจำลองของฉันไม่ดีทำไมคุณคิดเช่นนั้น ฉันชอบที่จะเรียนรู้สิ่งที่เป็นข้อเสียและจุดบอด

* จริง ๆ แล้วฉันต้องการติดแท็กคอมมิทด้วยเวอร์ชันเช่นv1แต่เห็นได้ชัดว่าแท็กในคอมไพล์ไม่ได้ถูกกำหนดขอบเขตในสาขา - นั่นคือฉันไม่สามารถมี 1 v1แท็กในlf5.2และอีกแท็กอินlf6.0- ดังนั้นฉันต้องตั้งชื่อ สาขา. มันถูกต้อง BTW?

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

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

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

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

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

โดยวิธีการ: ฉันเป็นโปรแกรมเมอร์ Java ผู้เชี่ยวชาญ Maven สร้างผู้เชี่ยวชาญและมีประสบการณ์กับ Liferay และพอร์ทัลเซิร์ฟเวอร์อื่น ๆ (IBM WebSphere และ Glassfish)

แต่นี่เป็นเพียงแค่€ 0.02 ของฉัน