O que é CI (integração contínua)? 

A integração contínua é a primeira parte do pipeline de CI/CD, um fluxo de trabalho de DevOps automático que simplifica o processo de entrega de software. A integração contínua possibilita que as equipes de DevOps melhorem continuamente seus aplicativos de software, recebam feedback uniforme, detectem e corrijam erros antes de afetarem o desempenho do software e entreguem software de maior qualidade em cronogramas de entrega mais previsíveis. 

Quando um desenvolvedor envia alterações de código para uma ramificação principal ou compartilhada de um sistema de controle de versão, a ação aciona uma ferramenta de CI para executar uma "compilação" da base de código atualizada. O sistema de CI pega o novo código, compila com o código existente e o empacota com todas as dependências, como arquivos de configuração, bibliotecas ou outros recursos. Isso constitui a "compilação" ou "build".

São realizados testes automáticos para validar essa compilação antes de ser produzido um "artefato de compilação", o arquivo resultante que é repassado para testes adicionais ou para um ambiente de produção. A próxima parte do pipeline é chamada de entrega contínua.

A CI foi criada como uma solução para os desafios associados ao desenvolvimento de software tradicional, especificamente seus processos de integração e implementação. Nos paradigmas de desenvolvimento tradicionais, cada desenvolvedor é responsável pela integração manual do novo código em novas iterações de um aplicativo ou serviço, tornando a integração um processo demorado e propenso a erros, especialmente para grandes equipes de desenvolvimento.

Diversas partes do código nem sempre funcionavam bem juntas e os desenvolvedores integravam suas alterações em diversos cronogramas (às vezes, no último minuto). Então o feedback sobre problemas de integração frequentemente era atrasado. Quando surgiam problemas, os atrasos no feedback tornavam mais difícil para as equipes descobrirem qual mudança havia causado o problema e tornavam a depuração um processo mais árduo.

Além disso, os testes de software eram pouco frequentes. As equipes normalmente implementavam grandes atualizações em lote de uma só vez, o que permitia que bugs passassem despercebidos e se acumulassem na base de código. Consequentemente, as equipes de desenvolvimento encontraram tarefas de solução de problemas mais difíceis, maiores taxas de falhas e lançamentos de código mais lentos; as empresas perderam receita devido a ineficiências de processos; e os usuários viram mais erros e falhas de software.

A integração contínua — um componente fundamental das práticas modernas de DevOps, pipelines de integração contínua/implementação contínua (CI/CD) e arquiteturas de microsserviços — ajuda a simplificar o processo de construção, enviando feedback rápido sobre o desempenho da integração.

Com um sistema de CI, o novo código é adicionado a um repositório central (normalmente, várias vezes ao dia), onde permanece para construção e testes. Se o sistema detectar um erro, ele envia notificações, corrige o código e confirma se o código atualizado está correto antes de mesclá-lo totalmente com a base de código do software.

Embora a configuração exata de um sistema de integração contínua varie de equipe para equipe e de empresa para empresa, todo sistema de CI utiliza determinados componentes e processos para otimizar as tarefas de integração de código.

A CI começa com um repositório central e compartilhado onde todos os desenvolvedores enviam seu código. Os repositórios centrais servem como base das práticas de IC. Sistemas de controle de versão (VCSs), como Git e Bitbucket, geralmente gerenciam esses repositórios. Quando os desenvolvedores enviam alterações, o repositório central as rastreia, criando um histórico completo das alterações de código que as equipes de desenvolvimento podem usar para colaborar com mais eficiência.

Os repositórios também utilizam técnicas de ramificação, que criam linhas separadas de desenvolvimento para isolar as alterações de código em andamento da base de código principal (a ramificação principal) e facilitar o desenvolvimento paralelo. A ramificação possibilita que os desenvolvedores criem ramificações de funcionalidades (para isolar funcionalidades específicas do aplicativo) e ramificações de curta duração para separar seu trabalho antes de mesclá-lo novamente na ramificação de código principal.

O Gitflow, por exemplo, é um modelo de ramificação baseado no Git que atribui funções (como "principal", "funcionalidade", "desenvolvimento" e "lançamento") a diferentes ramificações para controlar como elas interagem entre si. Os desvios do Gitflow exigem que os desenvolvedores criem desvios de funcionalidade e esperem até que a funcionalidade seja concluída para mesclar as mudanças de código no desvio principal.

Os servidores de CI são ferramentas que centralizam e gerenciam todas as operações de CI. Servem como central de automação do processo de CI. Os servidores de CI monitoram os repositórios em busca de alterações no código e Initiate e Power pipelines de CI predefinidos quando alterações são detectadas. Os servidores de CI executam compilações, testes e lançamentos de software automáticos; organizam protocolos de controle de versão; lidam com relatórios de status; e suportam plug-ins que podem aprimorar a funcionalidade do sistema.

