Làm thế nào để giữ cho thư viện bên thứ ba của bạn cập nhật?

Giả sử tôi có một dự án phụ thuộc vào 10 thư viện và trong thân cây dự án của tôi, tôi có thể sử dụng bất kỳ phiên bản nào của các thư viện đó. Vì vậy, tôi bắt đầu với các phiên bản gần đây nhất. Sau đó, mỗi thư viện sẽ nhận được cập nhật mỗi tháng một lần (trung bình). Bây giờ, giữ cho thân cây của tôi hoàn toàn cập nhật sẽ yêu cầu cập nhật một tài liệu tham khảo thư viện cứ sau ba ngày.

Điều này rõ ràng là quá nhiều. Mặc dù thông thường phiên bản 1.2.3 là phiên bản thay thế thả xuống cho phiên bản 1.2.2, bạn không bao giờ biết nếu không thử nghiệm. Các bài kiểm tra đơn vị không đủ; nếu đó là công cụ DB / tệp, bạn phải đảm bảo rằng nó hoạt động đúng với các tệp được tạo bằng các phiên bản cũ hơn và có thể ngược lại. Nếu nó có liên quan đến GUI, bạn phải kiểm tra trực quan mọi thứ. Và như vậy.

Làm thế nào bạn có thể xoay xở được chuyện này? Một số cách tiếp cận có thể:

• Nếu nó không bị hỏng, đừng sửa nó . Vẫn với phiên bản thư viện hiện tại của bạn miễn là bạn không nhận thấy bất cứ điều gì sai với nó khi được sử dụng trong ứng dụng của bạn, bất kể nhà cung cấp thư viện có xuất bản cập nhật thường xuyên như thế nào. Thay đổi gia tăng nhỏ chỉ là lãng phí.
• Cập nhật thường xuyên để giữ thay đổi nhỏ. Vì bạn sẽ phải cập nhật một ngày nào đó trong mọi trường hợp, tốt hơn hết là nên cập nhật thường xuyên để bạn sớm nhận thấy bất kỳ sự cố nào khi dễ khắc phục, thay vì nhảy qua một số phiên bản và để các vấn đề tiềm ẩn tích lũy.
• Một cái gì đó ở giữa. Có một điểm ngọt ngào?

Tôi bị sốc - và thực sự kinh hoàng - với số lượng câu trả lời ở đây nói rằng "không cập nhật trừ khi bạn phải". Tôi đã làm điều đó, và trong khi nó dễ dàng hơn trong thời gian ngắn, nó sẽ cháy như địa ngục trong thời gian dài. Thường xuyên hơn, các bản cập nhật nhỏ hơn rất nhiều, dễ quản lý hơn nhiều so với các bản cập nhật lớn thường xuyên và bạn sẽ nhận được lợi ích của các tính năng mới, sửa lỗi, v.v. sớm hơn.

Tôi không mua ý tưởng này rằng các thay đổi thư viện bằng cách nào đó khó kiểm tra hơn thay đổi mã. Điều này cũng tương tự - bạn đang thực hiện thay đổi đối với cơ sở mã và bạn cần xác thực nó trước khi bạn cam kết và sâu hơn trước khi phát hành. Nhưng bạn phải có quy trình để thực hiện việc này, vì bạn đang thực hiện thay đổi mã!

Nếu bạn đang làm việc trong các lần lặp, dài từ hai đến bốn tuần, tôi sẽ khuyên bạn nên cập nhật thư viện một lần cho mỗi lần lặp, để được thực hiện càng sớm càng tốt sau khi bắt đầu, khi mọi thứ thoải mái hơn một chút so với trước khi lặp thời hạn, và dự án có nhiều khả năng để hấp thụ thay đổi. Để ai đó (hoặc một cặp nếu bạn lập trình cặp) ngồi xuống, xem xét các thư viện đã được cập nhật và thử đưa từng người vào và chạy xây dựng lại và kiểm tra. Ngân sách nửa ngày đến một ngày cho mỗi lần lặp, có lẽ. Nếu mọi thứ hoạt động, hãy kiểm tra các thay đổi (tôi giả sử bạn giữ các thư viện kiểm soát nguồn, như chúng tôi vẫn làm; tôi không chắc chắn cách bạn truyền bá thay đổi theo cách được kiểm soát nếu không). Điều này rõ ràng sẽ dễ dàng hơn rất nhiều nếu bạn có các bài kiểm tra tự động so với việc kiểm tra hoàn toàn thủ công.

