Noções básicas sobre integração contínua e implantação contínua

Ouvi CI / CD, mas não tenho certeza do 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 utilizá-lo. Para satisfazer os negócios (geralmente chamados de usuários / clientes), é essencial que os produtos estejam livres de erros.

A abordagem típica seguida pelos engenheiros de software é trabalhar em ramificações e criar uma solicitação de recebimento que atualize a ramificação principal com a nova atualização que foi feita. Adotamos a prática de escrever testes como um meio de garantir que as novas alterações não apresentem bugs. Quando os desenvolvedores trabalham em um recurso, na maioria dos casos, eles geralmente não criam uma solicitação de recebimento até que estejam completos com o recurso. O que acontece quando eles estão prontos é isso;

  • Eles passam muito tempo tentando atualizar sua base de código com as alterações que ocorreram no ramo de produção enquanto estavam trabalhando.
  • Ao fazer isso, eles precisam corrigir uma série de conflitos de mesclagem.
  • Também existe a possibilidade de eles quebrarem o ramo de produção, o que afeta os que saem do ramo antes que o problema seja visto e resolvido.

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

Qual é a solução?

Integração contínua

https://www.youtube.com/watch?v=HnWuIjUw_Q8

Para evitar os cenários que afirmei acima; equipes de engenharia podem adotar a prática chamada integração contínua – como o nome sugere, envolve a integração contínua de alterações de código feitas pelos desenvolvedores no ramo / repositório compartilhado. O código a ser integrado precisa 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 filial localmente na qual escrevem código para a implementação de certos recursos. Em vez de enviar solicitações de recebimento quando elas são totalmente concluídas com o recurso, eles optam por enviar solicitações de recebimento à medida que fazem pequenas alterações. Um exemplo dessa mudança será a criação de um novo modal, assumindo que o desenvolvedor esteja trabalhando em um recurso que permita aos usuários gerenciar tarefas individuais no aplicativo. Em vez de aguardar até que o recurso da tarefa seja concluído, para aderir a um padrão de integração contínuo, o desenvolvedor envia essa pequena alteração (quando comparado ao que está trabalhando) e cria uma solicitação pull para mesclar com o código.

Antes que essa nova mudança seja integrada, é necessário executar uma série de testes.

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 forma que sejam executados assim que uma solicitação de recebimento for enviada ao ramo de destino selecionado durante a instalação.

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

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

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

Tipos de testes

Ao escrever 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 individuais ou componentes do software, como métodos ou funções.
  • UI – afirma que o software funciona bem da perspectiva do usuário.
  • Aceitação – testa se o software atende aos requisitos de negócios.

É importante observar que você não precisa testar tudo isso, pois alguns deles já podem estar cobertos no código escrito pelo desenvolvedor.

Ferramentas de Integração Contínua

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

  • Travis CI – conhecido no mundo de código aberto e promete que seu código seja testado perfeitamente em minutos.
  • CI do círculo – fornece energia, flexibilidade e controle para automatizar seu pipeline do controle à implantação.
  • Jenkins – fornece centenas de plugins para dar suporte à criação, implantação e automação de qualquer projeto.

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

Implantação Contínua

De que será bom se o recurso que você criar ficar no repositório por semanas ou meses antes de ser implementado no ambiente de produção. Por mais que as equipes de engenharia possam trabalhar para integrar pequenas mudanças no ramo principal, 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 é obter as alterações feitas pelos usuários assim que os desenvolvedores integrarem essas alterações na ramificação principal.

Como no caso da integração contínua, ao usar a implantação contínua, testes e verificações automatizados são configurados para garantir que as alterações recém-integradas sejam verificadas. A implantação ocorre apenas quando esses testes passam.

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

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

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

Conclusão

A produtividade de uma equipe de desenvolvimento é vital para o sucesso dos negócios. Para garantir que sejam produtivos, devem ser adotadas práticas que incentivem isso. Integração e implantação contínuas são exemplos dessas 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 ao usuário o mais rápido possível. A implantação dessas alterações possibilita a obtenção de feedback dos usuários. No final, o negócio poderá inovar com base no feedback recebido, que é uma vantagem para todos..

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

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map