Muitos servidores de CI apresentam funcionalidades que ajudam as equipes a modelar e visualizar fluxos de trabalho e construir seus pipelines de entrega contínua (CD).

Os sistemas de CI incentivam os desenvolvedores a enviar alterações de código várias vezes ao dia, priorizando pequenas alterações focadas em tarefas ou funcionalidades específicas. As ferramentas de CI possibilitam que as equipes iniciem revisões de código e discutam problemas antes de mesclarem um novo código, para que os erros sejam detectados mais cedo no processo de desenvolvimento.

Um sistema de CI baseado no Git pode, por exemplo, iniciar solicitações de pull para buscar alterações de código de uma ramificação local (armazenar localmente no computador de um único desenvolvedor) e integrá-las à ramificação remota atual (armazenar remotamente e compartilhada por toda a equipe de desenvolvimento). E as solicitações de mesclagem possibilitam que os desenvolvedores integrem as alterações propostas de uma ramificação local com outra ramificação local para avaliação, discussão e aprovação da equipe antes de mesclá-las com a ramificação remota.

Servidores e ferramentas de integração contínua (incluindo ferramentas populares de código aberto, como Jenkins, CircleCI, GitHub, AWS CodePipeline e GitLab CI) monitoram o repositório central em busca de alterações de código. Quando detectam uma nova alteração, os servidores de CI disparam o processo de compilação e executam fluxos de trabalho predefinidos e scripts de compilação, compilando e empacotando o código em preparação para testes e, no final das contas, implementação.

As ferramentas de CI executam uma série de testes para validar o código antes que ele seja mesclado com a base de código. Os testes unitários validam componentes ou funções individuais, fornecendo feedback imediato sobre o comportamento do código. Os testes de integração avaliam as interações entre componentes e módulos de software para garantir que estejam funcionando corretamente em conjunto e para detectar quaisquer problemas que os testes de unidade possam não ter detectado.

Em alguns fluxos de trabalho de CI, os testes de ponta a ponta validam o software simulando interações do usuário para verificar se o software se comporta corretamente da perspectiva do usuário. As equipes também podem executar testes de qualidade de código e análises estáticas para verificar a capacidade de resposta e a estabilidade da aplicação sob carga e para identificar violações de padrões de programação e vulnerabilidades de segurança.

Os servidores de CI notificam os desenvolvedores imediatamente se uma compilação ou teste falhar. Quando há uma falha, os desenvolvedores podem priorizar o reparo do código para ajudar a garantir que a ramificação principal permaneça implementável.

Se a criação de um software for bem-sucedida, os servidores produzirão artefatos — arquivos, como código compilado, imagens e bibliotecas do Docker, criados durante o processo de criação — que são versionados e armazenados em repositórios para testes e implementação futuros. Independentemente do resultado, os principais sistemas de CI registram tentativas de integração, taxas de sucesso e outras métricas para garantir que os membros da equipe possam sempre acessar a documentação abrangente da versão.

Os testes são um componente vital dos processos de integração contínua. No mínimo, os testes constituem cerca de um terço das atividades de CI, mas isso só acontece quando as equipes executam um único estágio de teste. Muitas vezes, as atividades de teste constituem a maior parte da carga de trabalho das ferramentas de CI. 

Os testes contínuos em um ambiente de CI começam quando um desenvolvedor envia um novo código para uma base de código. Essa ação aciona um processo de compilação e um teste automático. Em muitos casos, testes adicionais são realizados após a criação de um artefato de compilação (antes de o código entrar em produção). Também é importante que os desenvolvedores executem testes (e subconjuntos de testes) em seu ambiente local para ajudar a garantir que eles só enviem o código-fonte para o controle de versão depois que as novas alterações de código forem aprovadas nos testes.

Esse teste multifacetado de várias funções, casos de uso e integrações é chamado coletivamente de pacote de testes. Essa abordagem maximiza a cobertura do teste, evita a regressão e estabelece as bases para uma entrega contínua bem-sucedida.

O desenvolvimento baseado em testes (TDD) é outra abordagem para o desenvolvimento de software. O TDD é uma abordagem em que os desenvolvedores "trabalham de trás para frente", desenvolvendo um teste antes de escrever qualquer código. Nessa abordagem, os desenvolvedores escrevem um caso de teste no nível da unidade que falha, antes de escrever a quantidade mínima de código para fazê-lo passar. Feito isso, o código de teste e de produção pode ser refatorado e aprimorado.

