Os fundamentos da integração contínua em DevOps

Em seu cerne, o DevOps busca aumentar a velocidade dos lançamentos de software enquanto garante um produto final confiável e seguro, e a CI é essencial para que isso seja feito.

A CI é uma prática cultural que encoraja os desenvolvedores a fazerem merge regularmente de seu código em um repositório compartilhado. Mas a CI também é um processo técnico, onde uma mistura de automação e ferramentas são usados para aumentar a velocidade com a qual as mudanças de código são integradas, testadas e preparadas para implantação.

Esse guia vai falar de:

• Porque a integração é necessária

• Melhores práticas da integração contínua

• Os benefícios da integração contínua

• Como um pipeline de integração contínua funciona

• Como criar um pipeline de integração contínua bem-sucedido

Por que a integração contínua é necessária?

A CI busca encorajar ciclos de desenvolvimento mais rápidos e mais eficientes ao resolver um problema importante no desenvolvimento de software: o gerenciamento dos desafios de integração de código em um repositório compartilhado com vários contribuidores.

Quando um desenvolvedor começa a trabalhar em uma atualização de software ou na solução de um bug, ele faz uma cópia da base de código com a qual trabalhar. Isso é feito usando um sistema de controle de versão como o Git, que permite aos desenvolvedores criarem uma cópia, ou “fork,” da base de código.

Conforme mais desenvolvedores criam cópias da base de código, a integração das alterações feitas por vários contribuidores torna-se um desafio, especialmente quando a base de código na qual um desenvolvedor começou a trabalhar fica desatualizada e não é mais correspondente ao repositório principal.

Na pior das hipóteses, pode levar mais tempo para integrar com sucesso as mudanças de código do que para fazer as alterações em si, conforme cada desenvolvedor tenta corrigir a falta de correspondência do seu código. Os desenvolvedores geralmente chamam isso de “inferno de integração”.

A CI busca impedir que isso aconteça, encorajando os desenvolvedores a integrar as mudanças conforme elas são feitas. A CI também utiliza a automação para aumentar a velocidade na qual os códigos são integrados e testados, para garantir que nenhuma mudança adicional seja necessária e reduzindo o ônus para o desenvolvedor. Essa combinação de integrações de código mais frequentes com a compilação e testagem automatizada ajuda a acelerar o processo de desenvolvimento de software.

Melhores práticas ao adotar a integração contínua

Cada empresa vai definir sua prática de CI conforme suas necessidades únicas. Algumas empresas podem introduzir testes automatizados de segurança mais rigorosos, outras podem priorizar o code merge e reservar os testes automatizados mais demorados para uma etapa posterior no ciclo de vida de desenvolvimento de software (SDLC).

Apesar disso, os pipelines de CI eficientes compartilham um conjunto de ferramentas e melhores práticas em comum. Esses incluem:

Um repositório de código compartilhado

Um repositório de código compartilhado em um sistema de controle de versão é fundamental para criar uma prática de CI eficiente. Além de servir como um lugar para armazenar códigos, scripts, testes automatizados e tudo mais, os sistemas de controle de versão também permitem aos desenvolvedores criarem vários branches com os quais trabalhar.

Commits de código regulares

A automação, testes e ferramentas são importantes para criar um pipeline eficiente, mas sem uma mudança cultural da equipe para priorizar as mudanças de código no commit frequentes, você provavelmente não chegará muito longe. Não existem regras absolutas para a frequência com a qual os desenvolvedores devem fazer commit do código. Porém, uma boa regra geral é que quanto maior for a frequência dos commits individuais, mais produtivo será o ambiente de desenvolvimento.

Automação de compilação

A automação de compilação é um componente crucial do pipeline de CI e permite que as equipes padronizem suas compilações de software. Um processo típico de compilação inclui compilar o código-fonte, gerar instaladores de software e garantir que todos os itens necessários estejam no lugar para apoiar uma implantação de sucesso. Em uma prática de CI, esse processo é automatizado para ajudar a integrar os commits de código na base de código.

Testes automatizados

