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

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

เฉพาะบางส่วน:

• GIT บน BitBucket
• Jenkins สำหรับการปรับใช้สคริปต์กับ Azure

สิ่งที่ฉันหวังไว้คือวิธีที่จะแยกคุณสมบัติเมื่อมันเคลื่อนที่ผ่านสภาพแวดล้อมและผลักดันสิ่งที่พร้อมจะแยงเท่านั้น

ดูเหมือนคุณจะมีปัญหาเล็กน้อยที่นี่:

1. การระบุคุณสมบัติสำหรับรุ่นเฉพาะ

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

2. กลยุทธ์การแตกแขนง

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

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

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

สาขา "Hotfix" หรือ "bugfix" เป็นส่วนสำคัญของกระบวนการนี้ ใช้พวกเขาสำหรับการแก้ไขครั้งเดียวที่มีขนาดเล็กที่มีรอบ QA สั้น ๆ

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

3. สภาพแวดล้อม

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

หากคุณมีสาขาฟีเจอร์มากกว่าหนึ่งสาขาที่ต้องได้รับการแยกต่างหาก แต่กำลังได้รับการทดสอบในเวลาเดียวกัน ..... ¯ \ _ (ツ) _ / ¯ .... หมุนเซิร์ฟเวอร์อื่นหรือไม่ อาจรวมพวกเขาเข้าด้วยกันเป็นสาขาทิ้ง ... กระทำการแก้ไข / เปลี่ยนแปลงสาขาเดิมและรวมเข้ากับสาขาทิ้งไป; ทำการอนุมัติขั้นสุดท้ายและ UAT ในแต่ละสาขาที่วางจำหน่าย

4. การลบคุณสมบัติที่ไม่ได้รับการอนุมัติจากสาขา

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

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

ขอให้โชคดี

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

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

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

ทำงานกองพะเนิน

นี่เป็นปัญหาสากลในประสบการณ์ของฉัน ฉันพูดกับ:

• การจัดการที่แข็งแกร่งของการเผยแพร่คุณสมบัติโดยเจ้าของผลิตภัณฑ์
• ตรวจสอบให้แน่ใจว่าสาขาถูกลบเมื่อรวมเข้าด้วยกัน
• จำกัด งานระหว่างทำ (โดย จำกัด คอลัมน์ในจิรา)
• ตรวจสอบตั๋วเก่าแบบเก่าทุกไตรมาสซึ่งมีทั้งแบบบั๊กและฟีเจอร์
• Retrospectives เพื่อหารือเกี่ยวกับองค์ประกอบของปัญหา
• กำลังใจอย่างต่อเนื่องสำหรับการตรวจสอบรหัสโดยทั้งหมด
• การจับคู่โอกาสในการแก้ไขปัญหาตั๋วและปัญหาที่ยาวนาน
• การประชุมรายไตรมาสเพื่อทบทวนและทำความสะอาดตั๋วเก่าให้หมด
• วิธีการทำงานเป็นทีมเพื่อรับ dev ผลิตภัณฑ์และ QA / QE ทำงานร่วมกันอย่างแน่นหนา
• การรายงานและเครื่องมือที่ดีในการทำให้คุณสมบัติของผลิตภัณฑ์ใหม่และงานในมือชัดเจน
• ตรวจสอบเซสชันเพื่อดูผ่านสาขาเก่าและลบทิ้ง

สาขา

คุณจำเป็นต้องมีสาขาเพื่อควบคุมกระบวนการดังกล่าว:

• คุณสมบัติ : สาขานี้เกิดจากต้นแบบ ใช้แอปพลิเคชันการจัดการโครงการเพื่อระบุสาขาฟีเจอร์แต่ละรายการด้วยงาน ตัวอย่างเช่นถ้าคุณใช้ TRAC คุณจะสิ้นสุดถ้าสาขาเช่น: 1234-user-crud, 1235-bug-delete-catalogฯลฯ ระบุการกระทำของคุณด้วยหมายเลขงานด้วยสิ่งนี้จะช่วยคุณได้มากเมื่อคุณมีปัญหาในการรวม (คุณจะ)
• ทดสอบ : ทุกสาขาคุณลักษณะที่ทำจะถูกรวมเข้ากับสาขาทดสอบ คุณไม่เคยรวมสาขาทดสอบลงในสาขาคุณลักษณะบางอย่างเพราะคุณไม่ต้องการรหัสจากคุณสมบัติอื่นที่ไม่ได้อยู่ในการผลิต (หลัก) เช่นเดียวกับreleaseสาขา
• ปล่อย : เมื่อคุณตัดสินใจว่าฟีเจอร์ใดที่ทดสอบได้ในการผลิตคุณจะรวมสาขานี้ (อีกครั้ง ... ) ในสาขานี้ คุณต้องทดสอบคุณลักษณะทั้งหมดอีกครั้งเนื่องจากการผสานนี้อาจทำให้เกิดปัญหาใหม่ เมื่อรีลีสทดสอบและเสร็จสิ้นแล้วคุณจะรวมสาขานี้เข้ากับมาสเตอร์และสร้างแท็กบนมาสเตอร์สำหรับเวอร์ชัน
• ต้นแบบ : มีรหัสการผลิตเท่านั้น