Essa abordagem ajuda os desenvolvedores a se concentrarem em requisitos bem definidos e a evitarem códigos estranhos. Também enfatiza o feedback contínuo e pode ser uma técnica bem-sucedida para acelerar os ciclos de desenvolvimento.

Os pipelines de DevOps aceleram a entrega de software de alta qualidade, automatizando e combinando os esforços das equipes de desenvolvimento e operações de TI, que tradicionalmente existiam em silos separados.

Os processos e culturas de DevOps bem-sucedidos vão além do desenvolvimento e das operações, incluindo engenharia de plataforma e infraestrutura, segurança, conformidade, governança, gerenciamento de riscos, linha de negócios, usuários finais e clientes. Em outras palavras, um bom DevOps deve incorporar o input de todos os stakeholders da aplicação ao ciclo de desenvolvimento de software.

Em uma estrutura de DevOps, a integração contínua fica no início do processo de desenvolvimento de software e do pipeline de CI/CD. A CI possibilita que os desenvolvedores verifiquem frequentemente seu código para evitar que cópias locais se afastem muito da ramificação principal da compilação do código. Essa abordagem ajuda as equipes a evitar conflitos de mesclagem que podem "quebrar" a compilação nas fases de entrega e implementação.

A CI também possibilita que os desenvolvedores enviem atualizações pequenas e frequentes que promovem ciclos de feedback rápidos e consistentes e melhoria contínua com base na priorização das necessidades do cliente – princípios fundamentais da filosofia DevOps.

A integração contínua é a primeira parada no pipeline de CI/CD e normalmente é seguida por processos de entrega contínua e implementação contínua. A integração contínua refere-se às mesclagens frequentes de código e às compilações e testes de unidade que se seguem.

A entrega contínua (CD) pega onde a integração contínua deixa, automatizando a entrega de alterações de base de código validadas (incluindo atualizações, correções de bugs e até mesmo novas funcionalidades) em ambientes selecionados ou repositórios de código. As equipes DevOps recebem notificações sobre a compilação mais recente e podem migrar manualmente as atualizações para um ambiente de produção ao vivo. O objetivo do estágio do Delivery Pipeline contínua é implementar novo código com o mínimo de esforço, mas ainda permitir um nível de supervisão humana antes que o código seja ativado.

A implementação contínua libera automaticamente as alterações de código para os usuários finais depois de passar por uma série de testes predefinidos, como testes de integração que testam o código em um ambiente espelhado para ajudar a garantir a integridade do código. Tanto a entrega contínua quanto a implementação contínua lidam com a automação mais abaixo do pipeline do que a CI e geralmente são usadas de forma intercambiável.

A diferença entre a entrega contínua e a implementação contínua está no nível de automação empregado nas versões de software ou aplicativo. Na entrega contínua, o código migra automaticamente para ambientes semelhantes aos de produção para testes adicionais e garantia de qualidade, como a avaliação de riscos e a identificação de vulnerabilidades no código-fonte. É necessária a intervenção humana para migrar à produção após testes bem-sucedidos.

Na implementação contínua, a automação vai além. Depois que o código for aprovado no teste, a implementação na produção ocorrerá automaticamente, sem necessidade de aprovação humana.¹

O desenvolvimento ágil é uma abordagem iterativa da engenharia de software que prioriza a flexibilidade, a colaboração, a melhoria contínua e a rápida adaptação às mudanças. É uma prática que organiza o desenvolvimento em grupos menores de trabalho — ou “sprints” — para otimizar a colaboração entre desenvolvedores e stakeholders e acelerar a entrega de software.

Da mesma forma, a CI exige atualizações frequentes e graduais de código e validação constante do código. É uma abordagem iterativa para o desenvolvimento que possibilita aos desenvolvedores atualizar e dimensionar rapidamente as soluções de software com o passar do tempo e entregar produtos de alta qualidade aos usuários com mais rapidez. Como tal, a integração contínua é uma prática inerentemente ágil. 

A integração contínua ajuda as equipes de desenvolvimento a iterar mais rapidamente e disponibilizar software melhor aos usuários, mas há etapas adicionais que uma empresa pode seguir para otimizar o processo. As práticas de CI comumente implementadas são:

As práticas de integração contínua — e mais amplamente frameworks de DevOps — ajudam as empresas a agilizar a colaboração e a integração de código e a manter Delivery Pipelines contínuos. Tais práticas melhoram a qualidade do software e aceleram os processos de lançamento de software. As ferramentas modernas de CI incorporam uma variedade de tecnologias emergentes que fortalecem essas práticas e aumentam seu valor.

