มีสาขาการผลิตหรือใช้ต้นแบบ?

16

ฉันทำงานกับทีมเล็ก ๆ กับนักพัฒนาระยะไกลอื่น ๆ ในRailsแอปพลิเคชัน เรากำลังเริ่มแก้ไขgitเวิร์กโฟลว์ของเรา เราคิดเกี่ยวกับโครงสร้างการแตกแขนงดังนี้:

(dev) -> (qa) -> (stag) -> (master)

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

(master) -> (qa) -> (stag) -> (prod)

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

อะไรคือข้อเสียของการใช้โครงสร้างการแยกสาขาที่ใช้สำหรับการพัฒนาเป็นหลักและแยกสาขาที่แยกต่างหากคือสิ่งที่คุณใช้สำหรับการปรับใช้?

git

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

— BitTickler

2

เราใช้เวิร์กโฟลว์คอมไพล์ที่อธิบายไว้ในไซต์นี้ด้วยความแตกต่างเล็กน้อย nvie.com/posts/a-successful-git-branching-modelความแตกต่างเพียงอย่างเดียวคือเราชอบสาขาท้องถิ่นที่เข้ามามีส่วนร่วมในการพัฒนาเพื่อสร้างประวัติศาสตร์ที่สะอาดและปฏิบัติตามตรรกะ "หนึ่งกระทำปัญหาเดียว"

— Jepessen

ปกติแล้วจะเกิดอะไรขึ้นกับสาขา "กวาง" ของคุณ

— simgineer

แนะนำให้ชัดเจน CI / CD ไม่ได้ใช้สาขาหลักเนื่องจากอาจถูกเรียกออกมาผิด ๆ {development} - {unit} - {Integration} - {staging} - {production} ในสีน้ำเงิน / สีเขียวที่มีการผลิตอย่างต่อเนื่องสร้าง> ชิ้นที่ใช้งานอยู่และการจัดเตรียม> ชิ้นที่ไม่ใช้งาน HEAD> พัฒนาสาขาที่คุณสมบัติถูกแยกออก พัฒนาให้มี webhooks เพื่อกระตุ้นการสร้างไปสู่หน่วยการพัฒนาสู่การรวมและการจัดเตรียม (ด้วยแท็กที่เหมาะสมเมื่อผ่านการรวม) โปรแกรมแก้ไขด่วนที่มีต่อการพัฒนา + การผลิต (หายาก แต่เกิดขึ้น) ความซับซ้อนมากขึ้น แต่ความคิดทั่วไป

— Jimmy MG Lim

16

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

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

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

— มาโกโตะ
แหล่งที่มา

1

ฉันคิดว่าคุณเป็นจุดที่ดีจริงๆ ขอบคุณสำหรับความคิดเห็น.

+1 สำหรับการติดแท็ก ฉันทำงานด้วยตัวเองเกือบตลอดเวลา แต่ฉันติดแท็กการเผยแพร่ด้วยเหตุผลสองประการ 1) ใช้งานได้ดีกับเครื่องมือประวัติ git visual เพื่อแสดงว่าคอมมิชชันใดที่เป็นจริงในการผลิต 2) ใช้งานได้ดีกับเครื่องมือเช่น GitHub ที่สามารถแพ็คเกจรุ่นที่วางจำหน่ายโดยตรวจสอบการติดแท็กการคอมมิทและบรรจุลงในไฟล์ zip เพื่อการบริโภค

— nbering

9

ฉันเห็นภาวะที่กลืนไม่เข้าคายไม่ออกของคุณ ฉันก็มีเช่นกันจนกระทั่งฉันไม่เข้าใจสิ่งที่ฉันคาดเดาเกี่ยวกับนายเสมอ

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

จากเอกสาร / หนังสือของGit - การแยกสาขาของ Git

สาขา "มาสเตอร์" ใน Git ไม่ใช่สาขาพิเศษ มันเหมือนกับสาขาอื่น ๆ เหตุผลเดียวที่เกือบทุกที่เก็บมีหนึ่งคือคำสั่ง git init สร้างขึ้นโดยค่าเริ่มต้นและคนส่วนใหญ่ไม่รำคาญที่จะเปลี่ยนมัน

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

(dev) -> (qa) -> (stag) -> (prod)

นี่คือวิธีการที่คุณเปลี่ยนชื่อสาขาต้นแบบ

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

— Sumeet Pareek
แหล่งที่มา

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

6

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

หากคุณไม่มีความเห็นหลังการทบทวนโค้ดจะช่วยได้ (บ่อยครั้งที่คนที่มีระเบียบวินัยมากขึ้นจะต้องการความเห็นโค้ดต่อไป)

นั่นเป็นเหตุผลที่เรากำหนดค่า repo Git ของเรา (เราใช้ Gitlab) ว่ามีเพียงบางคนเท่านั้นที่สามารถรวมคำขอดึงและนักพัฒนาแต่ละคนจะได้รับส่วนตัวแยกต่างหากของ repo หลัก

ที่ช่วยแก้ปัญหาที่สอง:

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

— Aaron Digulla
แหล่งที่มา

1

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

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

พวกเขาจะเห็น (หลัก) -> (วางจำหน่าย) โดยอาจมีขั้นตอนกลางขั้นที่ 1,2 ซึ่งเป็นประโยชน์

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

วิธีแบบดั้งเดิมนั้นไม่ได้หมายความว่าจะต้องใช้เวลานานกว่าที่จะไม่มีการสร้างผลิตภัณฑ์ที่สมบูรณ์

ดังนั้นขั้นตอน "คลาสสิค" จะเป็น: (dev) -> (หน่วย) -> (การรวม) -> (ทดสอบ / qa) -> (การผลิต)

บทบาทของผู้รวมระบบคือ "ยอมรับ / ซื้อ" หน่วยที่วางจำหน่ายหรือปฏิเสธพวกเขาหากพวกเขาไม่ตรงกับความต้องการของรุ่นถัดไปที่จะมาถึง

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

จากประสบการณ์ของฉัน (ซึ่งส่วนใหญ่อยู่ในพื้นที่ของการใช้วิธีการ "คลาสสิก") วิธีการ "คลาสสิก" ทำงานได้ดีในโครงการจากประมาณ 4-50 คนในทีม

— BitTickler
แหล่งที่มา