Khi nào phụ thuộc nên được cập nhật?

Chúng tôi đã có hai cuộc khủng hoảng liên quan đến phụ thuộc lớn với hai cơ sở mã khác nhau (Android và ứng dụng web Node.js). Repo Android cần để di chuyển từ Flurry sang Firebase, yêu cầu cập nhật thư viện Google Play Services bốn phiên bản chính. Một điều tương tự đã xảy ra với ứng dụng Node được lưu trữ trên Heroku của chúng tôi, nơi ngăn xếp sản xuất của chúng tôi (tuyết tùng) không được dùng nữa và cần được nâng cấp lên cedar-14. Cơ sở dữ liệu PostgreSQL của chúng tôi cũng cần cập nhật từ 9.2 đến 9.6.

Mỗi sự phụ thuộc của các ứng dụng này đã bị trì hoãn trong gần hai năm và khi một số bị phản đối và chúng tôi đã đến thời kỳ 'hoàng hôn', việc cập nhật chúng hoặc thay thế chúng là một vấn đề đau đầu. Tôi đã dành hơn 30 giờ trong một hoặc hai tháng qua để giải quyết chậm tất cả các xung đột và mã bị hỏng.

Rõ ràng để mọi thứ ngồi trong hai năm là quá dài. Công nghệ di chuyển nhanh chóng, đặc biệt là khi bạn đang sử dụng một nhà cung cấp nền tảng như Heroku. Giả sử rằng chúng tôi có một bộ kiểm tra chính thức và quy trình CI như Travis CI, có rất nhiều phỏng đoán khi cập nhật. Ví dụ: nếu một chức năng đã bị xóa sau khi nâng cấp và bạn đang sử dụng nó, các thử nghiệm của bạn sẽ thất bại.

Bao lâu thì phụ thuộc nên được cập nhật, hoặc khi nào phụ thuộc nên được cập nhật? Chúng tôi cập nhật vì chúng tôi bị ép buộc, nhưng có vẻ như một cách tiếp cận ưu tiên nào đó sẽ tốt hơn. Chúng ta có nên cập nhật khi các phiên bản nhỏ được phát hành? Phiên bản chính? Mỗi tháng nếu cập nhật có sẵn? Tôi muốn tránh một tình huống như những gì tôi vừa trải qua bằng mọi giá.

Tái bút - đối với một trong các dự án Rails cá nhân của tôi, tôi sử dụng dịch vụ có tên Gemnasium để theo dõi các phụ thuộc của bạn để bạn có thể được thông báo về các lỗ hổng bảo mật. Đó là một dịch vụ tuyệt vời, nhưng chúng tôi sẽ phải kiểm tra thủ công các phụ thuộc cho các dự án tôi đã đề cập.

Bạn thường nên nâng cấp phụ thuộc khi:

1. Nó là bắt buộc
2. Có một lợi thế để làm như vậy
3. Không làm như vậy là bất lợi

(Đây không phải là loại trừ lẫn nhau.)

Động lực 1 ("khi bạn phải") là trình điều khiển khẩn cấp nhất. Một số thành phần hoặc nền tảng mà bạn phụ thuộc (ví dụ Heroku) yêu cầu nó và bạn phải xếp hàng. Yêu cầu nâng cấp thường xếp tầng ra khỏi các lựa chọn khác; bạn quyết định nâng cấp lên phiên bản PostgreSQL như vậy. Bây giờ bạn phải cập nhật trình điều khiển, phiên bản ORM của bạn, v.v.

Nâng cấp bởi vì bạn hoặc nhóm của bạn nhận thấy một lợi thế trong việc này là nhẹ nhàng hơn và tùy chọn hơn. Thêm một lời kêu gọi phán xét: "Tính năng mới, khả năng, hiệu suất, ... có xứng đáng với nỗ lực và trật khớp mang lại trong đó không?" Ở Olden Times, đã có sự thiên vị mạnh mẽ đối với các nâng cấp tùy chọn. Chúng là thủ công và cứng, không có cách nào tốt để thử chúng trong hộp cáthoặc môi trường ảo hoặc để khôi phục lại bản cập nhật nếu nó không hoạt động và không có kiểm tra tự động nhanh để xác nhận rằng các bản cập nhật không "làm đảo lộn giỏ hàng táo". Ngày nay, xu hướng thiên về các chu kỳ cập nhật nhanh hơn, tích cực hơn. Phương pháp nhanh nhẹn thích thử mọi thứ; trình cài đặt tự động, trình quản lý phụ thuộc và repos làm cho quá trình cài đặt nhanh và thường gần như vô hình; môi trường ảo và kiểm soát phiên bản phổ biến làm cho các nhánh, nhánh và rollback trở nên dễ dàng; và kiểm tra tự động cho phép chúng tôi thử cập nhật sau đó dễ dàng và đánh giá đáng kể "Nó có hoạt động không? Nó có làm hỏng việc gì không?" Xu hướng đã thay đổi bán buôn, từ "nếu nó không bị hỏng, đừng sửa nó" sang "cập nhật sớm, cập nhật thường xuyên"

