Entendendo a Integração Contínua e a Implantação Contínua

Ouviu CI/CD, mas não sabe o que é?

Idealmente, os engenheiros de software são contratados para escrever o código que precisa ser enviado para um ambiente de produção para que a empresa que precisa do produto possa usá-lo. Para satisfazer o negócio (muitas vezes chamado de usuários/clientes), é essencial que os produtos estejam livres de bugs.

A abordagem típica seguida por engenheiros de software é trabalhar em ramificações e criar uma solicitação pull que atualiza a ramificação mestre com a nova atualização que foi feita. Adotamos a prática de escrever testes como forma de garantir que as novas mudanças não introduzam bugs. Quando os desenvolvedores trabalham em um recurso, na maioria dos casos, eles geralmente não criam uma solicitação pull até que terminem completamente o recurso. O que acontece quando eles estão prontos é isso;

  • Eles gastam muito tempo tentando atualizar sua base de código com as mudanças que ocorreram na ramificação de produção enquanto trabalhavam.
  • Ao fazer isso, eles precisam corrigir uma série de conflitos de mesclagem.
  • Há também a possibilidade de eles quebrarem o branch de produção, o que passa a afetar aqueles que puxam do branch antes que o problema seja visto e corrigido.

Se você já esteve nessa situação, você concorda que pode ser uma dor – ninguém gosta de passar o dia de trabalho assim.

Qual é a solução?

Integração contínua

Para evitar os cenários que mencionei acima; as equipes de engenharia podem adotar a prática chamada de integração contínua – como o nome sugere, envolve a integração contínua das alterações de código feitas pelos desenvolvedores no branch/repositório compartilhado. O código a ser integrado deve passar por um teste verificado para garantir que não interrompa o aplicativo. É somente quando o teste passa que ele é integrado

Para entender isso, vamos imaginar um cenário da vida real onde há uma equipe de 10 desenvolvedores. Esses desenvolvedores criam uma ramificação localmente na qual escrevem código para a implementação de determinados recursos. Em vez de enviar solicitações de pull quando o recurso estiver totalmente concluído, eles optam por enviar solicitações de pull, pois fazem pequenas alterações. Um exemplo dessa mudança será a criação de um novo modal, assumindo que o desenvolvedor está trabalhando em um recurso que permite aos usuários gerenciar tarefas individuais no aplicativo. Em vez de esperar até que o recurso de tarefa seja concluído, para aderir a um padrão de integração contínua, o desenvolvedor faz push dessa pequena alteração (quando comparado com o que está trabalhando) e cria uma solicitação pull para mesclar ao código.

  Como configurar seu Mac para ligar automaticamente todos os dias

Antes que essa nova mudança seja integrada, uma série de testes deve ser executada.

As equipes de engenharia de software fazem uso de ferramentas como Travis CI para criar esses processos e testes de integração. Com ferramentas como essas, os testes são automatizados, de modo que são executados assim que um pull request é enviado ao branch de destino selecionado durante a configuração.

Os resultados dos testes são gerados, e o desenvolvedor que criou as pull requests pode ver os resultados e fazer as alterações necessárias. Os benefícios de aderir a esse padrão de integração de código o mínimo possível e ter um teste verificado para executar são;

  • Torna-se possível para a equipe envolvida saber o que causou a falha do processo de compilação ou teste. Isso reduz a possibilidade de enviar um bug para a produção.
  • Se a equipe automatizar o processo, eles terão o luxo de tempo para se concentrar em ser produtivos.

O importante a ser observado nessa prática é que ela incentiva a equipe a enviar código para a ramificação principal com frequência. Fazer isso será ineficaz se outros membros da equipe não estiverem extraindo do branch principal para atualizar seu repositório local.

  Como fazer ping em um iPhone

Tipos de testes

Na escrita de testes que farão parte do processo de integração, aqui estão alguns que podem ser implementados no processo:

  • Integração – combina unidades individuais do software e as testa como um grupo.
  • Unidade – testa unidades ou componentes individuais do software, como métodos ou funções.
  • UI – afirma que o software funciona bem do ponto de vista do usuário.
  • Aceitação – testa se o software atende aos requisitos de negócios.

É importante observar que você não precisa testar todos eles, pois alguns deles já podem ser abordados no código escrito pelo desenvolvedor.

Ferramentas de integrações contínuas

Sem entrar em profundidade, aqui estão as ferramentas que você pode começar a usar em seus projetos atuais ou novos;

  • Travis CI – conhecido no mundo open-source e promete a você ter seu código testado perfeitamente em minutos.
  • CI do círculo – fornece energia, flexibilidade e controle para automatizar seu pipeline desde o controle até a implantação.
  • Jenkins – fornece centenas de plugins para apoiar a construção, implantação e automatização de qualquer projeto.

Se você é novo no Jenkins, sugiro que faça isso Curso Udemy para aprender CI com Java e .NET.

Implantação Contínua

De que adiantará se o recurso que você criar ficar no repositório por semanas ou meses antes de ser implantado no ambiente de produção. Por mais que as equipes de engenharia possam trabalhar para integrar pequenas alterações na ramificação principal à medida que elas acontecem, elas também podem enviar essas alterações para o ambiente de produção o mais rápido possível.

O objetivo ao praticar a implantação contínua é levar as alterações feitas aos usuários assim que os desenvolvedores integrarem essas alterações na ramificação principal.

Como no caso da integração contínua, ao fazer uso da implantação contínua, testes e verificações automatizadas são configurados para garantir que as alterações recém-integradas sejam verificadas. A implantação só acontece quando esses testes são aprovados.

  O que é aceleração de hardware e você deve usá-lo?

Para que uma equipe se beneficie da prática de implantação contínua, ela precisa ter o seguinte;

  • O teste automatizado é a espinha dorsal essencial de todas as práticas contínuas de engenharia. No caso de implantação contínua, o código a ser implantado precisa estar de acordo com o padrão que a equipe estabeleceu para o que eles pretendem enviar aos usuários finais. Idealmente, se uma nova mudança estiver abaixo do limite, o teste deve falhar e não ser integrado. Caso contrário, torna-se integrado.
  • Apesar de ter testes automatizados consecutivos, é possível que alguns bugs entrem no ambiente de produção. Para isso, é necessário que a equipe seja capaz de desfazer uma mudança que foi feita – desfazer um deploy. Isso deve reverter o código de produção para o que era antes da nova alteração ser feita.
  • Os sistemas de monitoramento são necessários para acompanhar as mudanças que foram enviadas para o ambiente de produção. É assim que a equipe pode rastrear bugs que os usuários encontram ao fazer uso das alterações implantadas.

As ferramentas mencionadas para integração contínua também fornecem a funcionalidade de configurar um sistema de implantação contínua. Há muitos deles que você também pode ler.

Conclusão

A produtividade de uma equipe de desenvolvimento é vital para o sucesso do negócio. Para garantir que sejam produtivos, devem ser adotadas práticas que o estimulem. A integração e implantação contínuas são exemplos de tais práticas.

Com a integração contínua, as equipes podem enviar o máximo de código possível diariamente. Com isso alcançado, fica fácil implantar as alterações recém-adicionadas para o usuário o mais rápido possível. A implantação dessas mudanças possibilita obter feedback dos usuários. No final, o negócio será capaz de inovar com base no feedback recebido, o que é vantajoso para todos.

Você também pode aprender como dimensionar e otimizar CI/CD.

Se você é um desenvolvedor e está interessado em aprender CI/CD, confira este curso brilhante.

Gostou de ler o artigo? Que tal compartilhar com o mundo?