Você pode fazer muitos commits e ter um processo automatizado de compilação. Mas o fato de ser possível executar um programa não significa que ele está sendo executado corretamente. É aí que entra o teste. Testes automatizados são uma parte essencial dos pipelines de CI. Cada commit aciona um conjunto de testes para identificar bugs, falhas de segurança e problemas de commit. Esses testes são feitos para manter o branch de código principal operacional, ou “verde”, e para dar feedback rápido aos desenvolvedores sobre a eficiência de suas mudanças de código.

Os benefícios da integração contínua

No seu ponto de maior eficiência, a CI permite que as organizações construam software mais rápido, lancem software mais confiáveis e melhores a integridade geral do negócio.

Mas essas são vantagens de alto nível para a organização de maneira geral. Na prática, você pode esperar vários benefícios materiais ao adotar a CI. Esses incluem:

Mudanças de código mais rápidas

Como a CI prioriza commits de código mais rápidos, as organizações frequentemente veem uma melhoria na velocidade do trabalho de suas equipes de desenvolvimento. Cada desenvolvedor está trabalhando em um pedaço menor de uma determinada peça de software, juntamente com outros membros da equipe. E como a CI pede por mudanças de código menores e regulares em vez de grandes atualizações de código, isso simplifica a integração, teste e, em última instância, o envio de código aos usuários finais.

Maior confiabilidade de testes

Organizações que adotam a CI com sucesso normalmente reportam uma maior confiabilidade nos testes. Isso acontece porque o teste se torna contínuo, e passa a fazer parte da rotina do ciclo de vida de desenvolvimento de software. Quando um teste falha, isso indica falhas no software ou que o teste em si precisa ser reescrito. Com testes mais confiáveis, os pipelines de CI podem facilitar melhor uma velocidade de desenvolvimento mais rápida, integração de código e lançamentos de software.

Isolamentos de falha

O isolamento de falhas é um conceito técnico onde os desenvolvedores constroem sistemas que minimizam o escopo e os danos de problemas em potencial. O uso de isolamentos de falha em pipelines de CI é uma prática e benefício comum. Com frequência, os desenvolvedores combinam o teste automatizado com o isolamento de falhas e o monitoramento do sistema para impedir grandes falhas de software na fase de compilação, e para que cada problema seja mais fácil de solucionar.

Tempo médio de resolução (MTTR) melhorado

O MTTR é uma medição de quanto tempo leva para solucionar um erro de código. Equipes que praticam bons procedimentos de DevOps podem usar o MTTR para medir o quanto são bem sucedidos no tempo de manutenção e na resolução de problemas que causam falhas. Como as práticas de CI favorecem mudanças de código pequenas e incrementais, os negócios que adotam pipelines de CI frequentemente veem medições de MTTR melhoradas e um desempenho de tempo de operação melhorado (tipicamente em conjunto com implantações automáticas).

Taxas de lançamento de software mais rápidas

Com uma melhora nos testes, MTTR e o uso de isolamentos de falha para limitar o escopo de erros em potencial, os pipelines de CI tipicamente resultam em taxas de lançamento de software mais rápidas. Porém, para que isso seja realmente garantido, as organizações precisam implementar a CI com sucesso tanto na cultura ao encorajar taxas mais frequentes de commit de código quanto na tecnologia com testes automatizados e criando um pipeline de CI completo. Parte disso é criar um ambiente de produção idêntico ao que os clientes usarão para testar o lançamento de software individualmente.

Menos backlogs de bugs não críticos

Pipelines de CI podem reduzir o número de bugs não críticos que atingem a produção quando os identificam por meio de testes automatizados antes de um lançamento de software. Ao fazer isso, os desenvolvedores têm a oportunidade de solucionar esses bugs e também reduzem os backlogs de bugs futuros e a dívida técnica. Isso permite que os desenvolvedores foquem mais em atualizações de recurso grandes, em vez de problemas do backlog.

Melhor comunicação em equipe

Os melhores pipelines de CI utilizam testes contínuos, monitoramento e relatórios para gerar um fluxo de feedback contínuo, que é usado para melhorar a estabilidade do software. O feedback contínuo também ajuda a melhorar a comunicação da equipe e as linhas de responsabilidade para resolver problemas conforme eles surgem.