Động lực 3 là mềm nhất. Câu chuyện của người dùng không liên quan đến "hệ thống ống nước" và không bao giờ đề cập đến "và giữ cho cơ sở hạ tầng không quá N phát hành phía sau bản hiện tại." Những nhược điểm của phiên bản trôi dạt (đại khái là nợ kỹ thuật liên quan đến việc tụt lại phía sau đường cong) lấn chiếm âm thầm, sau đó thường tự thông báo thông qua việc phá vỡ. "Xin lỗi, API đó không còn được hỗ trợ!" Ngay cả trong các nhóm Agile, khó có thể thúc đẩy chủ nghĩa gia tăng và "đứng đầu" sự mới mẻ của các thành phần khi nó không được coi là mấu chốt để hoàn thành một lần chạy nước rút hoặc phát hành. Nếu không ai ủng hộ việc cập nhật, họ có thể không được bảo vệ. Bánh xe đó có thể không kêu rít cho đến khi nó sẵn sàng để phá vỡ, hoặc thậm chí cho đến khi bị hỏng.

Từ góc độ thực tế, nhóm của bạn cần chú ý nhiều hơn đến vấn đề trôi dạt phiên bản. 2 năm là quá dài. Không có phép thuật. Đó chỉ là vấn đề "trả tiền cho tôi ngay bây giờ hoặc trả tiền cho tôi sau." Hoặc là giải quyết vấn đề trôi dạt phiên bản tăng dần, hoặc chịu đựng và sau đó vượt qua các cuộc đua lớn hơn cứ sau vài năm. Tôi thích chủ nghĩa gia tăng, bởi vì một số jolts nền tảng là rất lớn. API hoặc nền tảng chính mà bạn phụ thuộc vào việc không còn hoạt động thực sự có thể làm hỏng ngày, tuần hoặc tháng của bạn. Tôi muốn đánh giá độ tươi của thành phần ít nhất 1-2 lần mỗi năm. Bạn có thể lên lịch đánh giá một cách rõ ràng hoặc để chúng được kích hoạt một cách hữu cơ theo chu kỳ tương đối, thường là các chu kỳ cập nhật hàng năm của các thành phần chính như Python, PostgreQuery và node.js. Nếu các bản cập nhật thành phần không kích hoạt nhóm của bạn rất mạnh mẽ, hãy kiểm tra độ mới trên các bản phát hành chính, tại các cao nguyên dự án tự nhiên, hoặc mọi bản phát hành k cũng có thể hoạt động. Bất cứ điều gì đặt sự chú ý để sửa phiên bản trôi dạt trên một nhịp đều đặn hơn.

Thư viện nên được cập nhật khi chúng được yêu cầu cập nhật. Điều đó có nghĩa là, nếu cập nhật không mang lại giá trị, bạn không nên.

Trong trường hợp cụ thể của bạn, bạn đã di chuyển từ một ngăn xếp công nghệ cũ sang một kho công nghệ mới và để làm được điều đó, bạn buộc phải cập nhật các phụ thuộc của mình. Chính thời điểm đó là thời điểm chính xác để cập nhật các phụ thuộc.

Nếu bạn đã cập nhật các phụ thuộc của mình theo thời gian, để "không phải đau đầu bây giờ", bạn đã phải đầu tư rất nhiều thời gian làm việc (mã hóa) để không có giá trị trả về. Và khi bạn thực hiện bản cập nhật cuối cùng (bản hiện tại bạn đang làm, nhưng cập nhật 1 phiên bản chính thay vì 4), có lẽ bạn vẫn còn đau đầu ở đâu đó (sau tất cả, phiên bản chính có nghĩa là phá vỡ các thay đổi). Vì vậy, tôi nghĩ rằng bạn đang đi đúng hướng.

Tuy nhiên, nếu bạn thấy quá khó để di chuyển và phải thực hiện nhiều công cụ tái cấu trúc, rất có thể vấn đề nằm ở cơ sở mã của bạn. Điều khá phổ biến đối với các dự án Android là không có kiến ​​trúc tổng thể về cấu trúc mã. Một khung tiêm phụ thuộc tốt như Dagger 2 và một vài nguyên tắc công nghệ phần mềm như SOLID sẽ giúp việc thay đổi triển khai mã dễ dàng hơn trong khi vẫn giữ nguyên các hành vi / yêu cầu.

