Por que o tamanho da construção é uma preocupação?

Costumo ouvir (de pessoas, mas também de CLIs informativas) que o "tamanho da compilação / slug é grande". Isso ocorre principalmente quando o tamanho da compilação é de 0,5 - 2 GB

Por que (ou sob que circunstâncias) o tamanho da construção é uma preocupação?

Nota: o motivo pelo qual pergunto é porque vejo recursos como armazenamento e computação relativamente baratos em comparação com o passado; portanto, se houver algo, eu esperaria que o tamanho da compilação fosse menos problemático agora do que no passado

Quando levanto uma questão de tamanho de compilação como uma preocupação, geralmente não vem de "é tão grande, será caro armazená-la".

Os principais problemas com grandes compilações são os seguintes -

• aumento do tempo de envio. mover grandes pedaços de um lugar para outro freqüentemente consome tempo.
• mudanças frequentes em grandes artefatos mais um grande período de retenção suficiente tornam o armazenamento desses artefatos caro, menos com artefatos em camadas, como imagens de janela de encaixe.
• criar esses artefatos grandes geralmente consome tempo, mais do que criar artefatos muito menores. automatizar o processo para criar artefatos menores pode levar tempo, mas a automação que pode ser repetida deve ser o mais curta possível para permitir um feedback rápido.
• recuperar da falha (dependendo da configuração) pode levar mais tempo com artefatos maiores, especialmente quando um artefato mais antigo precisa ser reaplicado em vez de um novo com defeito.

Eu assino as quatro métricas de devops:

• Tempo de espera para alterações - reduza-o
• Frequência de implantação - aumente a frequência
• Hora de restaurar o serviço - reduzi-lo
• Alterar taxa de falha - reduza para nunca

Os artefatos grandes geralmente criam um problema em cada uma dessas métricas, e nenhuma dessas métricas está realmente preocupada com o custo do armazenamento - porque isso é barato, o tempo é caro.

Complementando a resposta de Evgeny com mais alguns exemplos.

O que você quer dizer com tamanho da compilação pode importar um pouco:

• se for o tamanho do (s) artefato (s) que está sendo construído (cada um individualmente ou seu tamanho combinado) - isso pode ter importância nas operações de armazenamento ou uso / implementação de artefato, se essas operações tiverem limites de tamanho e forem excedidas. Por exemplo, os aplicativos do Google App Engine têm esses limites de implantação ; se as implantações alcançadas falharem, consulte Erro ao implantar no Google App Engine .

• se for o tamanho da área de trabalho na qual você executa a construção, pode ser importante da perspectiva de gerenciamento da área de trabalho. Mesmo o 2G pode ser significativo - por exemplo, se você estiver montando em um sistema de arquivos RAM em uma máquina sem muita memória RAM. Mas algumas compilações podiam ser muito maiores - eu tive que lidar com áreas de trabalho de 500G + (quando a maioria dos discos do meu servidor estava abaixo de 1T).

Se a compilação fizer parte do seu pipeline de CI / CD, quanto maior o tamanho da compilação, maior será o tempo de execução do pipeline (executando a compilação real e, se aplicável, arquivando, implantando para teste, analisando em caso de falha, limpando, etc.) - quanto mais lento / arriscado / mais caro for o seu desenvolvimento geral.

Se você atingir um limite, precisará ser criativo para contorná-lo (nem sempre é simples / possível). Se for apenas um impacto no desempenho / custo, você também terá a opção de aceitar e viver com ele e / ou abordá-lo parcialmente / gradualmente.

Talvez valha a pena distinguir entre:

• construções inchadas - quando o tamanho é desnecessariamente aumentado - geralmente é possível corrigir o problema descartando peças desnecessárias
• nos casos em que o conteúdo da compilação em si é o que realmente é necessário - o tamanho não importa tanto - é necessário, a única maneira de abordar pode ser sacrificando algumas funcionalidades

Vou acrescentar uma questão muito concreta que realmente encontramos. É um efeito colateral da arquitetura ruim que estamos sofrendo atualmente:

Como nossa compilação é grande e precisamos carregar muitas dependências, basta juntar tudo isso por um longo tempo. Há muito tempo, dividimos a compilação em várias pequenas compilações como uma abordagem para uma arquitetura de microsserviço, em vez de um grande monólito.

A execução de todos os testes do monólito leva cerca de 45 minutos e bloqueia o ambiente do IC por enquanto.

Como é muito trabalhoso e leva tanto tempo, atualmente é impossível executar várias construções paralelas umas às outras.

Portanto, como os pôsteres antes de mim já declararam em um nível mais teórico, isso deve mostrar algumas implicações colaterais potenciais (e prováveis) que uma grande compilação geralmente tem, além de precisar de mais espaço no disco rígido.