ดูการไหลของคอมไพล์:

                              |FEAT_2|
                                  |
                             .---C06<-------.---------.
                            /                \         \
                           /   |FEAT_1|        \         \
                          /       |            \         \
                         /    .--C07<--.--------\---------\---------.
                        /    /          \        \  |TEST| \         \
                       /    /            \        \    |    \         \
                      /    /        .-----`--C09<--`--C10    \         \ |RELEASE|
                     /    /        /                          \         \    |
    <v4.6.0>        /    /        /                       .----`--C11<---`--C12<--.
       |           /    /        /                       /                         \
C01<--C02<--C04<--´----´--------´-----------------------´---------------------------`--C13
 |           |                                                                          |
<v4.5.0>  <v4.6.1>                                                                   |MASTER|
                                                                                        |
                                                                                     <v4.7.0>

สภาพแวดล้อม

ง่ายมาก:

• ทดสอบ : สภาพแวดล้อมนี้ใช้สาขาทดสอบ
• รุ่น : สภาพแวดล้อมนี้ใช้สาขารุ่นจริง

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

ปัญหาที่เกิดขึ้น

ปัญหาที่ใหญ่ที่สุดในกระบวนการนี้คือการรวมกัน

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

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

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

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

IMHO กระบวนการที่เหมาะสมจะเป็น:

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

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

• ฉันไม่แน่ใจว่าคุณมีกลุ่ม Dev และ QA แยกกันหรือไม่ ถ้าเป็นเช่นนั้นตรวจสอบให้แน่ใจว่าทั้ง Dev และ QA อยู่ในการวางแผนการวิ่งและการประชุมประเมิน ที่หนึ่งใน บริษัท ที่ผ่านมาของฉันเราตรวจสอบให้แน่ใจว่าจำนวนของเรื่องราวที่เรามอบหมายให้กับเรื่องราวนั้นเป็นสาเหตุของการพัฒนาและการทดสอบ (ในทางทฤษฎีคุณอาจมีการประมาณการสองแบบแยกกันสำหรับความพยายาม dev และ QA แต่วิธีใดก็ตามที่คุณต้องการสำหรับการประเมินของคุณในการรวมทั้งสองอย่างเวลาที่จำเป็นสำหรับเรื่องราวเป็นเวลาที่ต้องใช้ในการส่งมอบจริง) แม้ว่าคุณจะไม่มีกลุ่มควบคุมคุณภาพ แต่ก็ยังต้องแน่ใจว่าคุณได้ทำการทดสอบในการประมาณของคุณแล้ว
• ตามเส้นเลือดที่คล้ายกันไปด้านบนตกลงล่วงหน้าว่ามีกี่เรื่องที่คุณจะรวมอยู่ในการวิ่ง จำนวนคะแนนเรื่องราวที่คุณยอมรับนั้นขึ้นอยู่กับจำนวนนักพัฒนาที่คุณสามารถทำได้ในการวิ่งของพวกเขาและจำนวนรายการที่ QA สามารถทดสอบในการวิ่งได้ (ฉันคิดว่าแน่นอนว่า QA sprints นั้นอยู่เบื้องหลัง Dev sprints แต่คุณสามารถปรับให้เข้ากับกระบวนการของคุณได้) หากนักพัฒนาของคุณสามารถทำคะแนนได้ครบ 200 คะแนน แต่ QA ของคุณสามารถทำคะแนนได้แค่ 150 คะแนนเท่านั้นแน่นอนว่าคุณสามารถทำได้เพียง 150 คะแนนก่อนที่งานจะเริ่ม "กองพะเนิน" และจบลงด้วยกรณีที่คุณอธิบาย (ในกรณีเช่นนี้คุณอาจต้องการตรวจสอบสาเหตุของสิ่งกีดขวางบนถนนเพื่อพยายามบรรเทา)
• ไม่มีใครผลักดันอะไรไปยัง QA จนกว่าทุกอย่างใน QA จะได้รับการทดสอบและส่งมอบและการส่งมอบ
• คุณสมบัติที่สมบูรณ์คือสิ่งที่ได้รับการทดสอบและส่งมอบ ถ้ามันไม่ได้ส่งมันไม่ได้ทำ
• เห็นได้ชัดว่าคุณต้องการที่จะลองทำตามตารางเวลาที่แน่นอน หนึ่งในแนวคิดทั้งหมดที่อยู่เบื้องหลังการผนวกรวมอย่างต่อเนื่องและความคล่องตัวคือการวนซ้ำ ตามคำนิยามการทำซ้ำหมายถึงการจัดส่งบ่อยครั้ง การผสานรวมและการจัดส่งเป็นประจำช่วยลดความเสี่ยงของแต่ละรายการได้

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

ในการสรุป: ส่งมอบให้กับ QA เมื่อคุณทำการทดสอบและส่งมอบฟีเจอร์เก่าเท่านั้น

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

ไม่สำคัญว่าการกระทำในภายหลังในสาขาเดียวกันจะยังไม่ได้ทดสอบ