นักพัฒนาถูกบล็อกโดยรอรหัสเพื่อรวมจากสาขาอื่นโดยใช้ GitFlow


17

ทีมของเราเพิ่งเปลี่ยนจาก FogBugz & Kiln / Mercurial เป็น Jira & Stash / Git เรากำลังใช้โมเดล Git Flow สำหรับการแยกสาขาเพิ่มสาขาย่อยย่อยออกจากสาขาคุณลักษณะ (เกี่ยวข้องกับงานย่อย Jira ของคุณสมบัติ Jira) เรากำลังใช้ Stash เพื่อกำหนดผู้ตรวจสอบเมื่อเราสร้างคำขอดึงเพื่อรวมกลับเข้าไปในสาขาหลัก (โดยปกติจะพัฒนา แต่สำหรับงานย่อยกลับเข้าไปในสาขาคุณลักษณะ)

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

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

ฉันรู้ว่านี่ไม่จำเป็นต้องเป็นปัญหา Git - มันเกี่ยวกับการทำงานกับการพึ่งพาซึ่งกันและกันของรหัสในหลายสาขาผสมผสานกับกระบวนการทำงานและวัฒนธรรมของเราเอง หากเราไม่มีนโยบายการตรวจสอบรหัสที่เข้มงวดสำหรับการพัฒนา (สาขาการรวมที่แท้จริง) นักพัฒนา 1 สามารถผสานเพื่อพัฒนาสำหรับนักพัฒนา 2 เพื่อดึงจาก ความซับซ้อนอีกประการหนึ่งคือเราต้องทำการทดสอบเบื้องต้นเป็นส่วนหนึ่งของกระบวนการตรวจสอบโค้ดก่อนส่งคุณสมบัติไปยัง QA ซึ่งหมายความว่าแม้ว่าผู้พัฒนา front-1 1 จะดึงโดยตรงจากสาขานักพัฒนา back-end 2 เนื่องจากพวกเขา ไปถ้าผู้พัฒนาแบ็คเอนด์ 2 เสร็จสิ้นและคำขอดึงของเขาอยู่ในการตรวจสอบโค้ดเป็นเวลาหนึ่งสัปดาห์แล้วนักพัฒนาฟรอนต์เอนด์ 2 ในทางเทคนิคไม่สามารถสร้างคำขอการดึง / การตรวจสอบโค้ดของเขาได้เพราะผู้ตรวจสอบรหัสของเขา / เธอไม่สามารถ ทดสอบเพราะนักพัฒนาซอฟต์แวร์ส่วนหลัง 2 '

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

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


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

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

คำตอบ:


11

ปัญหาอาจอยู่ในการแยกงานที่เข้มงวดเกินไประหว่างแบ็คเอนด์และการพัฒนาฟรอนต์เอนด์

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

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


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

6
แม้ว่านี่จะไม่ได้เป็นส่วนหนึ่งของกระบวนการพัฒนาของคุณนี่เป็นค่าใช้จ่ายพิเศษมากกว่าการมีนักพัฒนาสองคนทำนิ้วหัวแม่มือของพวกเขาเป็นเวลาสามวันเพื่อรอคนอื่น ๆ ให้ยอมรับรหัสของพวกเขาหรือไม่? คุณเสียเวลานักพัฒนา 8 ชั่วโมงต่อ thumb-twiddler เปรียบเทียบกับเวลาที่ใช้ในการเริ่มต้นอ้างอิงส่วนหลัง
Greg Burghardt

5

ปัญหาของคุณ: นักพัฒนา A สาขาจาก Master นักพัฒนา B จาก Master ทั้งทำงานเกี่ยวกับคุณสมบัติที่เกี่ยวข้องอย่างใกล้ชิดและความจริงที่หลีกเลี่ยงไม่ได้ว่าการรวมเข้ากับสาขา Master นั้นยากเนื่องจากความขัดแย้งที่หลีกเลี่ยงไม่ได้คือสิ่งที่ทำให้ทุกคนกลับมา

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


0

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

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


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

0

สิ่งหนึ่งที่คุณสามารถทำได้เพื่อช่วยให้สถานการณ์นั้นดูที่วิธีที่สั้นลงรอบการพัฒนา

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

มีวิธีที่จะแยกคุณสมบัติออกเป็นหน่วยงานเล็ก ๆ เพื่อให้วงจรการรวมทำงานต่อไปได้หรือไม่?

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


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