Почему Размер Сборки Вызывает Такое Беспокойство?

Я часто слышу (от людей, а также от информативных интерфейсов командной строки), что «размер сборки/слага большой». Это особенно актуально, когда размер сборки составляет 0,5–2 ГБ.

Почему (или при каких обстоятельствах) размер сборки вызывает такое беспокойство?

Примечание. Причина, по которой я спрашиваю, заключается в том, что я считаю, что такие ресурсы, как хранилище и вычисления, относительно дешевы по сравнению с прошлым, поэтому, во всяком случае, я ожидаю, что размер сборки сейчас будет меньшей проблемой, чем в прошлом.

#строит

Когда я поднимаю проблему размера сборки как проблему, это обычно не связано с тем, что «она настолько велика, что хранить ее будет дорого».

Основные проблемы с большими сборками следующие:

• увеличенное время доставки. Частое перемещение больших битов с места на место отнимает много времени.
• частые изменения в больших артефактах плюс достаточно большой период хранения делают хранение таких артефактов дорогостоящим, особенно в случае многоуровневых артефактов, таких как образы Docker.
• Создание таких больших артефактов обычно требует больше времени, чем создание гораздо меньших артефактов. автоматизация процесса создания более мелких артефактов может занять время, но повторяемая автоматизация должна быть как можно более короткой, чтобы обеспечить быструю обратную связь.
• восстановление после сбоя (в зависимости от конфигурации) может занять больше времени с более крупными артефактами, особенно когда необходимо повторно применить более старый артефакт вместо неисправного нового.

Я придерживаюсь четырех показателей DevOps:

• Время подготовки к изменениям – сократите его
• Частота развертывания — увеличьте частоту.
• Время восстановления сервиса - сократите его
• Измените частоту отказов – сократите ее до никогда

Большие артефакты обычно создают проблемы по каждому из этих показателей, и ни один из этих показателей на самом деле не связан со стоимостью хранения — потому что это дешево, а время дорого.

Дополняю ответ Евгения еще несколькими примерами.

То, что вы подразумеваете под размером сборки, может иметь значение:

• если это размер создаваемого артефакта (ов) (каждого по отдельности или их совокупного размера) - это может иметь значение при операциях хранения или использования/развертывания артефактов, если эти операции имеют ограничения по размеру и они превышены. Например, приложения Google App Engine имеют такие ограничения развертывания, если достигнутое развертывание завершится неудачей, см. Ошибка при развертывании в Google App Engine..

• если это размер рабочей области, в которой вы выполняете сборку, это может иметь значение с точки зрения управления рабочей областью. Даже 2G может иметь значение — например, если вы создаете файловую систему RAM на машине с небольшим объемом оперативной памяти. Но некоторые сборки могли быть намного больше — мне приходилось иметь дело с рабочими пространствами более 500 ГБ (когда большинство моих серверных дисков были ниже 1 Т).

Если сборка является частью вашего конвейера CI/CD, то чем больше размер сборки, тем дольше будет время выполнения конвейера (выполнение фактической сборки и, если применимо, архивирование, развертывание для тестирования, анализ в случае сбоя, очистка, и т. д.) — тем медленнее/рискованнее/затратнее может быть ваше общее развитие.

Если вы достигнете жесткого предела, вам придется проявить творческий подход, чтобы обойти его (не всегда просто/возможно). Если это всего лишь снижение производительности/затрат, у вас также есть возможность принять это и жить с этим и/или частично/постепенно решать эту проблему.

Возможно, стоит различать:

• раздутые сборки - когда размер излишне увеличивается - исправить проблему обычно можно путем удаления ненужных частей
• случаи, когда содержимое самой сборки - это то, что действительно необходимо - размер не имеет большого значения - оно необходимо, единственный способ решить эту проблему - пожертвовать некоторой функциональностью

Я добавлю очень конкретную проблему, с которой мы действительно столкнулись. Это побочный эффект плохой архитектуры, от которого мы сейчас страдаем:

Поскольку наша сборка большая и нам нужно загрузить множество зависимостей, простое объединение всего этого занимает очень много времени. Нам давно следовало разделить сборку на множество небольших сборок в качестве подхода к микросервисной архитектуре, а не на один большой монолит.

Выполнение всех тестов монолита занимает около 45 минут и на время блокирует нашу среду CI.

Поскольку это требует такой большой нагрузки и занимает так много времени, в настоящее время мы не можем запускать несколько сборок параллельно друг другу.

Итак, как уже говорилось на более теоретическом уровне в плакатах до меня, это должно продемонстрировать некоторые потенциальные (и вероятные) побочные последствия, которые обычно имеет большая сборка, помимо необходимости большего места на жестком диске.