O que muda quando um executor Git autoalojado passa a fazer parte do fluxo de trabalho diário de um programador?

Quando um runner Git autoalojado passa a fazer parte do fluxo de trabalho diário, torna-se uma dependência de produção: os programadores passam a depender da sua fila, cadeia de ferramentas, acesso à rede, segredos, caches e tempo de recuperação.

A topologia deve, por isso, separar o controlo da execução, tornar as tarefas descartáveis e preservar apenas o estado que é partilhado intencionalmente. Um runner persistente e rápido é conveniente, mas desvios ocultos e credenciais com permissões abrangentes podem transformar essa conveniência numa fronteira de confiança frágil.

Trate o runner como um sistema de execução remota de código

Cada tarefa aceite executa código controlado pelo repositório em infraestruturas que lhe pertencem. Defina quais os repositórios, ramos, colaboradores e eventos de pedidos de integração que podem aceder ao runner antes de associar credenciais de implementação ou de pacotes.

Uma arquitetura de runner baseada em microVMs utiliza máquinas virtuais de utilização única para manter o desempenho da execução autoalojada e, ao mesmo tempo, reduzir o estado transportado de uma tarefa para a seguinte.

Use grupos de runners separados para tarefas de lançamento fidedignas e testes normais. Um fluxo de trabalho público ou acionado por um fork não deve partilhar um ambiente de execução com segredos de implementação em produção.

Passe de uma máquina rápida para um contrato de fila

A utilização diária cria expectativas quanto ao tempo de espera, à simultaneidade, ao cancelamento e à prioridade. Meça separadamente o tempo de espera na fila e a duração da tarefa, para não confundir um teste lento com capacidade insuficiente do runner.

Defina a simultaneidade abaixo do nível em que as compilações simultâneas saturam a memória, o armazenamento ou as transferências do Docker. Reserve capacidade para tarefas interativas ou de lançamento, caso não devam ficar à espera de matrizes de testes demoradas.

Documente a alternativa para os programadores quando o runner está offline: execução alojada, um comando local ou uma tarefa não crítica adiada. Sem uma alternativa, a manutenção transforma-se numa interrupção imprevista do desenvolvimento.

Separe a cache recriável do estado persistente

As caches aceleram o fluxo de trabalho diário, mas têm de ter um limite de tamanho, um modelo de propriedade e uma regra de eliminação. Os artefactos de compilação e as provas de lançamento devem ficar num destino externo, com um período de retenção definido, e não numa pasta de espaço de trabalho sem limites.

Permita substituir o runner a partir de uma imagem ou de um script de aprovisionamento. Se recriar o anfitrião destruir a única chave de assinatura ou o único resultado de teste, esses recursos estavam atribuídos à função errada.

Featured

ZimaBoard 2 - Mini servidor doméstico para a sua grande ideia

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Adicione correções, observabilidade e responsabilidade por falhas

Acompanhe a versão do runner, as atualizações do sistema operativo, as versões do Docker ou da cadeia de ferramentas, a utilização do disco, a taxa de falhas dos trabalhos, a latência da fila e o crescimento da cache. Defina uma janela de manutenção e um responsável, mesmo que o runner esteja num servidor pessoal.

Um estudo sobre a manutenção de fluxos de trabalho empírico concluiu que a própria automatização gera trabalho contínuo de correção de erros e melhoria de CI. A autoalojagem acrescenta o ciclo de vida do anfitrião a essa carga de manutenção.

Gere alertas quando o sistema ficar offline, houver falhas repetidas nos trabalhos, os discos estiverem cheios ou as filas forem invulgarmente longas. Os registos têm de identificar se a falha teve origem no código do repositório, na imagem do runner, no acesso à rede ou no anfitrião.

Utilize um teste de prontidão para o fluxo de trabalho diário

Recrie um runner, altere uma credencial de implementação, execute duas compilações em simultâneo, encha e limpe a cache e desligue deliberadamente o anfitrião durante um trabalho. Confirme que os programadores conseguem ver a falha e recorrer ao procedimento alternativo.

Mantenha o runner num único anfitrião quando o tempo de inatividade for aceitável e os trabalhos forem de confiança. Separe as cargas de trabalho de lançamento, não confiáveis ou específicas de hardware quando exigirem credenciais ou janelas de manutenção diferentes. O guia de sistemas operativos para servidores domésticos ajuda a escolher um anfitrião para o runner que facilite atualizações repetíveis e a recuperação.

Deixe de tratar o runner como um serviço de passatempo quando os trabalhos falhados bloquearem lançamentos ou trabalho para clientes. A partir daí, defina a responsabilidade pelo serviço, a capacidade de reserva e uma substituição testada, tal como faria com qualquer outra dependência de desenvolvimento.

Regra final de configuração

A configuração é aprovada quando cada serviço tem uma função atribuída, estado protegido, acesso controlado, restauro testado e um critério mensurável para dividir ou expandir a topologia.