Integração contínua
Na engenharia de software, integração contínua (IC), do inglês 'continuous integration (CI), é a prática de mesclar todas as cópias de trabalho dos desenvolvedores em uma linha principal compartilhada, várias vezes ao dia.[1] Grady Booch propôs pela primeira vez o termo IC em seu método de 1991,[2] embora ele não tenha defendido a integração várias vezes ao dia. A programação extrema, Extreme Programming (XP) em inglês, adotou o conceito de IC e defendeu a integração mais de uma vez por dia - talvez até dezenas de vezes ao dia.[3]
Justificativa
Ao iniciar uma mudança, um desenvolvedor obtém uma cópia da base de código atual com a qual trabalhar. À medida que outros desenvolvedores enviam o código alterado para o repositório de código-fonte, esta cópia deixa gradualmente de refletir o código do repositório. Não apenas a base de código existente pode mudar, mas um novo código pode ser adicionado, bem como novas bibliotecas e outros recursos que criam dependências e conflitos potenciais.
Quanto mais o desenvolvimento continuar em um branch sem se fundir de volta à linha principal, maior será o risco de vários conflitos de integração[4] e falhas quando o branch do desenvolvedor for eventualmente fundido de volta. Quando os desenvolvedores enviam código para o repositório, eles devem primeiro atualizar seu código para refletir as mudanças no repositório desde que fizeram sua cópia. Quanto mais mudanças o repositório contém, mais trabalho os desenvolvedores devem fazer antes de enviar suas próprias mudanças.
Eventualmente, o repositório pode se tornar tão diferente das linhas de base dos desenvolvedores que eles entram no que, às vezes, é chamado de "inferno de fusão" (merge hell) ou "inferno de integração" (integration hell),[5] onde o tempo que leva para integrar excede o tempo que levou para fazer suas alterações originais.[6]
Fluxos de trabalho (workflows)
Executar testes localmente
A Integração Contínua deve ser usada em combinação com testes de unidade automatizados, escritos por meio de práticas de desenvolvimento orientado a testes. Isso é feito executando e passando todos os testes de unidade no ambiente local do desenvolvedor antes de se enviar (commit) à linha principal. Isso ajuda a evitar que o trabalho em andamento de um desenvolvedor interrompa a cópia de outro desenvolvedor. Onde necessário, recursos parcialmente completos podem ser desabilitados antes de confirmar, usando alternadores de recursos, por exemplo.
Compilação de código em Integração Contínua
Um servidor de compilação compila o código periodicamente ou mesmo após cada envio (commit) e relata os resultados aos desenvolvedores. O uso de servidores de compilação foi introduzido fora da comunidade XP (programação extrema) e muitas organizações adotaram IC sem adotar todo o XP.
Referências
Ligações externas
- «Continuous Integration» (wiki). C2 (a collegial discussion)
- Richardson, Jared. «Continuous Integration: The Cornerstone of a Great Shop» (introduction)
- Flowers, Jay. «A Recipe for Build Maintainability and Reusability». Consultado em 28 de maio de 2006. Cópia arquivada em 25 de junho de 2020
- Duvall, Paul (4 de dezembro de 2007). «Developer works»
- «Version lifecycle». MediaWiki
- «Continuous Integration in the Cloud» (PDF). CrossTalk. 2016[ligação inativa]
- «Continuous Integration Introduction». Katalon. 2019
- Bugayenko, Yegor. "Why Continuous Integration Doesn't Work"
