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

As equipas transferem estes serviços dos portáteis para tornar as compilações reproduzíveis, permitir o acesso a dependências partilhadas, descartar o estado dos testes e garantir que a entrega não depende da bateria ou do espaço de trabalho de um único programador.

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

Comece pelo problema no fluxo de trabalho

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

A integração contínua depende de verificações automatizadas frequentes, cujos resultados sejam visíveis para todos. As práticas de integração contínua de Martin Fowler destacam compilações com autotestes automatizados e resultados visíveis, características difíceis de garantir num portátil que só está disponível ocasionalmente.

Transfira um papel apenas depois de identificar o problema que resolve: atraso na fila, divergência entre ambientes, distribuição de imagens, estado de integração partilhado ou concorrência pelo portátil.

Separe a fronteira de confiança dos executores

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

Imponha quotas ao espaço de trabalho e às caches de compilação. Uma tarefa com falhas não deve encher o sistema de ficheiros raiz do servidor nem ler credenciais do registo que não estejam relacionadas com o projeto.

Defina as etiquetas dos executores de acordo com o nível de confiança e as capacidades. Não envie código de pedidos de alteração de colaboradores desconhecidos para um executor com acesso a segredos de produção ou à rede doméstica.

Defina o papel do Registo como serviço de distribuição duradouro

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

Faça cópias de segurança da configuração, dos metadados e de quaisquer artefactos que não possam ser recriados. Se as imagens puderem ser reproduzidas 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 todas as camadas de cache.

Monitorize a capacidade antes da limpeza. A recolha de lixo do registo pode exigir muitos recursos de E/S e, dependendo da implementação, poderá requerer um modo de manutenção.

Featured

NAS de nuvem pessoal doméstica ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

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

Atribua a cada pipeline ou ramo um nome de base de dados, esquema, contentor ou VM isolado. Inicialize-o a partir de dados de teste versionados ou de um conjunto de dados anonimizado, execute as migrações automaticamente e elimine-o no fim do período de retenção.

Nunca copie segredos de produção nem dados pessoais não anonimizados para a função de teste. Limite o acesso à rede para que uma tarefa comprometida não possa passar da base de dados de teste para serviços sem relação.

Guarde apenas os registos e artefactos necessários para diagnosticar testes falhados. Bases de dados enigmáticas que persistem durante muito tempo recriam o problema do portátil numa máquina maior.

Crie a topologia de servidor para uma equipa pequena

Use 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 proporcionar 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 responsabilidade e o procedimento de reversão para 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 com dados iniciais, uma situação de disco cheio e o reinício do servidor. Os programadores devem poder continuar a 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 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 teste são isoladas e descartáveis e nenhum executor tem acesso a mais segredos do que os necessários para o seu trabalho.