Microsserviços. Controle de versão em sistemas de integração contínua e implantação Estudo de caso de CI / CD usando TFS

Edição

Para projetos grandes e tecnicamente complexos, nos quais, em regra, muitas equipes distribuídas trabalham simultaneamente, existe um problema bem conhecido de software com versão em desenvolvimento, que diferentes empresas resolvem de maneira diferente.

Atualmente, vários de nossos clientes e parceiros entregam as versões mais recentes (CI / CD) para produção manualmente, instalando as versões mais recentes / atuais de seus softwares, testando-as anteriormente com o restante do ambiente. Por exemplo, fornecendo compilações de aplicativos iOS, Android etc., se estivermos falando sobre software cliente, ou atualizando imagens de janela de encaixe em um ambiente de janela de encaixe, se estivermos falando de back-end. Para projetos grandes e importantes em que a decisão de liberar uma nova versão no Production a cada vez é tomada pelo gerente de projetos, essa decisão é justificada e não é muito cara, especialmente se as liberações não são frequentemente lançadas. No entanto, para o ambiente de desenvolvimento de teste (ambiente Dev / Stage), o uso de ferramentas "manuais" leva à complexidade do projeto, possível interrupção de impressões no Cliente e assim por diante. Pode haver muitas razões para isso, incluindo inconsistências nas versões de vários contêineres no software de middleware ou a falta de um histórico detalhado de lançamentos.

Tivemos que garantir isso pessoalmente e enfrentar muitas dificuldades em um grande projeto, no qual eram lançadas diariamente de 6 a 8 novas versões de software no back-end e 2-3 versões de software no front-end no sistema de CI, onde os engenheiros de teste não podiam lidar objetivamente com a carga e havia uma constante falta de entendimento de qual versão do software no front-end / back-end era considerada estável no momento.

Nossa experiência

Nossa empresa utiliza vários sistemas de CI / CD em seu trabalho, cuja escolha geralmente é determinada pelos requisitos do Cliente. Por exemplo, nossos especialistas geralmente encontram sistemas de CI / CD como Jenkins, TeamCity, Travis CI, Circle CI, Gitlab CI, Atlassian Bamboo, onde às vezes trabalhamos inteiramente na infraestrutura do cliente. Dessa forma, com essa abordagem, o problema com a solução do controle de versão é inteiramente do Cliente.

Ao desenvolver soluções para os clientes, quando temos a oportunidade de fazer isso em nossa própria infraestrutura, usamos o TFS versão 2018 como base para o sistema de Integração Contínua / Entrega Contínua, o que nos permite resolver a principal tarefa de criar um ciclo completo de desenvolvimento de software, a saber:

• Declaração de tarefas (Problemas, Bugs, Tarefas) com base na abordagem de desenvolvimento de software usada no projeto atual;
• Armazenamento do código fonte do projeto;
• Implantação da infraestrutura de agentes de construção para montagens para diferentes sistemas operacionais (Windows, Linux, MacOS);
• Montagem de projetos no modo "manual" e IC;
• Implantação de projetos no modo "manual" e CD;
• Testando projetos;
• Formação de dados sobre o tempo gasto pelos funcionários no projeto e várias funções adicionais que implementamos usando as Extensões TFS de nosso próprio design e adicionando estática ao WIT (nesse formulário, o TFS substituiu nossa empresa Redmine e simplificou a coleta de estatísticas, relatórios etc. no contexto de projetos )

Nesse caso, seria lógico atribuir a solução ao problema de controle de versão ao TFS, finalizando a funcionalidade do TFS para nossas tarefas e os desejos do Cliente. Como resultado, a tarefa de construir um sistema de versão para projetos de arquitetura de microsserviço foi resolvida pelas ferramentas TFS, personalizando vários scripts de construção e organizando ambientes de teste / liberação.

A solução: usando o TFS e ferramentas de terceiros

Portanto, precisamos de um sistema de versão para projetos de arquitetura de microsserviço para organizar ambientes de teste e lançamentos.

Como dados iniciais, temos:

• Orquestração - usamos o docker swarm principalmente para reduzir o uso de outras ferramentas de terceiros. Ao mesmo tempo, existem conversores para converter configurações - por exemplo, o utilitário Kompose , que permitirá usar o Kubernetes, se necessário.
• Agentes de construção - VM baseada em servidores Linux.
• Repositório de origem - Git baseado em TFS.
• Armazenamento de imagem - registro da janela de encaixe na VM.

Para a pergunta do nome das compilações

• Será lógico usar os padrões de nomenclatura existentes, por exemplo, como a Semantic Versioning Specification .
• Seguimos esse nome ao iniciar manualmente o processo de compilação da versão de lançamento, porque, caso contrário, você não poderá obter o nome correto automaticamente (a menos que o coloque manualmente no código, que novamente tem pouca relação com a ideologia do IC).
• No modo CI para versões de software de "depuração", usamos os seguintes nomes em diferentes projetos:
  
  
  1. Extensões TFS incorporadas
  2. Numeração com base na data atual e número da compilação naquele dia;
  3. O número da confirmação que iniciou a construção.

Uma solução específica, por exemplo, pode ser visualizada com base em um exemplo do serviço Calculadora , feito em Javascript, e em vários projetos publicamente disponíveis.

Algoritmo de decisão

1. No TFS2018, crie um projeto chamado SibEDGE Semver e importe o repositório para o repositório local


Figura 1 - Projeto SibEDGE Semver no repositório do TFS 2018

