Continuous Integration (CI) é uma prática de engenharia de software e DevOps em que os desenvolvedores frequentemente publicam suas alterações de código em um repositório central, geralmente aplicando previamente algumas técnicas de testes unitários.
A integração contínua é a etapa inicial de um pipeline automatizado de entrega contínua, onde o time de desenvolvimento culturalmente se habitua a integrar seu código com frequência. Para a integração contínua os desenvolvedores geralmente usam um sistema de controle de versões, como o Git.
Antigamente era comum que desenvolvedores de um mesmo time trabalhassem isoladamente por longos períodos sem atualizares seus repositórios locais com o repositório central, somente fazendo essa atualização após a conclusão de um extenso pacote de novas funcionalidades. Esse processo de etapas longas de desenvolvimento tornou o merge de código algo difícil e demorado. Também impacta diretamente na qualidade do software, pois a correção de bugs ou a entrega de novas funcionalidades passa por um processo lento e custoso.
Com a integração contínua o repositório central é frequentemente atualizado com pequenas partes de código novo ao invés de ser atualizado apenas uma vez por semana com uma grande quantidade de alterações no código. Essa prática visa reduzir tempo e custo gastos no trabalho de resolver conflitos no código.
Se o código não for constantemente atualizado no repositório central, é provável que o tempo necessário para a correção de conflitos seja até maior que o tempo que os desenvolvedores gastaram para escrever o novo código. Isso se torna um tremendo desperdício de tempo e de dinheiro.
Quando um desenvolvedor começa a atuar em um novo código, ele baixa uma cópia da última versão estável do software para sua máquina. Com o passar das horas, outros desenvolvedores enviam seus respectivos códigos para o repositório central e, com isso, o código inicialmente baixado fica desatualizado. Quanto mais tempo levar para o desenvolvedor subir seu novo código para o repositório central, maiores serão as chances de conflitos e mais tempo será gasto na resolução destes. Por isso a necessidade de constantemente fazer merge de pequenas porções de código ao invés de segurar o código consigo por vários dias e, somente depois, tentar fazer o merge com um repositório que já teve várias atualizações.
Quando chegar o momento de o código ser mergeado com o repositório central, é preciso seguir alguns passos para garantir que sua atualização não quebre o software.
O desenvolvedor deve primeiramente atualizar seu repositório local com a última versão que consta no repositório central. Caso existam conflitos, estes serão pequenos e bem mais simples de se resolver. Após este passo, é uma boa prática que o desenvolvedor execute localmente testes unitários do seu código. Somente após estes passos é que o código estará pronto para ser mergeado com o repositório central.
Um processo de integração contínua inclui automações para validar se o código pode ser compilado corretamente e também se este código já compilado passa pelos testes unitários previamente definidos. Caso a compilação do código ou o teste unitário falhe, o processo de Continuous Integration é considerado falho, e a atualização do código não é aceita no repositório central.
Dentro de um processo ágil de entrega de software, a saída do processo de Continuous Integration é a entrada para o processo de Continuous Delivery ou Continuous Deployment.
Como vimos, a implementação de um processo de Continuous Integration trará muitas vantagens para seu time de desenvolvimento, porém é com a junção com Continuous Delivery ou com Continuous Deployment que sua empresa dará um enorme salto rumo à dezenas de deploys por dia!