Bây giờ, câu hỏi là bạn sẽ làm gì nếu một bản cập nhật phá vỡ mọi thứ - bạn có dành thời gian để sửa nó hay bỏ nó đi không? Tôi muốn đề nghị nghiêng về phía sau; Nếu nó có thể được sửa trong một giờ, hãy thực hiện nó, nhưng nếu một bản cập nhật sẽ mất nhiều công sức quan trọng để tích hợp, thì hãy nâng nó thành nhiệm vụ phát triển của riêng nó, để được ước tính, ưu tiên và lên lịch như mọi thứ khác. Cơ hội là trừ khi nó mang lại một số sửa chữa hoặc cải tiến rất quan trọng, mức độ ưu tiên sẽ thấp và bạn sẽ không bao giờ đạt được điều đó. Nhưng bạn không bao giờ biết, vào thời điểm ngày cập nhật lặp đi lặp lại tiếp theo, vấn đề có thể đã tự khắc phục; ngay cả khi không, ít nhất là bây giờ bạn biết rằng có một rào cản trên đường cập nhật và nó sẽ không làm bạn ngạc nhiên.

Nếu bạn không thực hiện các bước lặp đó, tôi sẽ thiết lập một số loại lịch độc lập để cập nhật - không dài hơn hàng tháng. Có một số nhịp điệu dự án khác mà bạn có thể ràng buộc nó, như đánh giá tình trạng hàng tháng, hoặc một cuộc họp hội đồng kiến ​​trúc? Ngày trả lương? Pizza đêm? Trăng tròn? Dù thế nào đi nữa, bạn cần tìm ra thứ gì đó ngắn hơn nhiều so với chu kỳ phát hành truyền thống, bởi vì cố gắng cập nhật mọi thứ trong một lần cứ sau 6-18 tháng sẽ trở nên đau đớn và mất tinh thần.

Không cần phải nói, nếu bạn làm các nhánh ổn định trước khi phát hành, bạn sẽ không áp dụng chính sách này cho họ. Ở đó, bạn chỉ cập nhật các thư viện để nhận các bản sửa lỗi quan trọng.

Tôi đánh giá.

• Đầu tiên tôi tìm kiếm các lỗi mà chúng tôi đã gây ra đối với thư viện đó và xem chúng đã được sửa chưa.
• Thứ hai, tôi tìm kiếm bất kỳ sửa lỗi nào khác trong lib mà chúng ta có thể hưởng lợi (có lẽ đó là một trường hợp góc có thể xảy ra).
• Thứ ba, tôi tìm kiếm các cải tiến trong lib / API và sau đó điều tra tác động của việc thay đổi mã của chúng tôi để sử dụng điều đó và sự đánh đổi benfit. Tôi đã quá thường xuyên trong các bản nâng cấp lib trước đây mà không thực sự sử dụng các tính năng mới của chúng, thật ngớ ngẩn!

Sau đó tôi cân nhắc tất cả những điều đó chống lại việc ở lại với lib hiện có.

Luôn kiểm tra - hy vọng các bài kiểm tra đơn vị / tích hợp của bạn sẽ đảm bảo rằng không có hồi quy lớn nào xảy ra.

Vấn đề chính với các thư viện bên thứ ba, là bạn cần kiểm tra lại ứng dụng CỦA BẠN khi bạn cập nhật chúng, trước khi nó có thể đi vào sản xuất. Vì vậy, trừ khi bạn có một lỗi được báo cáo, yêu cầu cập nhật thư viện, bạn không chạm vào chúng cho đến khi bạn có thời gian để thực hiện một chu trình đảm bảo chất lượng hoàn chỉnh.

Điều này thường được thực hiện khi phát hành một phiên bản mới.

Tuy nhiên, tôi sẽ đề nghị bạn nên có một bộ kiểm tra để xây dựng liên tục cho phép bạn cập nhật các thư viện trong nhánh phát triển và thực hiện tự động. Điều này sẽ đảm bảo rằng bạn phát hiện sớm khi nó bị hỏng, vì vậy bạn có thể gửi bugreports cho dự án.