2. Crie um arquivo Dockerfile com a descrição do assembly node.js para nossas necessidades ( link ).

FROM node:7 WORKDIR /usr/src/app COPY package.json app.js LICENSE /usr/src/app/ COPY lib /usr/src/app/lib/ LABEL license MIT COPY tests tests ENV NODE_ENV dev RUN npm config set strict-ssl false RUN npm update && \ npm install -g mocha CMD ["mocha", "tests/test.js", "--reporter", "spec"] 

Script 1 - Dockerfile para criar uma construção

3. Na bancada de testes (com a janela de encaixe instalada), onde planejamos implantar nosso ambiente, crie um cluster de enxame. No nosso caso, ele consistirá em um servidor.

 $ docker swarm init 

4. Crie um arquivo yml com uma descrição dos microsserviços para as nossas necessidades ( link ).
Observe que vm-docker-registry.development.com:5000 é o repositório interno deste projeto, que preparamos com antecedência. Para que o suporte de teste possa usar este repositório, é necessário registrar um certificado SSL no suporte na pasta /etc/docker/certs.d/ <nome do repositório> /ca.crt

 version: '3.6' services: #--- # Portainer for manage Docker #--- portainer: image: portainer/portainer:1.15.3 command: --templates http://templates/templates.json -d /data -H unix:///var/run/docker.sock networks: - semver-network ports: - 9000:9000 volumes: - /var/run/docker.sock:/var/run/docker.sock #--- #----Service Calculator Test# #--- semver-calc: image: vm-docker-registry.development.com:5000/calculator:latest networks: - semver-network #--- #----Pminder - Nginx# #--- nginx: image: nginx:1.9.6 depends_on: - mysql ports: - "8888:80" - "6443:443" networks: - semver-network # #----------------------------- # START NoSQL - Redis. #--- redis: image: redis:4.0 networks: - semver-network ports: - "8379:6379" # # END NoSQL - Redis. #--- #----Pminder - DB# #--- mysql: image: mysql:5.7 ports: - "3306:3306" environment: MYSQL_ROOT_PASSWORD: 'ODdsX0xcN5A9a6q' MYSQL_DATABASE: 'semver' MYSQL_USER: 'user' MYSQL_PASSWORD: 'uXcgTQS8XUm1RzR' networks: - semver-network #--- #----PhpMyAdmin # #--- phpmyadmin: image: phpmyadmin/phpmyadmin depends_on: - mysql environment: PMA_HOST: 'mysql' PMA_USER: 'user' PMA_PASSWORD: 'uXcgTQS8XUm1RzR' ports: - "8500:80" - "8600:9000" networks: - semver-network #--- networks: semver-network: 

O script 2 é o conteúdo do arquivo semver.yml, que é o arquivo do projeto docker-compose.

5. Crie uma descrição da compilação no TFS2018 (Definição da compilação).

6. A primeira ação do nosso script é criar a imagem do contêiner do docker:


Figura 2 - Criando uma imagem para nossa compilação no TFS 2018

7. Envie a imagem do contêiner do docker criada na máquina de construção para o repositório interno deste projeto:


Figura 3 - Salvando a imagem do docker para nosso assembly no repositório do TFS 2018

8. Para todo o ambiente na bancada de testes no arquivo de descrição dos microsserviços, altere o nome da imagem para um novo:


Figura 4 - Substituindo o nome da imagem no script de compilação por nossa compilação no TFS 2018

9. Na bancada de testes, copie a imagem do contêiner do docker criado no repositório interno e atualize o serviço no swock do docker:


Figura 5 - Implantando o contêiner do docker com o script de compilação para nossa compilação a partir da imagem no TFS 2018

Como resultado, quando saímos para o repositório TFS, temos um arquivo yml com versões de liberação das imagens do docker, que por sua vez tem um nome de liberação para todo o projeto.

10. Vamos para a bancada de testes e verificamos o trabalho dos serviços e asseguramos que o serviço Calculadora tenha sido atualizado e utilize a nova versão do conjunto.

 $ docker service ls 

Figura 6 - Atualizando o serviço Calculadora e verificando sua versão atual em nossa bancada de testes

Portanto, em nosso armazenamento de imagens do registro do docker, temos um conjunto de imagens de diferentes versões de microsserviços (nesse caso específico, a versão de apenas um microsserviço é alterada). Ao iniciar um processo de implantação separado (por meio de um script que altera o arquivo de descrição yml), a qualquer momento você pode obter o ambiente necessário para o teste em um banco de testes e transferir essa configuração para a divisão de controle de qualidade. Após o teste (regressão, carga etc.), obtemos informações de que o microsserviço de uma determinada versão funciona de forma estável em um banco de testes com as versões de lançamento de outros microsserviços dessas e de tais versões, e a decisão final já está tomada sobre a atualização ou não suporte de lançamento para a nova versão.

Resumo - o que você conseguiu na saída

Graças à implementação do controle de versão em projetos com arquitetura de microsserviço, o seguinte resultado foi alcançado:

• a quantidade de caos nas versões diminuiu;
• a velocidade de implantação de um novo ambiente em projetos aumentou;
• a qualidade das montagens melhorou e o nível de erros nelas diminuiu;
• maior transparência do desenvolvimento para os gerentes de projeto e o cliente;
• a interação entre departamentos melhorou;
• Existem novas direções no trabalho do DevOps.

PS Agradeço ao meu colega Kirill B. por me ajudar a escrever este artigo.