Como construímos universos paralelos para nosso (e seu) pipeline de CI / CD no Octopod

Olá, Habr! Meu nome é Denis, e contarei a vocês como nos foi sugerido fazer uma solução técnica para otimizar o processo de desenvolvimento e QA em nosso Typeable. Tudo começou com uma sensação geral de que estávamos fazendo tudo certo, mas ainda seria possível nos movermos com mais rapidez e eficiência - aceitar novas tarefas, testar, sincronizar menos. Tudo isso nos levou a discussões e experimentos, que resultaram em nossa solução de código aberto, que descreverei a seguir e que agora está disponível para vocês.



Não vamos, entretanto, correr na frente da locomotiva, mas começar do início e entender em detalhes do que estou falando. Vamos imaginar uma situação bastante padrão - um projeto com uma arquitetura de três camadas (armazenamento, back-end, front-end). Existe um processo de desenvolvimento e um processo de garantia de qualidade em que existem vários ambientes (muitas vezes chamados de contornos) para teste:

• A produção é o principal ambiente de trabalho para onde os usuários do sistema vão. 
• Pre-Production – - (, production, ; RC), production, production . Pre-production – , Production .
• Staging – , , , Production, .

Com a pré-produção, tudo é bastante claro: os candidatos a lançamento vão sempre lá, o histórico de lançamento é o mesmo que na produção . Existem nuances com o Staging :

1. ORGANIZACIONAL. O teste de peças críticas pode exigir um atraso na publicação de novas alterações; as mudanças podem interagir de maneiras imprevisíveis; o rastreamento de erros torna-se difícil devido à grande quantidade de atividade no servidor; às vezes, há confusão sobre qual versão é implementada; às vezes não está claro qual das mudanças acumuladas causou o problema.
2. . : production , «». staging , . . : , . , QA production , .
   
   
   
3. .
   
   
   
   
   
   
4. . . -. , . , . , .
5. . - , , , , . , , , . , . production , time-to-production time-to-market .

Cada um desses pontos se resolve de uma forma ou de outra, mas tudo isso nos levou à questão: será possível simplificar nossa vida se nos afastarmos do conceito de uma arquibancada para seu número dinâmico. Semelhante a como temos verificações de CI para cada branch no git, podemos obter estandes de verificação de controle de qualidade para cada branch. A única coisa que nos impede de tal mudança é a falta de infraestrutura e ferramentas. Grosso modo, para aceitar um recurso, um teste separado é criado com um nome de domínio dedicado, o controle de qualidade o testa, aceita ou retorna para revisão. Algo assim: 





Com esta abordagem, o problema dos diferentes ambientes é resolvido de forma natural:





Notavelmente, após a discussão, as opiniões da equipe foram divididas em “vamos tentar, quero melhor do que agora” e “parece tão normal, não vejo problemas monstruosos”, mas voltaremos a isso mais tarde.

Nosso caminho para a solução

A primeira coisa que tentamos foi um protótipo construído por nosso DevOps: uma combinação de docker-compose (orquestração), rundeck (gerenciamento) e portainer (introspecção), que nos permitiu testar a direção geral do pensamento e da abordagem. Houve problemas de conveniência:

1. Qualquer alteração exigia acesso ao código e ao rundeck, que os desenvolvedores tinham, mas não tinham, por exemplo, os engenheiros de QA.
2. Isso foi gerado em uma grande máquina, que logo se tornou insuficiente, e para a próxima etapa, o Kubernetes ou algo semelhante já era necessário.
3. O Portainer forneceu informações não sobre o estado de um estágio específico, mas sobre um conjunto de contêineres.
4. Tive que mesclar constantemente o arquivo com a descrição das etapas, as arquibancadas antigas tiveram que ser deletadas.

Mesmo com todas as suas desvantagens e alguns inconvenientes de operação, a abordagem veio e começou a economizar tempo e esforço da equipe do projeto. A hipótese foi testada, e decidimos fazer tudo igual, mas de uma maneira bem batida. Em busca do objetivo de otimizar o processo de desenvolvimento, coletamos os requisitos para um novo e entendemos o que queríamos:

