A integração contínua possibilita o desenvolvimento iterativo de software, reduz os riscos provenientes de defeitos e torna os desenvolvedores altamente produtivos.
O que é Integração Contínua?
A Integração Contínua (CI) é uma prática de desenvolvimento de software em que os desenvolvedores mesclam suas alterações ao branch principal várias vezes ao dia. Cada mesclagem aciona um processo automatizado de construção (build) e execução de testes, que idealmente é concluído em menos de 10 minutos. Um build bem-sucedido na CI pode levar a etapas posteriores de entrega contínua (continuous delivery).
Se um build falhar, o sistema de CI bloqueia o progresso para as etapas seguintes. A equipe recebe um relatório e corrige o problema rapidamente, geralmente em poucos minutos.
Para saber mais sobre CI, você pode assistir ao vídeo ou ouvir este episódio do podcast Technical Tips. Boas construções!
Hoje, todas as empresas de tecnologia competitivas praticam integração contínua. Trabalhando em pequenas iterações, o processo de desenvolvimento de software se torna mais previsível e confiável. Os desenvolvedores podem construir novas funcionalidades de forma iterativa. Os gerentes de produto conseguem levar os produtos certos ao mercado mais rapidamente. Os desenvolvedores podem corrigir bugs rapidamente e, geralmente, descobri-los antes que cheguem aos usuários.
A integração contínua exige que todos os desenvolvedores que trabalham em um projeto se comprometam com ela. Os resultados precisam estar disponíveis de forma transparente para todos os membros da equipe, e o status do build deve ser reportado aos desenvolvedores sempre que fizerem alterações no código. Caso o branch principal do código falhe na construção (build) ou nos testes, um alerta é enviado, geralmente, para toda a equipe de desenvolvimento, que deve agir imediatamente para restaurar o estado “verde” (green).
Por que precisamos de Integração Contínua?
Nos negócios, especialmente no desenvolvimento de novos produtos, muitas vezes não temos tempo ou a capacidade de resolver tudo de antemão. Dar passos menores nos ajuda a estimar com mais precisão e validar com mais frequência. Um ciclo de feedback mais curto significa ter mais iterações. E são o número de iterações, não o número de horas investidas, que impulsionam o aprendizado.
Para equipes de desenvolvimento de software, trabalhar em ciclos de feedback longos é arriscado, pois aumenta a probabilidade de erros e a quantidade de trabalho necessária para integrar mudanças em uma versão funcional do software.
Mudanças pequenas e controladas são seguras para acontecer com frequência. E ao automatizar todas as etapas de integração, os desenvolvedores evitam trabalho repetitivo e erros humanos. Em vez de ter pessoas decidindo quando e como rodar os testes, uma ferramenta de CI monitora o repositório central de código e executa todos os testes automatizados a cada commit. Com base no resultado total dos testes, ela aceita ou rejeita o commit do código.
Leia mais: sobre problemas de integração de software.
Extensão com Entrega Contínua
Uma vez que construímos e testamos nosso software automaticamente, fica mais fácil liberá-lo. Assim, a Integração Contínua é frequentemente estendida com a Entrega Contínua, um processo no qual as alterações de código também são automaticamente preparadas para uma liberação (CI/CD).
Em um processo CI/CD bem ajustado, todas as alterações de código são implantadas em um ambiente de staging, um ambiente de produção, ou ambos, após a fase de CI ser concluída.
A entrega contínua pode ser um fluxo de trabalho totalmente automatizado. Nesse caso, geralmente é chamada de Implantação Contínua (Continuous Deployment). Ou pode ser parcialmente automatizada, com etapas manuais em pontos críticos. O que é comum em ambos os cenários é que os desenvolvedores sempre têm um artefato de liberação da fase de CI que passou por um processo de testes padronizado e está pronto para ser implantado.
Leia mais: Sobre a diferença entre integração contínua, entrega contínua e implantação contínua.
Pipeline de CI e CD
CI e CD são frequentemente representados como um pipeline, onde o novo código entra em uma extremidade, passa por uma série de etapas (compilação, teste, staging, produção) e é publicado como uma nova versão de produção para os usuários finais na outra extremidade.
Cada etapa do pipeline de CI/CD é uma unidade lógica no processo de entrega. Os desenvolvedores geralmente dividem cada unidade em uma série de subunidades que são executadas sequencialmente ou em paralelo.
Por exemplo, podemos dividir os testes em testes unitários de baixo nível, testes de integração dos componentes do sistema trabalhando juntos e testes de alto nível da interface do usuário.
Além disso, cada etapa no pipeline atua como uma barreira que avalia um determinado aspecto do código. Problemas detectados em uma etapa inicial impedem que o código avance para as próximas etapas do pipeline. Não faz sentido executar todo o pipeline se houver bugs fundamentais no código que precisam ser corrigidos primeiro. Resultados detalhados e logs sobre a falha são enviados imediatamente para a equipe corrigir.
Como os pipelines de CI/CD são essenciais para o processo de desenvolvimento, alta performance e alta disponibilidade são fundamentais para a produtividade dos desenvolvedores.
Leia mais: sobre pipelines de CI/CD.
Pré-requisitos para realizar Integração Contínua
TOs pré-requisitos básicos para implementar integração contínua incluem:
- Automação de builds;
- Automação de testes;
- Commits mais frequentes em um único repositório de código-fonte, e
- Fornecer visibilidade do processo e acesso em tempo real ao status de CI para a equipe.
Equipes que ainda não praticam CI devem dar passos pequenos, melhorar continuamente e iterar no código e no processo de uma forma que ajude a organização a crescer.
A cada passo na jornada para o CI/CD completo, a produtividade da equipe de desenvolvimento aumentará, assim como a velocidade de todo o negócio.
Um fluxo de trabalho típico de desenvolvimento
Você pode aplicar integração contínua na maioria dos projetos de software, incluindo aplicativos web, microserviços nativos da nuvem, aplicativos móveis, software de sistemas, IoT / sistemas embarcados e muito mais.
O Semaphore integra-se ao GitHub, trazendo CI/CD para o processo de desenvolvimento padrão baseado em pull requests.
A qui está um fluxo de trabalho típico de integração contínua que os usuários do Semaphore praticam diariamente:
- Um desenvolvedor cria um novo branch de código no GitHub, faz alterações no código e realiza o commit.
- Quando o desenvolvedor envia seu trabalho para o GitHub, o Semaphore constrói o código e executa a suíte de testes automatizados.
- Se o Semaphore detectar algum erro no pipeline de CI (status: vermelho), o desenvolvedor recebe uma notificação no Slack ou vê uma mensagem no seu painel pessoal no Semaphore.
- Se o desenvolvedor tiver aberto um pull request, o Semaphore também reporta o status do CI na página do pull request no GitHub.
- Se o desenvolvedor tiver aberto um pull request, o Semaphore também reporta o status do CI na página do pull request no GitHub.
- Caso contrário, o usuário recebe uma notificação de que o CI passou (status verde). O Semaphore inicia automaticamente o próximo pipeline, que implanta uma nova versão da aplicação em um servidor de staging. Isso permite que o QA ou qualquer outra pessoa da equipe teste as alterações em um ambiente semelhante ao de produção.
- Depois que outro desenvolvedor verificar as alterações em uma revisão por pares, o autor pode mesclar o novo branch de código no branch master.
- O Semaphore executa mais um pipeline de build e teste no branch master, e quando ele passa, implanta uma nova versão do código em produção. A equipe recebe uma notificação sobre o novo lançamento via Slack.
Benefícios da Integração Contínua
A CI oferece inúmeros benefícios para a sua equipe de desenvolvimento de software, incluindo o aumento da produtividade dos desenvolvedores, a automação do processo de desenvolvimento, a melhoria da qualidade do código e a confiabilidade do software.
Aumento da produtividade dos desenvolvedores
O maior benefício de praticar a integração contínua é o aumento da produtividade dos desenvolvedores. A integração contínua liberta os desenvolvedores de tarefas manuais e das dificuldades de integrar seu código com outras partes do sistema. Em vez disso, eles podem se concentrar em programar a lógica que entrega as funcionalidades que o negócio precisa. Ou podem usar o tempo que a CI economizou para investir no crescimento profissional.
Equipes que trabalham em um loop de feedback rápido de CI podem entregar mais valor aos clientes do que equipes que enfrentam dificuldades para integrar o trabalho de cada um ou sofrem com um pipeline lento que não escala.
Entregar softwares que funcionam com mais frequência
A integração contínua é uma forma de sua equipe construir e testar automaticamente cada alteração no código-fonte. Esta é a base que permite que o seu processo de entrega de software mais amplo seja eficiente, resiliente, rápido e seguro.
Encontrar bugs mais cedo, corrigir mais rápido
O processo de testes automatizados pode incluir diversos tipos de verificações:
- Verificar a correção do código;
- Validar o comportamento da aplicação do ponto de vista do cliente;
- Comparar o estilo de codificação com as convenções padrão da indústria;
- Testar o código para falhas de segurança comuns;
- Detectar atualizações de segurança em dependências de terceiros;
- Medir a cobertura dos testes: quanto das funcionalidades da sua aplicação estão cobertas por testes automatizados.”
Incorporar esses testes no seu pipeline de CI, medir e melhorar a pontuação em cada um deles é uma maneira garantida de manter a alta qualidade do seu software.
Uma ferramenta de CI fornece feedback instantâneo aos desenvolvedores sobre se o novo código que eles escreveram funciona, ou se introduziu bugs ou regressões na qualidade. Erros detectados precocemente são os mais fáceis de corrigir.
Ferramentas de Integração Contínua
A integração contínua é, antes de tudo, um processo derivado da cultura da sua organização. Nenhuma ferramenta pode fazer com que os desenvolvedores colaborem em pequenas iterações, mantenham um processo de build automatizado e escrevam testes. No entanto, ter uma ferramenta de CI confiável para executar o processo é crucial para o sucesso.
O Semaphore foi projetado para permitir que sua organização construa um processo de CI de alto desempenho e altamente disponível, com quase escala ilimitada. O Semaphore oferece suporte para linguagens populares no Linux e iOS, com a capacidade de executar qualquer container Docker que você especificar.
Com as vantagens de uma integração estreita com o GitHub e a capacidade de modelar pipelines personalizados que podem se comunicar com qualquer ponto de extremidade na nuvem, o Semaphore é altamente flexível. Abraçando o modelo de computação sem servidor, seu processo de CI escala automaticamente sem tempo gasto em filas. Sua organização não tem nada para manter e paga com base no tempo gasto na execução.
Independentemente da ferramenta de CI que você escolher, recomendamos que escolha aquela que maximize a produtividade da sua organização. Em termos de funcionalidades, seu provedor de CI deve estar alguns passos à frente das suas necessidades atuais, para que você tenha a certeza de que ele pode lhe dar suporte à medida que você cresce.
Ferramentas de Build e Testes
Você pode considerar todas as ferramentas usadas dentro dos seus passos de build e testes como sua cadeia de valor de CI. Isso inclui ferramentas como analisadores de estilo de código e complexidade, ferramentas de automação de build e tarefas, frameworks de testes unitários e de aceitação, motores de testes de navegador, ferramentas de testes de segurança e performance, etc.
Escolha ferramentas que sejam amplamente adotadas, bem documentadas e ativamente mantidas.
A ampla adoção é refletida por um grande número de downloads de pacotes (frequentemente na casa dos milhões) e contribuições de código aberto. Fazer uma pesquisa sobre casos de uso comuns retorna um número sólido de exemplos de fontes confiáveis.
Ferramentas bem documentadas são fáceis de começar a usar. Um site de documentação pesquisável fornece informações sobre como realizar tarefas mais complexas. Você frequentemente encontrará livros que cobrem seu uso de forma profunda.
Ferramentas ativamente mantidas tiveram seu lançamento mais recente recentemente, pelo menos nos últimos 6 meses. O último commit no código-fonte ocorreu há menos de um mês. As melhores ferramentas evoluem com o ecossistema e fornecem correções de bugs e atualizações de segurança de forma oportuna.
Melhores Práticas de Integração Contínua
A seguir está um resumo breve das melhores práticas de CI.
Trate o build master como se você fosse fazer um lançamento a qualquer momento. O que implica algumas não práticas em toda a equipe:
- Não comente os testes com falha. Registre um problema e corrija-os em vez disso.
- Não faça check-in em um build quebrado e nunca vá embora com um build quebrado.
Mantenha o build rápido: até 10 minutos. Ficar mais lento é bom, mas não permite um loop de feedback rápido o suficiente.
Paralelize os testes. Comece dividindo por tipo (por exemplo, unitários e de integração) e depois adote ferramentas que possam paralelizar cada um deles.
Faça com que todos os desenvolvedores façam commit no master pelo menos 10 vezes por dia. Evite branches de funcionalidades de longa duração, que resultam em grandes merges. Construa novas funcionalidades de forma iterativa e use flags de funcionalidade para esconder o trabalho em andamento dos usuários finais.
Espere os testes passarem antes de abrir um pull request. Lembre-se de que um pull request, por definição, é um convite para que outro desenvolvedor revise seu código. Seja consciente do tempo dele.
Teste em uma cópia do ambiente de produção. Você pode definir seu ambiente de CI com uma imagem Docker e fazer com que o ambiente de CI corresponda totalmente ao de produção. Uma alternativa é personalizar o ambiente de CI para que bugs devido a diferenças com a produção quase nunca aconteçam.”Test in a clone of the production environment.
Use o CI para manter seu código. Por exemplo, execute fluxos de trabalho agendados para detectar versões mais recentes das suas bibliotecas e atualizá-las.
Mantenha o controle das métricas-chave: tempo total de build do CI (incluindo o tempo de fila, que sua ferramenta de CI deve manter em zero) e com que frequência seu master está em estado vermelho.