Từ kinh nghiệm trong quá khứ với cơ sở mã Big Ball Of Mud phát triển tự nhiên trong nhiều năm dưới bàn tay của nhiều nhà phát triển cơ sở không có giám sát, tôi muốn chỉ ra điều gì xảy ra khi bạn không thực hành CI với những nhà phát triển đó.
Chỉnh sửa / Cập nhật : Theo nhận xét của RubberDuck; câu trả lời này giả định rằng mục tiêu hợp nhất của bạn để tích hợp là một nhánh phát triển chứ không phải là một nhánh đánh giá hoặc phát hành.
- Rõ ràng cần phải có nhiều quyền kiểm soát hơn đối với mã để phát hành và triển khai trực tiếp; nếu không có một nhánh sản xuất riêng biệt thì sẽ đáng để xem xét thay đổi chiến lược hợp nhất / hợp nhất của bạn để chạy một nhánh phát triển tổng thể (được sử dụng để thử nghiệm tích hợp và không bao giờ được phát hành) cùng với nhánh phát hành chính. Điều này giữ cho tất cả các lợi ích của CI và hợp nhất thường xuyên mà không có nguy cơ phá vỡ mã sản xuất.
1. Các nhà phát triển trẻ ít có khả năng giao tiếp với đồng nghiệp hoặc người giám sát của họ
Tích hợp liên tục không chỉ đơn giản là vấn đề hợp nhất trong mã, đây là thời điểm mà theo đó một nhà phát triển buộc phải tương tác với các bên liên quan khác.
Giao tiếp rất quan trọng và không muốn khái quát quá mức, nó có xu hướng trở thành một kỹ năng được học ít đến với các nhà phát triển thiếu kinh nghiệm hơn so với những người đã từng làm việc trong môi trường nhóm.
Nếu bạn cho phép các nhà phát triển cơ sở ngồi trong tủ của họ và bash đi mã trong nhiều tuần mà không được yêu cầu báo cáo / đánh giá thường xuyên, thì nhiều khả năng họ sẽ tránh giao tiếp hoàn toàn.
2. Mã họ đang sản xuất có thể cần xem xét nghiêm ngặt hơn
Bạn đã bao giờ xem lại một cái gì đó tồi tệ đến mức bạn muốn bạn nhặt nó sớm hơn và ngăn nó không bao giờ được viết? Điều này xảy ra rất nhiều.
Bạn không thể ngăn chặn mã xấu được viết, nhưng bạn có thể hạn chế thời gian lãng phí. Nếu bạn cam kết đánh giá và sáp nhập thường xuyên, thì bạn sẽ giảm thiểu phạm vi lãng phí thời gian.
Trường hợp xấu nhất là bạn có thể để một nhà phát triển cơ sở một mình trong vài tuần cho dự án thu nhỏ của riêng họ và khi họ cuối cùng đã sẵn sàng để xem xét mã, đơn giản là họ không còn đủ thời gian để họ ném toàn bộ mớ hỗn độn đi và bắt đầu lại từ đầu.
Nhiều dự án trở thành một quả bóng lớn chỉ đơn giản vì toàn bộ tải mã xấu đã được viết khi không ai chú ý cho đến khi quá muộn.
3. Bạn nên ít chắc chắn rằng một nhà phát triển cơ sở hoặc thành viên nhóm mới khác đã hiểu các yêu cầu
Đôi khi một nhà phát triển có thể xây dựng giải pháp hoàn hảo cho vấn đề sai; Điều này thật đáng buồn bởi vì thường là những hiểu lầm đơn giản, điều này sẽ rất dễ tránh nếu chỉ có ai đó đã hỏi đúng câu hỏi trước đó trong quá trình.
Một lần nữa, đây là một vấn đề có nhiều khả năng ảnh hưởng đến các nhà phát triển thiếu kinh nghiệm, những người có nhiều khả năng chấp nhận các yêu cầu "xấu" theo mệnh giá thay vì đẩy lùi và đặt câu hỏi về sự khôn ngoan của yêu cầu.
4. Chúng dường như ít quen thuộc hơn với các mẫu phổ biến, với kiến trúc của mã hiện có và với các công cụ và giải pháp nổi tiếng
Đôi khi, một nhà phát triển dành toàn bộ thời gian để phát minh lại bánh xe một cách không cần thiết chỉ vì họ không biết rằng một giải pháp tốt hơn thậm chí còn tồn tại. Hoặc họ có thể mất nhiều ngày cố gắng đóng một cái chốt vuông vào một cái lỗ tròn mà không nhận ra mình đang làm gì sai.
Một lần nữa, loại điều này có nhiều khả năng xảy ra với các nhà phát triển thiếu kinh nghiệm, và cách tốt nhất để giải quyết vấn đề là đảm bảo đánh giá thường xuyên.
5. Khoảng thời gian dài giữa các lần xác nhận / hợp nhất mã khiến các lỗi khó xác định và sửa chữa hơn
Khi một lỗi xuất hiện ngay lập tức sau nhiều tuần thay đổi mã có giá trị đã được sáp nhập vào nhánh chính, thách thức xác định thay đổi nào có thể khiến lỗi trở nên khó khăn hơn.
Rõ ràng chiến lược phân nhánh tổng thể của bạn cũng đi vào chơi ở đây; lý tưởng là tất cả các nhà phát triển của bạn sẽ làm việc trong các nhánh riêng của họ hoặc trong các nhánh tính năng (hoặc cả hai) và sẽ không bao giờ làm việc trực tiếp với chủ / thân.
Tôi đã thấy các tình huống trong đó tất cả các đội đều làm việc trực tiếp với chủ / thân cùng một lúc và đây là một môi trường tồi tệ cho CI, nhưng may mắn thay, giải pháp kéo mọi người ra khỏi chủ / thân thường cung cấp đủ sự ổn định cho công việc cá nhân vật phẩm / vé / v.v.
Cần phải luôn luôn "OK" cho bất kỳ nhà phát triển nào để phá vỡ nhánh chính / thân cây, với sự hiểu rằng việc sáp nhập sẽ diễn ra thường xuyên như vậy, rằng việc phá vỡ các thay đổi và khiếm khuyết sẽ được xác định nhanh hơn và do đó cũng được giải quyết nhanh hơn. Các khiếm khuyết tồi tệ nhất thường là những khuyết điểm không bị phát hiện trong nhiều tháng hoặc thậm chí nhiều năm.
Tóm tắt; những lợi thế chính của tích hợp liên tục / triển khai liên tục là:
- Giao tiếp giữa các nhóm của bạn được cải thiện
- Chất lượng mã thường được duy trì ở tiêu chuẩn cao hơn
- Yêu cầu ít có khả năng bị bỏ lỡ hoặc giải thích sai
- Các vấn đề về kiến trúc và thiết kế nên được phát hiện nhanh hơn,
- Khiếm khuyết có nhiều khả năng được phát hiện và sửa chữa ở giai đoạn sớm hơn
Vì vậy, nếu bạn không thực hành CI với các nhà phát triển cơ sở, thì bạn đang chấp nhận rất nhiều rủi ro không cần thiết đáng kể, vì đây là những thành viên trong nhóm của bạn, những người cần nó nhiều hơn những người còn lại.
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- đó là ý kiến dựa trên;) IMHO khó khăn hơn nhiều để đảm bảo thành công với việc triển khai dịch vụ độc lập so với cách tiếp cận nguyên khối: softwareengineering.stackexchange.com/a/342346/187812 . Và với CI thực sự (không có nhánh tính năng / tích hợp), bạn không cần phải đợi một tuần.