Một phần, như được mô tả trong các chi nhánh nhà cung cấp svn . Quy trình được mô tả ở đây rất hữu ích, khi bạn tiếp tục sử dụng các thư viện bên thứ ba nguồn mở trong một thời gian dài và đã thực hiện các thay đổi để điều chỉnh nó theo nhu cầu của bạn.

Tôi sẽ nghĩ về việc cập nhật tất cả các thư viện của một dự án ngay trước hoặc ngay sau khi phát hành. Tuy nhiên, điều này có thể vượt khỏi tầm kiểm soát nếu bạn dựa vào hơn 10 hoặc 15 thư viện, trong trường hợp đó một loại cơ chế kiểm tra cập nhật sẽ giúp ích rất nhiều. Ưu điểm của việc này là bạn có thời gian dành riêng để kiểm tra thư viện của mình và có thể khắc phục mọi sự cố trong một lần. Bạn cũng không phải liên tục theo dõi các cập nhật từ mỗi thư viện, bạn chỉ cần kiểm tra vào một ngày nhất định cho bất kỳ cập nhật nào.

Tôi cũng sẽ chống lại bất kỳ loại tính năng cập nhật tự động nào trong một nhánh dev. Sẽ thật bực bội nếu giữa tôi đang làm việc với một thứ gì đó mà dự án bị phá vỡ vì tự động thư viện tự cập nhật hoặc tôi bất ngờ nhận được cảnh báo Khấu hao vì đã sử dụng API bị thay thế bởi thứ khác.

Bạn phải hỏi, bạn thực sự muốn gì từ bản cập nhật? Hầu hết các bản sửa lỗi bảo mật thực sự là các bản vá tầm thường, dưới dạng sửa lỗi:

• Tắt bởi một lỗi trong đó mã tùy ý có thể được sao chép vào một không gian không sử dụng trong bộ đệm
• Con trỏ lơ lửng, hoặc một cái gì đó khác kích hoạt hành vi không xác định nhưng (đúng hơn)
• Lỗi cho phép một số loại DoS
• Lỗi vô tình làm cho việc rình mò dữ liệu riêng tư dễ dàng
• Sai lầm toán học
• Các nhà bảo trì chạm vào những thứ họ không nên (lỗi SSL Debian, có ai không?)

Nếu bạn xem qua hầu hết các CVE trong năm năm qua, các bản vá sửa chúng thường khá tầm thường, nếu bạn đang sử dụng các thư viện mở, tôi hy vọng bạn là như vậy.

Sau đó, bạn có sửa lỗi thực tế, mà bạn có thể muốn, nhưng có lẽ bạn đã tự sửa nó. Nếu nó không bị hỏng, đừng sửa nó.

Cuối cùng, bạn có các tính năng mới .. và có lẽ các tính năng không dùng nữa. Bạn cần kiểm tra những ghi chú phát hành và khác biệt cẩn thận. Bạn có thể sử dụng chúng, ngay cả khi chúng phá vỡ một API mà nhiều thứ khác phụ thuộc vào không? Nếu có, đã đến lúc phẫu thuật .. nếu không, anh đào chọn những gì bạn muốn và tiếp tục.

Một số có thể không đồng ý với tôi, nhưng tôi từ chối sử dụng thư viện mà không có mã nguồn.

Nó khác nhau tùy thuộc vào những thứ như trên thư viện, chúng được sử dụng cho mục đích gì, mức độ phổ biến của chúng trong mã của bạn, chi phí (về thời gian và tiền bạc) khi thực hiện nâng cấp, v.v.

Lý tưởng nhất là bạn sẽ luôn có bản mới nhất mọi lúc, nhưng nếu phiên bản mới không tương thích ngược thì sao? Bạn có thể phải tạm gác bản cập nhật đó để phát hành trong tương lai cho đến khi bạn có thể xử lý thay đổi một cách cẩn thận. Có thể có một số thay đổi tinh vi trong hành vi (chẳng hạn như "bây giờ bạn cần đặt thuộc tính X trước khi gọi phương thức Y hoặc bạn bị rò rỉ bộ nhớ chậm") rất khó xác minh khi kiểm tra.

Mặt khác, phiên bản mới có thể có một số sửa lỗi bảo mật nghiêm trọng, vì vậy bạn cũng phải tính đến điều đó.

Phiên bản ngắn: mang nó trên cơ sở từng trường hợp.

Điều này sẽ phụ thuộc vào shedules phát hành của bạn.