Por exemplo, o uso de inteligência artificial (IA) e aprendizado de máquina (ML) em processos de integração contínua está se tornando prática de desenvolvimento padrão. As ferramentas habilitadas por IA podem ajudar os desenvolvedores a criar sistemas de autocorreção que identificam e corrigem códigos problemáticos de forma automática e autônoma antes que eles afetem o fluxo principal de desenvolvimento. Os sistemas de CI baseados em ML também podem gerar automaticamente casos de teste personalizados com base em envios e modificações de código, para que os desenvolvedores passem menos tempo criando testes de código manualmente.

Com ameaças cibernéticas cada vez mais sofisticadas,² os desenvolvedores estão cada vez mais incorporando práticas de segurança diretamente no processo de desenvolvimento de software. Essas estratégias de segurança "shift-left" introduzem verificações de segurança nas primeiras fases do desenvolvimento, inclusive nos processos de CI, para ajudar a garantir que as vulnerabilidades sejam detectadas durante a codificação e não após a implementação.

Atualmente, o Kubernetes e o ecossistema mais amplo de tecnologias relacionadas a contêiner formam os blocos de construção dos ambientes de TI modernos. O DevSecOps integra a segurança em todas as fases do DevOps para enfrentar os desafios de segurança que acompanham esses ecossistemas dinâmicos.

Contêineres são unidades executáveis de software que empacotam o código da aplicação junto com suas bibliotecas e dependências para que o código possa ser executado em qualquer ambiente de computação. E o Kubernetes — também conhecido como k8s ou kube — é uma plataforma de orquestração de contêineres de código aberto para agendar e automatizar a implementação, o gerenciamento e o dimensionamento de aplicações conteinerizadas.

Tradicionalmente, as equipes de DevOps contavam com uma equipe de segurança separada para identificar vulnerabilidades e, em seguida, usavam feedback para implementar alterações de código na rodada seguinte de atualizações de aplicativos. Agora espera-se que os desenvolvedores protejam contêineres e clusters e apliquem princípios zero trust em todas as suas aplicações e no processo de desenvolvimento, o que reflete um novo paradigma operacional^.3 A adoção de práticas de DevSecOps significa que a programação e o desenvolvimento de software não se concentram somente na construção de funcionalidades, mas também na antecipação de riscos.

A computação sem servidor e as arquiteturas nativas da nuvem também são prioridades para as equipes DevOps atuais.

A computação sem servidor é um modelo de execução e desenvolvimento de aplicações que possibilita que os desenvolvedores criem e executem códigos de aplicações sem precisar aprovisionar nem gerenciar servidores ou infraestruturas de back-end. Há de fato servidores em configurações sem servidor, mas são totalmente gerenciados por um provedor de serviço de nuvem (CSP). Em pipelines de CI, as plataformas sem servidor liberam os desenvolvedores de preocupações com infraestrutura de back-end para poderem se concentrar na programação de front-end e na lógica do negócio.

Com a proliferação de computação sem servidor e aplicativos de IA, as arquiteturas baseadas em eventos (EDAs) desempenham papel central para ajudar as equipes a lidarem com a crescente complexidade da computação em nuvem. Os EDAs oferecem suporte à comunicação em tempo real entre sistemas front-end e back-end fracamente acoplados, permitindo que os sistemas funcionem de forma independente e processem eventos (qualquer alteração ou ação que ocorra em um sistema) de forma assíncrona.

Nos pipelines de CI, isso significa que os desenvolvedores podem dimensionar componentes individuais de aplicativos sem afetar toda a aplicação, o que ajuda as equipes a criar bases de código e processos de integração mais ágeis, responsivos e escaláveis.

A configuração de um pipeline de CI robusto exige planejamento e configuração cuidadosos, incluindo a escolha das ferramentas certas, a definição de fluxos de trabalho de compilação e teste e a configuração da infraestrutura. Os pipelines de CI também exigem manutenção regular para acomodar alterações na base de código, dependências (como APIs) e infraestrutura.

No entanto, adotar a integração contínua pode trazer uma série de benefícios para as equipes de desenvolvimento de software, como:

Os processos de CI possibilitam que as equipes resolvam os erros antecipadamente, às vezes minutos após o envio do código.

Todos da equipe podem alterar o código, mesclar alterações no código e identificar incompatibilidades e erros de integração, simplificando o compartilhamento de conhecimento e melhorando a qualidade do código e do software por meio do feedback dos colegas.

Como o novo código é integrado continuamente, as equipes gastam menos tempo integrando e testando grandes lotes de código. E o loop de feedback acelerado que as ferramentas de CI oferecem ajuda os desenvolvedores a iterar e entregar atualizações de software e novos produtos aos usuários finais com mais rapidez.

Confirmações frequentes de código significam mudanças menores e mais graduais, que são mais fáceis de entender, avaliar e testar. Isso reduz o risco de introduzir problemas significativos na base de código durante o desenvolvimento.