Porque é útil uma cache de compilação dedicada para programadores que trabalham com vários dispositivos?

Uma cache de compilação dedicada é útil quando os mesmos repositórios são compilados num portátil, computador de secretária, executor de CI ou em plataformas com CPUs diferentes, e o trabalho repetido custa mais do que a transferência e a manutenção da cache.

A cache deve continuar a ser uma otimização, não a fonte de verdade. As compilações devem continuar a ter sucesso após uma falha de cache, enquanto as chaves da cache, os limites de confiança, as quotas e a recolha de lixo impedem que um dispositivo contamine ou encha o serviço partilhado.

Meça o Trabalho Repetido Entre Dispositivos

Registe as transferências de dependências, as camadas de contentores, os objetos compilados, os recursos gerados e o tempo total de compilação em cada dispositivo. Conte com que frequência as mesmas entradas são compiladas novamente depois de mudar de máquina ou iniciar um trabalho de CI efémero.

Um guia prático sobre uma cache remota do Bazel explica como várias máquinas podem reutilizar artefactos em vez de compilarem independentemente entradas idênticas.

Uma cache dedicada justifica-se quando o trabalho repetido é frequente, os artefactos são determinísticos e o tempo de transferência é inferior ao da recomputação. Acrescenta pouco valor quando os projetos são pequenos ou os dispositivos raramente partilham entradas.

Defina as Chaves da Cache e os Limites de Confiança

As chaves devem incluir as entradas de origem, os ficheiros de bloqueio de dependências, a versão do compilador ou do runtime, a arquitetura de destino, os sinalizadores de ambiente importantes e o passo de compilação. Uma chave demasiado abrangente produz correspondências falsas; uma chave demasiado restrita não permite reutilização.

Dê acesso de escrita aos trabalhos de CI fidedignos e considere o acesso só de leitura para as máquinas dos programadores ou para branches não fideditas. Uma entrada da cache pode conter resultados executáveis, pelo que aceitar escritas de código arbitrário é uma decisão relacionada com a cadeia de fornecimento.

Separe arquiteturas e gerações de toolchains. Um portátil com Apple Silicon e um executor Linux x86 podem partilhar pacotes de código-fonte transferidos, mas necessitam de artefactos compilados diferentes.

Coloque a Cache Perto do Trabalho Dispendioso

Num fluxo de trabalho doméstico, mantenha uma cache local pequena em cada dispositivo e uma cache partilhada maior no servidor. Os programadores remotos podem usar a camada partilhada apenas quando o caminho de rede for suficientemente rápido para compensar a recompilação.

Mantenha a cache afastada das partilhas familiares protegidas e dos destinos de cópia de segurança. A elevada rotatividade e a eliminação automática pertencem a um dataset dedicado com a sua própria quota.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Faça a Gestão de Quotas, Recolha de Lixo e Falhas de Cache

Defina um tamanho máximo, limites superior e inferior, uma idade máxima e uma política para entradas grandes. Acompanhe a taxa de acertos, os bytes transferidos, o tempo de compilação poupado, a taxa de expulsão e o tempo gasto na pesquisa da cache.

Um relato operacional sobre a execução de infraestrutura de compilação remota observa que os discos de cache podem ficar cheios mais depressa do que a recolha de lixo e que a latência de cauda da rede pode eliminar os ganhos médios.

Permita a continuação quando a cache estiver indisponível: a compilação deve recomputar os resultados em vez de parar. Restaure o serviço a partir da configuração e deixe as entradas serem repovoadas, exceto quando uma cache específica tiver dados de proveniência insubstituíveis.

Use um Limite entre Usar a Cache e Parar

Implemente uma cache dedicada quando pelo menos dois dispositivos recompilarem as mesmas entradas dispendiosas, a taxa de acertos for mensurável e for possível impor uma política com um único escritor fidedigno. Comece com um toolchain, em vez de colocar todos os gestores de pacotes em cache de uma só vez.

Separe os serviços de cache quando os projetos tiverem requisitos diferentes de confiança, retenção ou E/S. Acrescente capacidade SSD quando a expulsão remover artefactos frequentemente utilizados; acrescente capacidade de rede apenas quando as transferências, e não a pesquisa ou a compilação, forem o estrangulamento medido. O fluxo de testes SMB para ficheiros pequenos pode ajudar a identificar limites de transferência dominados por metadados.

Pare de expandir a cache se a taxa de acertos continuar baixa ou se os incidentes de invalidação custarem mais do que o tempo de compilação poupado. Uma falha de cache limpa é mais barata do que um artefacto rápido, mas incorreto.

Regra Final de Configuração

A configuração está pronta quando cada serviço tem uma função identificada, estado protegido, caminho de acesso controlado, restauro testado e um critério mensurável para dividir ou expandir a topologia.