Một quy trình làm việc Node.js tốt để giữ cho các gói cập nhật?


8

Gần đây tôi đã bắt đầu phát triển một dự án trong Node.js. Tất nhiên, ngay bây giờ các gói tôi đang sử dụng khá cập nhật khi tôi bắt đầu sử dụng phiên bản mới nhất, nhưng có tỷ lệ doanh thu phiên bản khá cao đối với hầu hết các gói Node.js và thường các tính năng nhất định sẽ là không dùng nữa hoặc bị loại bỏ và tất nhiên các lỗ hổng bảo mật sẽ được sửa chữa.

Vì hầu hết các gói của tôi được chỉ định sử dụng cú pháp phiên bản ngữ nghĩa ^1.2.3(bám vào số phiên bản chính đã cho để tránh phá vỡ các thay đổi), mọi cập nhật quan trọng ngoài phiên bản chính hiện tại sẽ bị mất.

Một cách thận trọng để đảm bảo rằng bạn luôn cập nhật hợp lý với các phụ thuộc của bạn là gì? Có cần thiết phải đặt một kiểm tra hàng tuần để cập nhật các phụ thuộc của bạn vào quy trình làm việc của bạn để đảm bảo bạn không bị tụt lại phía sau không? Và vì lý do này, nó sẽ là một ý tưởng tốt để thử và giảm thiểu sự phụ thuộc để giảm thiểu nỗi đau của việc xử lý các thay đổi khi bạn nhất thiết phải cập nhật lên các phiên bản chính mới hơn?


1. Nhận biết về bản cập nhật gói, 2. Đánh giá các thay đổi được thực hiện trong bản cập nhật, 3. Quyết định xem các thay đổi có hữu ích và phù hợp với dự án của bạn không. Nếu có, thì 4. Nâng cấp gói lên phiên bản mới.
Robert Harvey

@Robert Harvey. Dự án nút đơn giản của tôi sử dụng trực tiếp khoảng một chục gói chính, có thể là một trăm gián tiếp. Cách tiếp cận của bạn không quy mô. Đây là một câu hỏi hay để kiểm tra xem có cách nào dễ dàng hơn, tự động hơn không.
user949300

1
@Jez, bạn đã xem npm-check-update hay npm outdatedlệnh chưa? Không bao giờ sử dụng bản thân mình nhưng chúng trông giống như một sự khởi đầu.
user949300

Nếu bạn đang sử dụng GitHub, bạn có thể muốn thử một cái gì đó như Greenkeeper sẽ chạy thử nghiệm với các phiên bản mới của phần phụ thuộc của bạn.
Whymarrh

Câu trả lời:


6

Đây là quy trình công việc mà tôi hiện đang sử dụng cho một dự án với các bản phát hành hàng tháng.

  • Sau khi phát hành, đi qua các phụ thuộc và cập nhật những phụ thuộc chỉ có thay đổi nhỏ và cập nhật bản vá. Vì npm tuân theo phiên bản ngữ nghĩa, nếu các tác giả của các gói đã làm tốt công việc của họ, điều này sẽ không phá vỡ hệ thống của bạn.
  • Thực hiện kiểm tra khói và nếu có bất kỳ sự phụ thuộc nào bị phá vỡ, hãy tạo một nhiệm vụ để phát triển để cập nhật sự phụ thuộc đó. Nó có thể là một vé, nó có thể là một nhiệm vụ cho chạy nước rút của bạn, vv Điểm quan trọng là việc cập nhật những người không ngay lập tức và sẽ yêu cầu công việc, vì vậy bạn phải lên lịch trình. Bất kỳ thông tin phản hồi từ lần thử đầu tiên của bạn sẽ giúp ích.
  • Lên lịch các nhiệm vụ để cập nhật các phụ thuộc có thay đổi lớn.
  • Đóng băng phụ thuộc của bạn vào các phiên bản mới nhất.

Mục tiêu là không có cập nhật tự động nào cả. Họ có thể phá vỡ hệ thống của bạn theo cách mà bạn không mong đợi và rất có thể khi bạn thực hiện các thay đổi khác, điều này sẽ không giúp tìm ra vấn đề là gì.

Cập nhật các phụ thuộc phải là một quá trình có ý thức và nếu bất kỳ trong số chúng phá vỡ hệ thống của bạn, bạn nên biết về cái nào.

Các bản cập nhật nhỏ bị hỏng và không được chú ý có thể sẽ được chọn trong giai đoạn phát triển hoặc thử nghiệm của bạn, và đây là lý do tại sao bạn làm điều đó sau khi phát hành, vì bạn muốn có nhiều thời gian để phát hiện và phản ứng với vấn đề đó trước khi đi vào hoạt động.

Lưu ý rằng tôi thực sự sử dụng quy trình này trong dự án phụ thuộc .NET + Nuget, nhưng nó áp dụng khá nhiều cho Node và npm / bower, Rails + bundle, v.v.

Cuối cùng, bạn có thể sử dụng các lệnh hay sẽ giúp bạn trong việc đóng băng / giải phóng các phụ thuộc, thậm chí thêm chúng vào repo của bạn. Xem npm shrinkwrap.


0

Tôi sử dụng một giải pháp khác với cách tiếp cận khác https://uptodatenpm.com nó sẽ gửi cho bạn một bản tin hàng tuần với thông tin về các phiên bản mới của các phụ thuộc dự án của bạn để bạn có thể quyết định nên cập nhật thông tin nào.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.