Custos organizacionais menores

Os pipelines de CI confiam muito na automação, o que normalmente causa uma redução nos custos organizacionais. Um ditado comum nos ciclos de DevOps é que tudo que pode ser automatizado deve ser automatizado. Como prática cultural e técnica, a automação nos pipelines de CI reduz o risco de erro humano. Ela também libera recursos organizacionais para trabalhar na criação de códigos, em vez de fazer testes de códigos existentes.

Como um pipeline de integração contínua funciona?

Um pipeline de CI foca nas três primeiras fases do ciclo de vida de desenvolvimento de software (SDLC): compilação, teste e lançamento. Ao introduzir a automação e monitoramento a essas primeiras três fases, a CI acelera o SDLC e ajuda as organizações a implementarem software mais confiáveis.

Claro, é possível compilar, testar e lançar software manualmente. Mas a verdadeira vantagem da CI é que ela aplica automação a cada uma dessas etapas.

Fases de uma pipeline de CI

1. Compilação

Nessa fase o aplicativo é compilado. Em um pipeline de CI, a automação é usada para acionar um ciclo de compilação assim que um desenvolvedor faz as mudanças de código no commit no repositório principal. A partir daí, uma ferramenta de CI vai consultar as ferramentas de compilação do projeto para começar a compilar a aplicação em um ambiente de fase limpo. Contêineres são uma maneira popular e leve que as organizações usam com frequência para criar ambientes de compilação novos nessa fase.

2. Teste

Depois da aplicação ser compilada, uma série de testes são executados para garantir que o código funcione e que não há bugs ou problemas críticos. As organizações configuram sua ferramenta de CI para automatizar esses testes, para que eles comecem assim que a aplicação for compilada. Testes unitários, que são uma maneira de testar pequenas unidades de código, são um tipo de teste popular nessa fase pois são fáceis de escrever e baratos de executar e manter. O objetivo nessa fase do pipeline de CI é garantir que a base de código seja aprovada na inspeção.

3. Pacote

Em seguida, a organização começa a empacotar seu código. Em um pipeline de CI, essas etapas são automatizadas e acionadas assim que o testes unitários é concluído. A maneira como cada organização empacota seu código depende da linguagem de programação e do ambiente de produção. Uma organização usando contêineres de JavaScript e Docker, por exemplo, pode usar npm e imagens Docker para empacotar seu código.

Como começar a construir um pipeline de integração contínua bem-sucedido

Primeiro, uma realidade: nenhum modelo de CI é idêntico ao outro. Toda organização vai implementar uma CI de acordo com suas necessidades únicas e requisitos da sua equipe.

Porém, existem alguns passos comuns que todas as organizações precisam dar para implementar a CI com sucesso. Eles se resumem em sete práticas:

1. Criando uma estratégia de teste

Toda prática de CI começa com uma necessidade e uma estratégia de teste clara. Você precisará considerar quais tipos de teste está executando, o que aciona seu uso para compilar suas sequências de teste automatizado e quais testes são aplicáveis para cada branch de código no qual suas equipes de desenvolvimento estão trabalhando.

Como referência, existem três tipos de testes que são geralmente usados em um pipeline de CI:

• Testes unitários são testes simples que validam se uma função individual funciona em uma parte do código.

• Testes de integração garantem que as alterações de código sejam integradas adequadamente dentro da base de código mais ampla.

• Testes de aceitação verificam se uma aplicação atende aos requisitos funcionais. Alguns desses testes são chamados mais estritamente de testes de IU, que validam as funcionalidades esperadas de IU que um usuário vai encontrar.

Você não precisa começar com todos os três tipos de teste. A maioria das organizações começa com um teste de integração de unidade e vai avançado até chegar aos testes de aceitação.

2. Escolha uma ferramenta de CI

Escolher uma plataforma de CI é parte essencial da criação de um modelo de CI em qualquer organização. Essa é a ferramenta que vai acionar suas compilações automatizadas, testes, pacotes e lançamentos.

