แนวโน้มของสาขา“ พัฒนา” กำลังจะหายไป

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

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

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

มันมาจากความคิดของCIที่มีการรวมวันละหลายครั้ง

มีข้อดีข้อเสียของทั้งสอง

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

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

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

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

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

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

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

แอปพลิเคชันหรือซอฟต์แวร์ที่อัปเดตได้ง่ายอื่น ๆ ไม่มีข้อ จำกัด

อย่างไรก็ตามโปรดทราบว่า:

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

มีสองปรัชญาที่ฉันเคยเห็นในโครงการและฉันคิดว่าการเลือกเป็นเพียงเรื่องของรสนิยม:

1. กำหนด 'master' เป็นการนำออกใช้งานและพัฒนาในสาขา 'พัฒนา'

2. พัฒนาใน 'ต้นแบบ' และมีสาขาที่แตกต่างกันสำหรับการผลิตที่มั่นคง วิธีนี้เหมาะสมกว่าหากโครงการของคุณมีสาขาย่อยหลายสาขาในแต่ละครั้ง (เช่นสาขาที่ต้องการในปัจจุบันคือ Release-1.8 แต่คุณยังคงใช้ Release-1.7 อยู่)

ทั้งสองเป็นวิธีการทั่วไปและมีข้อดีข้อเสีย

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

หากพบข้อบกพร่องที่สำคัญในการผลิตในขณะที่ไม่สามารถปล่อยต้นแบบได้มันก็ง่ายพอที่จะชำระเงินแท็กและเริ่มสาขา "hotfixes-for-release-1.2.0" ใหม่จากที่นั่น แต่ควรจะค่อนข้างหายาก

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

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

...

ลองนึกภาพว่าผู้คนกำลังรวมตัวกันเป็นอาจารย์และมีรายงานข้อผิดพลาดในการผลิตซึ่งยากที่จะแก้ไขเพราะรหัสฐานสาขาหลักมีการเปลี่ยนแปลงอย่างมีนัยสำคัญ

นั่นไม่ใช่ GitHub Flow

นี่เป็นกระบวนการปรับใช้ / ผสาน Github Flow ตามลิงค์ของคุณ:

ปรับใช้

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

ผสาน

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

(เน้นเหมือง)

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

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

จำเป็นต้องมีวิธีการทดสอบคุณลักษณะหลายอย่างรวมคุณสมบัติหลายอย่างและปรับใช้เหมือนกัน ฉันใช้ 'bundle branch' (สาขาที่สร้างจากต้นแบบพร้อมกับฟีเจอร์การทดสอบพร้อมสาขาที่รวมเข้าไป) ที่ได้รับการปรับใช้กับ qa / uat การแก้ไขระหว่าง uat จะเกิดขึ้นในสาขาคุณลักษณะเท่านั้นและสิ่งเหล่านั้นจะถูกรวมเข้ากับสาขาของบันเดิล หลังจากส่วนย่อยของสาขาบันเดิลได้รับการอนุมัติเฉพาะฟีเจอร์ที่ได้รับการอนุมัติภายในบันเดิลเท่านั้นจะได้รับการร้องขอแบบดึงไปยังต้นแบบและวัฏจักรจะต่อเนื่อง

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

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

ปัญหาอื่นคือกระบวนการดึงคำขอเกิดขึ้นเมื่อสิ้นสุดก่อนที่จะรวมเข้ากับต้นแบบ อย่างไรก็ตามบางครั้งคุณต้องการตรวจสอบรหัสก่อนการทดสอบ qa ธุรกิจ - ดังนั้นก่อนทำการผสาน