Ngoài ra, vì chúng tôi đang tái cấu trúc, hãy đọc một chút về Kiểm thử đơn vị, vì điều đó sẽ giúp ích rất nhiều khi thực hiện loại công việc này.

Nếu bạn đang sử dụng các công cụ quản lý gói (ví dụ: npm, NuGet) và có bộ kiểm tra tự động toàn diện thì việc nâng cấp phụ thuộc phải là một hoạt động ít nỗ lực, chỉ cần nâng cấp gói, chạy bộ kiểm tra của bạn và xem có vấn đề gì không. Nếu có thì rollback và nâng một mục công việc để điều tra và khắc phục vấn đề.

Miễn là chi phí nâng cấp phụ thuộc thấp, nó cũng đáng để cập nhật:

• Nếu có vấn đề với việc nâng cấp, bạn muốn biết sớm hơn là trong trường hợp cần thay đổi ngược dòng.
• Rời khỏi nâng cấp phụ thuộc đến phút cuối thường có nghĩa là bạn đang thực hiện những nâng cấp đó vào thời điểm khủng hoảng (ví dụ để đối phó với lỗi nghiêm trọng về bảo mật). Giữ trên đầu các phụ thuộc của bạn có nghĩa là bạn kiểm soát được khi bạn dành nỗ lực đó và có thể thực hiện các nâng cấp đó vào những lúc bạn không bận rộn.
• Các phiên bản mới hơn có thể có những cải tiến về năng suất, ví dụ như tài liệu tốt hơn, sử dụng API dễ dàng hơn, sửa lỗi (mặc dù điều ngược lại cũng có thể).

Nếu việc nâng cấp phụ thuộc không phải là nỗ lực thấp (ví dụ: vì bạn cần kiểm tra nâng cấp theo cách thủ công hoặc vì có sự cố / thay đổi đã biết) thì bạn phải cân nhắc những ưu và nhược điểm đối với các nhiệm vụ khác của mình. Phụ thuộc cũ là một loại nợ kỹ thuật lãi suất thấp, và do đó nên được xử lý phù hợp.

Bạn không nên thực hiện một bản phát hành khi bạn cố ý sử dụng các phiên bản cũ của các phụ thuộc của mình, trừ khi các phiên bản đó được hỗ trợ thay thế.

tức là nếu bạn đang ở trên V1 và nó vẫn được hỗ trợ, bạn vẫn có thể sử dụng phiên bản v1 mới nhất.

Thời gian duy nhất bạn nên hết hạn là nếu:

A: Bạn đã không thực hiện một bản phát hành trong một thời gian.

B: Bạn đã ở trên v1 quá lâu đến nỗi nó không còn được hỗ trợ

Các bản cập nhật được phát hành vì một lý do, chúng chứa các bản sửa lỗi bảo mật mà bạn nên thực hiện trên tàu.

Nếu một phiên bản mới của sự phụ thuộc của bạn xuất hiện, bạn cũng nên phát hành

Tôi nghĩ rằng nó phải phụ thuộc vào thư viện trong một chừng mực nào đó, nhưng bản thân tôi cũng bị đau đầu phụ thuộc tương tự.

Thông thường nói với tôi rằng một phiên bản chính có lẽ là thời điểm thích hợp để nâng cấp, và một phiên bản nhỏ giải quyết một lỗ hổng nghiêm trọng, hoặc bao gồm một lợi ích đáng kể sẽ thay thế điều đó.

Đôi khi chúng tôi không có hứng thú làm việc trên mọi ứng dụng cần bảo trì hoặc thậm chí không thực hiện một nhiệm vụ quan trọng nào, nhưng cuối cùng chúng sẽ cắn bạn và một ounce phòng ngừa thường đánh bại một pound thuốc chữa!

Thư viện nên được cập nhật khi cung cấp một lợi thế mà phần mềm của bạn sẽ sử dụng để bù đắp cho công việc đã bỏ ra trong thay đổi.

Ngay cả các nâng cấp phiên bản thư viện nhỏ cũng có thể phá vỡ hoặc chèn sự không nhất quán trong các ứng dụng. Từ quan điểm đó không có thay đổi nhỏ.

Không có sự xấu hổ trong việc sử dụng libs cũ. Khi thay đổi là cần thiết có thể đau đớn nhưng đó là một phần của công việc.