Será preciso fazer várias perguntas ao selecionar uma plataforma de CI. Esses incluem:

• Ela se integra bem com o seu stack de tecnologia atual? Uma plataforma de CI deve se integrar facilmente com todas as partes do seu stack, desde suas linguagens de programação até seu sistema de controle de versão ou suas ferramentas de terceiros. Também vale a pena considerar quaisquer tecnologias futuras que você possa adotar e procurar uma plataforma que possa crescer com você.

• Ela oferece suporte nativo a contêineres? Os contêineres são parte essencial de uma prática de DevOps e de CI, e é essencial garantir que sua plataforma de CI tenha suporte nativo para aplicações de contêiner como o Docker. Você pode não utilizar contêineres hoje, mas conforme sua prática de DevOps cresce, há uma boa chance de você acabar usando contêineres de alguma forma.

• Ela habilita capacidades de teste de compilação de matriz? A compilação de matriz permite que você teste compilações simultaneamente entre vários sistemas operacionais e versões de tempo de execução. Busque uma ferramenta de CI que ofereça suporte nativo para compilações de matriz, o que ajuda a otimizar seus testes e garante que sua aplicação vai funcionar para todos os seus usuários finais.

• Ela oferece cobertura de código integrada e visualização de testes? A cobertura de código e visualização de testes dão a você uma maneira simples de ver quanto da sua base de código está sendo testado no momento e como os testes existentes estão sendo executados em tempo real e foram executados historicamente.

• Como ela mapeia seus requisitos de segurança? A segurança é uma consideração muito importante em qualquer investimento de tecnologia, especialmente se esse investimento vai acabar sendo integrado na sua base de código e nos seus serviços essenciais.

3. Integre o código assim que possível

A adoção bem-sucedida da CI começa garantindo que seus desenvolvedores estão integrando seus códigos assim que possível em um repositório compartilhado.

Isso traz dois benefícios:

1. Você evita grandes conflitos de integração que podem surgir ao fazer merge de ramificações mais antigas de volta ao repositório principal.

2. Você acaba integrando regularmente mudanças de código menores, o que ajuda com a transferência de conhecimento entre suas equipes e simplifica o regime de teste.

Também é importante considerar como é o seu SDLC existente, e quais mudanças processuais você pode querer fazer no futuro conforme implementa um pipeline de CI. Essa não é uma conversa sobre se é melhor usar desenvolvimento com branches ou com troncos. Na verdade, é uma conversa sobre garantir que você tem um fluxo de trabalho do desenvolvedor organizado que facilita uma corrente constante de codificação, teste, merge e revisão.

4. Corrija sua ramificação principal assim que ela apresentar um problema

Uma boa regra geral é: corrija seu branch principal assim que ele apresentar um problema.

Em um modelo de CI, seus desenvolvedores devem estar integrando mudanças de código assim que possível. Isso é bom. Mas se uma mudança de código quebrar seu branch principal e seus desenvolvedores continuarem adicionando mais mudanças, fica difícil identificar o que causou a falha inicial.

Para fazer isso, escreva testes que notificam imediatamente os desenvolvedores se uma das suas alterações de código quebrarem o branch principal. Isso ajuda a criar um ciclo de feedback, que é uma prática importante de DevOps.

Certifique-se de equilibrar a velocidade de teste com a cobertura do teste no que diz respeito a manter suas compilações verdes, ou operacionais. Se seus testes demorarem muito, fica mais difícil encontrar exatamente qual mudança de código causou uma falha. Os melhores pacotes de teste começam com testes simples para começar, como testes de compilação e integração, antes de avançar para testes mais demorados.

5. Crie novos testes para cada novo recurso que for introduzido

Sob um modelo de CI, seu pacote de teste deve crescer junto com seu software ou aplicação. Isso significa que, conforme você cria novos recursos e prepara atualizações maiores, também deve criar testes para validar esses recursos.

Considere escrever os testes assim que novos recursos e correções de bugs forem criados. Isso pode parecer demorado, mas voltar depois de tudo pronto quase certamente levará mais tempo do que escrever os testes conforme você compila o código.