1. Use o Kubernetes para escalar para qualquer número de ambientes de teste e tenha um conjunto padrão de ferramentas para DevOps modernos.
2. Uma solução que seria fácil de integrar à infraestrutura que já usa o Kubernetes.
3. , Product QA-. , . – .
4. , CI/CD , . , Github Actions CI.
5. , DevOps .
6. , , / - .
7. Informações completas e uma lista de ações devem estar disponíveis para superusuários na pessoa dos engenheiros de DevOps e líderes de equipe.

E começamos a desenvolver o Octopod . O nome era uma confusão de vários pensamentos sobre K8S, que usamos para orquestrar tudo no projeto: muitos projetos neste ecossistema refletem a estética e temas marinhos, e imaginamos uma espécie de polvo orquestrando muitos recipientes subaquáticos com tentáculos. Além disso, o Pod é uma das entidades fundadoras do Kubernetes.



Na pilha técnica, Octopod é Haskell, Rust, FRP, compilação para JS, Nix. Mas em geral a história não é sobre isso, então não vou me alongar sobre isso em mais detalhes.



O novo modelo ficou conhecido como Multi-staging em nossa empresa. Operar vários ambientes de teste simultaneamente é semelhante a viajar por universos e dimensões paralelas na ficção científica (e nem tanto). Nele, os universos são semelhantes entre si, com exceção de um pequeno detalhe: em algum lugar lados diferentes venceram a guerra, em algum lugar aconteceu uma revolução cultural, em algum lugar um avanço tecnológico. A premissa pode ser pequena, mas a que mudanças ela pode levar! Em nossos processos, esse pré-requisito é o conteúdo de cada ramificação de recurso separada.





Nossa implementação ocorreu em várias etapas e começou com um projeto. Isso inclui ajustar a orquestração do projeto do lado do DevOps e reorganizar o processo de teste e comunicação do gerente de projeto.



Como resultado de uma série de iterações, alguns recursos do Octopod em si foram removidos ou alterados irreconhecíveis. Por exemplo, na primeira versão tínhamos uma página com um log de implantação para cada circuito, mas aqui está o azar - nem toda equipe aceita que as credenciais possam fluir por meio desses logs para todos os funcionários envolvidos no desenvolvimento. Como resultado, decidimos nos livrar dessa funcionalidade e, em seguida, devolvê-la em um formato diferente - agora é personalizável (e, portanto, opcional) e implementado por meio da integração com o painel do kubernetes .



Há também outros pontos: com a nova abordagem, usamos mais recursos de computação, discos e nomes de domínio para dar suporte à infraestrutura, o que levanta a questão da otimização de custos. Se você combinar isso com as sutilezas do DevOps, o material será digitado em uma postagem separada, ou mesmo em duas, então não vou continuar sobre isso aqui.



Paralelamente à resolução de problemas emergentes em um projeto, começamos a integrar essa solução em outro, quando vimos o interesse de outra equipe. Isso nos permitiu ter certeza de que nossa solução era personalizável e flexível o suficiente para as necessidades de diferentes projetos. No momento, o Octopod é amplamente utilizado em nosso país há três meses.

Como resultado

Como resultado, o sistema e os processos são implementados em vários projetos, há interesse de mais um. Curiosamente, mesmo os colegas que não viram problemas com o antigo esquema agora não gostariam de voltar a ele. Descobrimos que, para alguns, resolvemos problemas que eles nem conheciam!



O mais difícil, como sempre, foi a primeira implementação - a maioria dos problemas e questões técnicas foram detectados nela. O feedback dos usuários tornou possível entender melhor o que precisa ser melhorado em primeiro lugar. Nas versões mais recentes, a interface e o trabalho com o Octopod têm a seguinte aparência:





Para nós, Octopod tornou-se uma resposta a uma questão processual, e eu chamaria o estado atual de um sucesso inequívoco - flexibilidade e conveniência claramente aumentaram. Ainda não há problemas totalmente resolvidos: arrastamos a autorização do próprio Octopod no cluster para Atlassian oauth para vários projetos, e esse processo é atrasado. Porém, isso não passa de uma questão de tempo, tecnicamente o problema já foi resolvido na primeira aproximação.

Código aberto

Esperamos que o Octopod seja útil não só para nós. Teremos o maior prazer em receber sugestões, solicitações e informações sobre como otimizar processos semelhantes. Se o projeto for do interesse do público, escreveremos conosco sobre as características de orquestração e operação.



Todo o código-fonte com exemplos de configuração e documentação está disponível no repositório no Github .