Nhưng lời khuyên của tôi sẽ là cài đặt một bộ thư viện trên tất cả các máy của nhà phát triển. Hãy coi nó là một tiêu chuẩn vàng nếu bạn muốn gọi nó là một cái gì đó, sau đó bắt đầu bạn phát triển cho bản phát hành đó.

Chỉ khi bản phát hành được triển khai và bạn đang trong giai đoạn phát hành bài, hãy đánh giá lại các thư viện, phiên bản và tính năng của chúng. Nếu họ cung cấp một số cải tiến đáng kể hoặc chức năng mới thì hãy cài đặt trước khi bắt đầu chu kỳ phát triển tiếp theo.

Chỉ cài đặt các phiên bản mới nếu có vấn đề lớn hoặc lỗi phải được sửa trước khi triển khai phần mềm.

Điều đó có nghĩa là bạn sẽ bỏ lỡ một số phiên bản nhưng nó sẽ giúp tiết kiệm một số vấn đề đau đầu và phiên bản cho phép bạn tập trung phát triển ứng dụng của mình.

Subversion Externals

Điều tuyệt vời ở tính năng đó là bạn có thể chỉ định bản sửa đổi mà bạn muốn.

Xin lưu ý rằng các cập nhật sẽ chậm hơn nếu bạn có nhiều bên ngoài.

Tôi hiện đang thiết lập một cái gì đó như thế:

• 1 repo đồng bóng cho mỗi phần mở rộng ứng dụng của tôi
• một repo đồng bóng thu thập các phiên bản cụ thể của một số thư viện bên thứ 3
• một repo SVN cho tài nguyên / tác phẩm đồ họa (nhưng có thể thay đổi thành thứ khác)
• một repo đồng bóng cho ứng dụng của tôi, sử dụng tính năng thay thế phụ trợ để sử dụng phiên bản cụ thể của repo pary thứ 3 và một số tiện ích mở rộng cơ bản

Bây giờ khi tôi cần làm việc với một tiện ích mở rộng không "cơ bản" (hoàn toàn được bao gồm dưới dạng một phần phụ trong repo ứng dụng), tôi chỉ cần sao chép repo trong thư mục tiện ích mở rộng và để CMake tạo dự án và giải pháp cho toàn bộ ứng dụng.

Bằng cách đó, tôi có thể:

• thay đổi bên thứ 3 trong một bản sao, kiểm tra xem nó có hoạt động với ứng dụng không, đẩy nó trong repo pary thứ 3, sau đó cập nhật phiên bản subrepo của repo ứng dụng lên phiên bản repo của bên thứ 3 mới
• làm việc trên các phần mở rộng một cách độc lập, tất cả cùng nhau hoặc chỉ chọn một số cụ thể
• không phải lo lắng về việc phải liên kết các dự án với nhau, điều này được thực hiện bởi Cmake chỉ bằng cách quét các dự án được quét với toàn bộ repo ứng dụng.

Chưa có nhiều kinh nghiệm với tổ chức này, nhưng tôi nghĩ điều đó khá hữu ích.

Nếu phần mềm của bạn quan trọng về bảo mật, bạn phải cập nhật càng sớm càng tốt, không có lý do. Bạn không muốn có một lỗi nhỏ trong thư viện đồ họa để làm cho toàn bộ chương trình của bạn dễ bị tổn thương.

Mặt khác, khi lib đã trưởng thành, đó là "Nếu nó không bị hỏng, đừng sửa nó." cho tôi. Sớm hay muộn, tôi có thể cần một tính năng của phiên bản mới hơn và không có lựa chọn nào khác ngoài việc cập nhật, nhưng cho đến khi đó, nỗ lực này rất khó để biện minh. Mặt khác, khi tôi làm việc với một lib hoặc khung tương đối mới, như Grails hoặc ExtJS, tôi luôn cập nhật phiên bản mới nhất vì những sản phẩm này chưa cảm thấy hoàn toàn trưởng thành, vì vậy việc cập nhật có thể giúp tôi tiết kiệm từ việc chạy vào một trong những lỗi đó, phiên bản mới hơn đã được sửa.

Tôi sử dụng NuGet để cập nhật thư viện bên thứ ba của mình.

Khi một người bạn, đồng nghiệp hoặc blog thông báo cho tôi rằng một trong các DLL của bên thứ 3 của tôi đã hết hạn, NuGet làm cho nó rất dễ dàng để cập nhật nó.