Tại sao kích thước xây dựng là một mối quan tâm như vậy?

Tôi thường nghe (từ mọi người, nhưng cũng từ CLI thông tin) rằng "kích thước xây dựng / sên là lớn". Điều này đặc biệt như vậy khi bản dựng có kích thước 0,5 - 2 GB

Tại sao (hoặc trong hoàn cảnh nào) là kích thước xây dựng như một mối quan tâm?

Lưu ý: lý do tôi hỏi là vì tôi thấy các tài nguyên như lưu trữ và tính toán tương đối rẻ so với trước đây, vì vậy, nếu có bất cứ điều gì, tôi sẽ mong đợi kích thước xây dựng sẽ ít gặp sự cố hơn so với trước đây

Khi tôi nêu vấn đề kích thước bản dựng là một mối quan tâm, nó thường không xuất phát từ "nó quá lớn, sẽ rất tốn kém để lưu trữ nó".

Các vấn đề chính với các bản dựng lớn là như sau -

• tăng thời gian vận chuyển. di chuyển các bit lớn từ nơi này sang nơi khác thường xuyên là tốn thời gian.
• thay đổi thường xuyên đối với các cổ vật lớn cộng với thời gian lưu giữ lớn khó khăn khiến việc lưu trữ các cổ vật đó trở nên tốn kém, ít hơn với các tạo tác xếp lớp như hình ảnh docker.
• tạo ra các tạo tác lớn như vậy thường tốn thời gian, hơn là tạo ra các tạo tác nhỏ hơn nhiều. tự động hóa quá trình để tạo ra các tạo tác nhỏ hơn có thể mất thời gian, nhưng tự động hóa có thể lặp lại nên càng ngắn càng tốt để cho phép phản hồi nhanh.
• phục hồi từ thất bại (tùy thuộc vào cấu hình) có thể mất nhiều thời gian hơn với các tạo phẩm lớn hơn, đặc biệt là khi một cổ vật cũ hơn cần được áp dụng lại thay vì một lỗi mới.

Tôi đăng ký bốn số liệu devops:

• Dẫn đầu thời gian thay đổi - rút ngắn nó
• Tần suất triển khai - tăng tần suất
• Thời gian để khôi phục dịch vụ - rút ngắn nó
• Thay đổi tỷ lệ thất bại - giảm nó xuống không bao giờ

Các tạo tác lớn thường tạo ra một vấn đề trong mỗi số liệu này và không có số liệu nào trong số này thực sự quan tâm đến chi phí lưu trữ thực sự - bởi vì đó là rẻ, thời gian là tốn kém.

Bổ sung câu trả lời của Evgeny với một vài ví dụ nữa.

Ý bạn là gì bởi kích thước bản dựng có thể quan trọng một chút:

• nếu đó là kích thước của (các) vật phẩm được chế tạo (mỗi kích thước riêng lẻ hoặc kích thước kết hợp của chúng) - có thể quan trọng trong các hoạt động lưu trữ hoặc sử dụng / triển khai tạo tác nếu các hoạt động đó có giới hạn kích thước và chúng bị vượt quá. Ví dụ: ứng dụng Google App Engine có giới hạn triển khai như vậy , nếu việc triển khai đạt được sẽ thất bại, hãy xem Lỗi khi triển khai lên Google App Engine .

• nếu đó là kích thước của không gian làm việc mà bạn thực hiện xây dựng thì nó có thể quan trọng từ góc độ quản lý không gian làm việc. Thậm chí 2G có thể là đáng kể - ví dụ: nếu bạn đang xây dựng hệ thống tệp RAM trên máy không có nhiều RAM. Nhưng một số bản dựng có thể lớn hơn nhiều - tôi đã phải xử lý các không gian làm việc 500G + (khi hầu hết các đĩa máy chủ của tôi đều dưới 1T).

Nếu bản dựng là một phần của đường ống CI / CD của bạn thì kích thước bản dựng càng lớn thì thời gian thực hiện đường ống sẽ càng dài (thực hiện bản dựng thực tế và, nếu có thể, lưu trữ, triển khai để thử nghiệm, phân tích trong trường hợp thất bại, làm sạch, v.v.) - chậm hơn / rủi ro hơn / chi phí phát triển tổng thể của bạn có thể.

Nếu bạn đạt đến giới hạn cứng, bạn sẽ phải sáng tạo để giải quyết xung quanh nó (không phải lúc nào cũng đơn giản / có thể). Nếu đó chỉ là một hiệu suất / chi phí, bạn cũng có tùy chọn chấp nhận và sống với nó và / hoặc giải quyết nó một phần / dần dần.

Có thể đáng để phân biệt giữa:

• bản dựng cồng kềnh - khi kích thước tăng không cần thiết - khắc phục sự cố thường có thể bằng cách bỏ các phần không cần thiết
• các trường hợp trong đó nội dung của bản dựng là những gì thực sự cần thiết - kích thước không quan trọng bằng - nó là cần thiết, cách duy nhất để giải quyết có thể là bằng cách hy sinh một số chức năng

Tôi sẽ thêm một vấn đề rất cụ thể mà chúng ta thực sự gặp phải. Đó là một khía cạnh của kiến ​​trúc xấu mà chúng ta hiện đang phải chịu:

Vì bản dựng của chúng tôi lớn và chúng tôi cần tải rất nhiều phụ thuộc đơn giản chỉ cần đặt tất cả lại với nhau mất một thời gian rất dài. Từ lâu, chúng ta nên chia việc xây dựng thành nhiều bản dựng nhỏ như một cách tiếp cận kiến ​​trúc microservice thay vì một khối nguyên khối lớn.

Chạy tất cả các bài kiểm tra cho khối nguyên khối mất khoảng 45 phút và chặn môi trường CI của chúng tôi trong thời gian hiện tại.

Vì nó quá tải và mất nhiều thời gian nên hiện tại chúng tôi không thể chạy nhiều bản dựng song song với nhau.

Vì vậy, như các áp phích trước tôi đã nêu ở cấp độ lý thuyết hơn, điều này sẽ thể hiện một số ý nghĩa phụ tiềm năng (và có thể), một công trình lớn thường có bên ngoài cần nhiều không gian hơn trên ổ cứng.