Versão russa

Vamos imaginar que você esteja desenvolvendo software e hardware. O dispositivo consiste em servidores distribuídos de SO, de alto padrão, com muita lógica de negócios; como resultado, ele precisa usar hardware real. Se você liberar um dispositivo com defeito, seus usuários não ficarão felizes. Como fazer lançamentos estáveis?

Eu gostaria de compartilhar minha história de como lidamos com isso.

Prova de conceito

Se você não conhece um objetivo, será realmente difícil concluir a tarefa. A primeira variante de implantação parecia bash :

make dist for i in abc ; do scp ./result.tar.gz $i:~/ ssh $i "tar -zxvf result.tar.gz" ssh $i "make -C ~/resutl install" done 

O script foi simplificado apenas para mostrar a ideia principal: não havia CI / CD. Nosso fluxo foi:

1. Criado no host do desenvolvedor.
2. Implementado no ambiente de teste para uma demonstração.

No estágio atual, o conhecimento de como foi provisionado, todos os kludges conhecidos eram magia suja nas mentes dos desenvolvedores. Foi um problema real para nós por causa do crescimento da equipe.

Apenas faça

Usamos o TeamCity em nossos projetos e o gitlab não era popular, por isso decidimos usar o TeamCity. Criamos manualmente uma VM. Estávamos executando testes dentro da VM.

Houve algumas etapas no fluxo de construção:

1. Instale alguns utilitários dentro do ambiente preparado manualmente.
2. Verifique se funciona.
3. Se estiver tudo bem, publique RPMs.
4. Atualize o teste para a nova versão.

 make install && ./libs/run_all_tests.sh make dist make srpm rpmbuild -ba SPECS/xxx-base.spec make publish 

Recebemos um resultado temporário:

1. Algo executável estava no ramo principal.
2. Funcionou em algum lugar.
3. Podemos detectar alguns problemas casuais.

Você sente o cheiro?

1. Havia um inferno de dependência com os RPMs.
2. Todo mundo tinha seu próprio ambiente de desenvolvimento para animais de estimação.
3. Os testes estavam sendo executados dentro do ambiente desconhecido.
4. Havia três entidades completamente ilimitadas: construção do SO, fornecimento de instalações e testes.

Reduzir magia suja

Mudamos os fluxos e processos:

1. Criámos o meta pacote RPM e removemos o inferno das dependências.
2. Criamos um modelo de VM de desenvolvimento via vagrant.
3. Mudamos os scripts do bash para o ansible.
4. Por um lado, criamos uma estrutura de testes de integração, mas, por outro, usamos serverpec .

Como resultado do estágio atual, recebemos:

1. Todo o nosso ambiente de desenvolvimento era idêntico.
2. O código do aplicativo e a lógica de provisionamento foram sincronizados entre si.
3. Aceleramos o processo de integração de novos desenvolvedores.

Por um lado, uma compilação foi realmente lenta (cerca de 30 a 60 minutos), mas, por outro lado, foi boa o suficiente e capturou com êxito a grande maioria dos problemas antes da garantia de qualidade manual. No entanto, enfrentamos novos problemas diferentes, ou seja, atualizamos o kernel ou revertemos um pacote.

Melhore

Resolvemos muitos problemas diferentes:

1. Os testes de integração funcionavam cada vez mais devagar porque o modelo de VM dev era mais antigo que os RPMs reais. Estávamos reconstruindo o modelo manualmente e decidimos automatizá-lo:
   
   • Crie um VMDK automaticamente.
   • Anexe o VMDK a uma VM.
   • Empacote a VM e faça o upload para o s3.
2. Em caso de mesclagem, não foi possível obter o status de compilação; como resultado, passamos para o gitlab.
3. Costumávamos fazer uma liberação manual toda semana, nós a automatizávamos.
   
   • Versão de incremento automático.
   • Gere notas de versão com base em problemas fechados.
   • Atualize o log de alterações.
   • Crie solicitações de mesclagem.
   • Crie um novo marco.
4. Mudamos algumas etapas para o docker (lint, execute alguns testes, envie mensagens, crie documentos etc.).

Como resultado, no estágio atual, o esquema parecia:

1. Havia muitos repositórios RPM / DEB para pacotes.
2. Havia s3 como armazém de artefatos.
3. Se você executasse uma compilação duas vezes para a mesma ramificação, receberia um resultado diferente, porque as dependências do meta pacote não foram codificadas.
4. Havia limites não óbvios (linhas vermelhas) nas construções.

No entanto, conseguimos produzir lançamentos toda semana e melhorar a velocidade de desenvolvimento.

Conclusão

O resultado não foi o ideal, mas uma jornada de mil li começa com um único passo ©.

PS é cruzamento