Porque estão os programadores a transferir os executores de CI, os registos e as bases de dados de teste para fora dos seus computadores portáteis?

As equipas transferem estes serviços dos computadores portáteis para tornar as compilações repetíveis, garantir o acesso às dependências partilhadas, manter o estado dos testes descartável e tornar a entrega independente da bateria ou do espaço de trabalho de um único programador.

O servidor não é um computador portátil maior. Um executor de CI executa instruções de projetos não fidedignas, um registo armazena artefactos da cadeia de fornecimento e uma base de dados de testes contém estado mutável. Combinar estes elementos pode ser eficiente para uma equipa pequena, mas apenas quando as identidades, redes, armazenamento, segredos, quotas e recuperação são separados por função.

Comece pela falha do fluxo de trabalho

A CI alojada num computador portátil falha quando o proprietário dorme, viaja, muda de rede, fecha a tampa ou precisa do CPU e da memória locais. Um registo local desaparece com esse computador, enquanto uma base de dados de testes acumula estado que apenas um programador compreende.

A integração contínua depende de uma verificação frequente e automatizada que todos possam consultar. As práticas de integração contínua de Martin Fowler destacam compilações com autotestes automatizados e resultados visíveis - propriedades difíceis de garantir num computador portátil disponível apenas ocasionalmente.

Transfira uma função apenas depois de identificar a falha que ela resolve: atraso na fila, divergência do ambiente, distribuição de imagens, estado de integração partilhado ou contenção do computador portátil.

Separe o limite de confiança do executor

Trate os trabalhos de CI como execução de código. Utilize contentores ou máquinas virtuais efémeros sempre que possível, evite montar o socket Docker do anfitrião em trabalhos não fidedignos e atribua credenciais com âmbito restrito por repositório ou pipeline.

Coloque o espaço de trabalho das compilações e as caches sob quotas. Um trabalho que falhe não deve encher o sistema de ficheiros raiz do servidor nem ler credenciais do registo que não estejam relacionadas com o seu projeto.

Defina etiquetas dos executores com base na confiança e nas capacidades. Não envie código de um pedido de pull de um colaborador desconhecido para um executor que possa aceder a segredos de produção ou à rede doméstica.

Torne o registo numa função de distribuição duradoura

Armazene os dados e a configuração do registo em armazenamento persistente, com autenticação, TLS em caminhos não fidedignos, regras de retenção e períodos de recolha de lixo. Separe as etiquetas de lançamento imutáveis das imagens de branches descartáveis.

Faça cópias de segurança da configuração, dos metadados e de quaisquer artefactos que não possam ser reconstruídos. Se as imagens forem reproduzíveis a partir do código-fonte, documente o tempo de reconstrução e preserve o código-fonte, as definições de compilação e as dependências externas, em vez de fazer cópias de segurança de cada camada de cache.

Monitorize a capacidade antes da limpeza. A recolha de lixo do registo pode exigir muita atividade de E/S e, dependendo da implementação, pode requerer um estado de manutenção.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Mantenha as bases de dados de testes descartáveis, mas representativas

Dê a cada pipeline ou branch um nome de base de dados, esquema, contentor ou máquina virtual isolado. Inicialize-o a partir de dados de teste versionados ou de um conjunto de dados anonimizado, execute as migrações automaticamente e destrua-o após o período de retenção.

Nunca copie segredos de produção ou dados pessoais não anonimizados para a função de testes. Limite o alcance da rede para que um trabalho comprometido não possa passar da base de dados de testes para serviços não relacionados.

Conserve apenas os registos e artefactos necessários para diagnosticar testes falhados. Bases de dados misteriosas de longa duração recriam o problema do computador portátil numa máquina maior.

Construa a topologia do servidor para uma equipa pequena

Utilize contas de serviço, redes de contentores, volumes, quotas e regras de cópia de segurança separados para as funções de executor, registo e base de dados. Este guia de plataformas NAS e Docker ajuda a decidir se os contentores ou as máquinas virtuais devem fornecer o isolamento.

Coloque a interface de gestão numa rede restrita. Exponha o registo e a interface de CI apenas à equipa ou através de uma camada de acesso autenticado. Registe as atualizações, a propriedade e a reversão de cada serviço.

Teste a recriação de um executor, o restauro ou a reconstrução do registo, a reinicialização da base de dados, uma situação de disco cheio e o reinício do servidor. Os programadores devem continuar a conseguir trabalhar localmente enquanto os serviços partilhados recuperam.

Verificação final da configuração

A migração é bem-sucedida quando as compilações são executadas sem depender de um computador portátil específico, os ambientes são recriados a partir de definições versionadas, os artefactos do registo têm um plano de retenção e recuperação, as bases de dados de testes estão isoladas e são descartáveis, e nenhum executor possui mais segredos do que aqueles exigidos pelo seu trabalho.