จากประสบการณ์ที่ผ่านมากับฐานรหัสBig Ball Of Mudซึ่งพัฒนาขึ้นตามธรรมชาติในช่วงหลายปีที่ผ่านมาด้วยมือของผู้พัฒนารุ่นเยาว์ที่ไม่มีผู้ดูแลฉันอยากจะชี้ให้เห็นว่าเกิดอะไรขึ้นเมื่อคุณไม่ฝึก CI กับนักพัฒนาเหล่านั้น
แก้ไข / อัปเดต : ตามความคิดเห็นของ RubberDuck; คำตอบนี้อนุมานว่าเป้าหมายการผสานของคุณสำหรับการรวมเป็นสาขาการพัฒนามากกว่าสาขาการประเมินหรือสาขาการปล่อย
- เห็นได้ชัดว่าจำเป็นต้องมีการควบคุมโค้ดสำหรับการวางจำหน่ายและการใช้งานจริงมากขึ้น หากไม่มีสาขาการผลิตแยกต่างหากมันจะคุ้มค่าที่จะพิจารณาการเปลี่ยนแปลงกลยุทธ์การรวมสาขา / การควบรวมของคุณเพื่อเรียกใช้สาขาการพัฒนาหลัก สิ่งนี้จะช่วยให้คุณได้รับประโยชน์ทั้งหมดของ CI และการผสานบ่อยครั้งโดยไม่เสี่ยงกับรหัสการผลิตที่ผิดพลาด
1. ผู้พัฒนาเยาวชนมีโอกาสน้อยที่จะสื่อสารกับเพื่อนร่วมงานหรือหัวหน้างานของพวกเขา
การรวมอย่างต่อเนื่องไม่ได้เป็นเพียงเรื่องของการรวมเข้ากับโค้ด แต่เป็นจุดที่ผู้พัฒนาถูกบังคับให้ต้องโต้ตอบกับผู้มีส่วนได้เสียอื่น
การสื่อสารเป็นสิ่งสำคัญและหากไม่ต้องการพูดเกินจริงก็มีแนวโน้มที่จะเป็นทักษะที่เรียนรู้ซึ่งทำให้นักพัฒนาที่ไม่มีประสบการณ์น้อยลงอย่างเป็นธรรมชาติมากกว่าคนที่คุ้นเคยกับการทำงานในสภาพแวดล้อมแบบทีม
หากคุณอนุญาตให้นักพัฒนารุ่นเยาว์นั่งอยู่ในห้องเล็ก ๆ ของพวกเขาและทุบตีรหัสเป็นเวลาหลายสัปดาห์โดยไม่ต้องขอรายงาน / บทวิจารณ์บ่อยนักพวกเขามีแนวโน้มที่จะหลีกเลี่ยงการสื่อสารทั้งหมด
2. รหัสที่พวกเขาผลิตนั้นมีแนวโน้มที่จะต้องการการตรวจสอบที่เข้มงวดยิ่งขึ้น
คุณเคยตรวจสอบบางสิ่งที่แย่มากจนคุณอยากหยิบมันมาก่อนหน้านี้และป้องกันไม่ให้มันถูกเขียนขึ้นมา? มันเกิดขึ้นมากมาย
คุณไม่สามารถป้องกันรหัสที่ไม่ดีจากการเขียน แต่คุณสามารถ จำกัด เวลาที่สูญเปล่า หากคุณให้คำวิจารณ์และการรวมเป็นประจำคุณจะลดขอบเขตสำหรับเวลาที่สูญเปล่า
สถานการณ์ที่เลวร้ายที่สุดคือคุณอาจทิ้งนักพัฒนารุ่นเยาว์ไว้คนเดียวเป็นเวลาหลายสัปดาห์ในโครงการจิ๋วของพวกเขาเองและเมื่อพวกเขาพร้อมสำหรับการตรวจสอบโค้ดในที่สุดก็ไม่มีเวลาเหลือพอที่พวกเขาจะทิ้งระเบียบทั้งหมด ออกไปและเริ่มต้นอีกครั้งตั้งแต่เริ่มต้น
หลายโครงการกลายเป็นลูกโคลนขนาดใหญ่เพียงเพราะมีการเขียนโค้ดไม่ดีทั้งหมดเมื่อไม่มีใครสนใจจนกว่าจะสายเกินไป
3. คุณควรแน่ใจน้อยกว่าว่าผู้พัฒนารุ่นเยาว์หรือสมาชิกทีมใหม่คนอื่น ๆ เข้าใจข้อกำหนด
บางครั้งนักพัฒนาอาจสร้างโซลูชันที่สมบูรณ์แบบสำหรับปัญหาที่ผิด อันนี้เป็นเรื่องน่าเศร้าเพราะโดยทั่วไปมักจะเข้าใจผิดง่าย ๆ ซึ่งจะง่ายต่อการหลีกเลี่ยงหากมีใครบางคนถามคำถามที่ถูกต้องก่อนหน้านี้ในกระบวนการ
นี่เป็นปัญหาที่มีแนวโน้มที่จะส่งผลกระทบต่อนักพัฒนาที่ไม่มีประสบการณ์ซึ่งมีแนวโน้มที่จะยอมรับข้อกำหนด "ไม่ดี" ที่ราคาหน้าแทนที่จะเปลี่ยนกลับและตั้งคำถามเกี่ยวกับภูมิปัญญาของความต้องการ
4. พวกเขามีแนวโน้มที่จะไม่ค่อยคุ้นเคยกับรูปแบบทั่วไปกับสถาปัตยกรรมของรหัสที่มีอยู่และด้วยเครื่องมือและโซลูชันที่มีชื่อเสียง
บางครั้งนักพัฒนาซอฟต์แวร์ใช้เวลาโหลดทั้งหมดคิดค้นล้อใหม่โดยไม่จำเป็นเพียงเพราะพวกเขาไม่รู้ว่ามีวิธีแก้ปัญหาที่ดีกว่าเดิม หรือพวกเขาอาจใช้เวลาหลายวันในการพยายามตอกหมุดสี่เหลี่ยมเป็นรูกลมโดยไม่ทราบว่าพวกเขากำลังทำอะไรผิด
อีกครั้งสิ่งแบบนี้มีแนวโน้มที่จะเกิดขึ้นกับนักพัฒนาที่ไม่มีประสบการณ์และวิธีที่ดีที่สุดในการแก้ไขปัญหาคือให้แน่ใจว่ามีการตรวจสอบเป็นประจำ
5. ระยะเวลานานระหว่างการคอมมิท / การรวมรหัสทำให้เกิดข้อบกพร่องยากที่จะระบุและแก้ไข
เมื่อบั๊กเกิดขึ้นทันทีหลังจากรวมค่าการเปลี่ยนแปลงโค้ดหลายสัปดาห์เข้าในสาขาหลักความท้าทายในการระบุว่าการเปลี่ยนแปลงใดที่อาจทำให้บั๊กยากขึ้น
เห็นได้ชัดว่ากลยุทธ์การแยกสาขาโดยรวมของคุณก็มาที่นี่ด้วยเช่นกัน นักพัฒนาซอฟต์แวร์ของคุณทั้งหมดจะทำงานในสาขาของตนเองหรือภายในสาขาฟีเจอร์ (หรือทั้งสองอย่าง) และจะไม่ทำงานโดยตรงจากต้นแบบ / ลำต้น
ฉันเคยเห็นสถานการณ์ที่ทั้งทีมทำงานโดยตรงกับมาสเตอร์ / หีบในเวลาเดียวกันและนี่เป็นสภาพแวดล้อมที่เลวร้ายสำหรับ CI แต่โชคดีที่ทางออกของการดึงทุกคนออกจากมาสเตอร์ / trunk โดยทั่วไปมีความมั่นคงเพียงพอสำหรับการทำงานเดี่ยว รายการ / ตั๋ว / ฯลฯ
มันควรจะเป็น "ตกลง" สำหรับนักพัฒนาใด ๆ ที่จะทำลายสาขาหลัก / ลำต้นด้วยความเข้าใจว่าการผสานควรเกิดขึ้นเป็นประจำการเปลี่ยนแปลงที่ผิดพลาดและข้อบกพร่องควรระบุได้เร็วขึ้นและแก้ไขได้เร็วขึ้นด้วย ข้อบกพร่องที่เลวร้ายที่สุดมักเป็นข้อบกพร่องที่ตรวจไม่พบเป็นเดือนหรือเป็นปี
สรุป; ข้อได้เปรียบหลักของการรวมอย่างต่อเนื่อง / การปรับใช้อย่างต่อเนื่องคือ:
- การสื่อสารระหว่างทีมของคุณดีขึ้น
- โดยทั่วไปคุณภาพรหัสจะคงอยู่ในระดับที่สูงขึ้น
- ความต้องการมีโอกาสน้อยที่จะพลาดหรือตีความผิด
- ควรตรวจพบปัญหาสถาปัตยกรรมและการออกแบบได้เร็วขึ้น
- ข้อบกพร่องมีแนวโน้มที่จะถูกตรวจพบและแก้ไขในระยะก่อนหน้า
ดังนั้นหากคุณไม่ได้ฝึก CI กับนักพัฒนารุ่นน้องของคุณคุณก็ยอมรับความเสี่ยงที่ไม่จำเป็นอย่างมากเพราะสิ่งเหล่านี้คือสมาชิกในทีมของคุณที่ต้องการมากกว่าส่วนที่เหลือ
it is more scary to wait a week to deploy all micro services at once to make sure that everything works together, than to strictly enforce api versioning, write lots of automatic tests (...), and auto deploy to production as soon as your commit passes as tests on stage- ที่ความเห็นตาม;) IMHO มันยากมากที่จะให้ประสบความสำเร็จกับการใช้งานบริการอิสระกว่าด้วยวิธีการที่เสาหิน: softwareengineering.stackexchange.com/a/342346/187812 และด้วย CI จริง (ไม่มีสาขา / สาขาการรวม) คุณไม่ควรรอเป็นเวลาหนึ่งสัปดาห์