CI/CD
O que é CI/CD?
CI/CD, ou integração contínua/entrega ou implantação contínuas, é uma prática de desenvolvimento de software habilitada pela automação. Atualizações frequentes e confiáveis aceleram os ciclos de lançamento por meio de entrega contínua de código.
Explicação sobre CI/CD
CI/CD é um termo padrão que abrange várias fases de DevOps. CI (integração contínua) é a prática de integrar alterações de código em um repositório várias vezes por dia. O CD tem dois significados: A entrega contínua automatiza as integrações de código, enquanto a implantação contínua lança automaticamente as builds finais aos usuários finais. Os testes frequentes do CI/CD reduzem erros e defeitos de código, tornando-o essencial para qualquer fluxo de trabalho de DevOps.
O que é integração contínua? (CI)
A integração contínua (CI) é um processo automatizado de desenvolvimento de software que aumenta a velocidade do desenvolvimento enquanto garante código limpo e de qualidade em cada implantação. A integração contínua exige que os desenvolvedores façam check-in/commit suas unidades de código frequentemente em um repositório compartilhado central várias vezes por dia.
CI é uma prática recomendada DevOps e estádio no ciclo de vida DevOps quando os desenvolvedores fazem check-in de código em seu repositório de código compartilhado. Uma ferramenta de build automatizada verifica a entrada ou ramificação para garantir que não ocorram erros e que está pronta para entrar em produção. O principal benefício aqui é que os problemas geralmente são percebidos cedo antes que possam se transformar em problemas maiores.
Praticar CI significa integrar pequenos subconjuntos de alterações em um período mais curto, em vez de atualizações substanciais que levam mais tempo e com menos frequência. Automatizar fluxos de trabalho para testes, mesclagens e verificação de alterações em um repositório compartilhado significa que as equipes podem entregar código mais limpo com mais rapidez. Código mais limpo significa validação mais rápida, lançamentos de melhor qualidade e um pipeline de desenvolvimento mais eficiente que é mais fácil de escalar.
Como funciona a integração contínua?
A integração contínua é um processo simples e contínuo que começa na fase de desenvolvimento e termina no ambiente de teste. A integração contínua permite que todos os desenvolvedores trabalhem de forma colaborativa e acompanhem seu código. Cada desenvolvedor “commandará” seu código em pequenos incrementos para um repositório de código compartilhado, também conhecido como o repositório de linha principal. O repositório de código é mantido em um sistema Version Control como Unity VCS, Perforce ou Git. Cada compromisso feito com a ramificação principal do repositório (ou ramificações menores, se preferir) pode acionar um processo de compilação automatizado vinculado a um sistema de gerenciamento de compilação que leva o código e cria uma compilação. Assim que o código for mesclado no sistema de build, os desenvolvedores obterão acesso total às builds de código. A partir daqui, eles podem ver se o código foi compilado corretamente ou se há um erro que talvez precise corrigir. Os sistemas de compilação podem ser configurados para oferecer suporte a diversas estruturas de teste.
Assim que o código for aprovado e o ciclo de compilação for bem-sucedido, um ambiente de teste automatizado será acionado para validar a qualidade da compilação e do lançamento subsequente. Como o processo de teste e compilação é extremamente rápido, os resultados das commits de código podem ser rapidamente comunicados, permitindo que os desenvolvedores corrijam os erros restantes em um prazo oportuno. Todo esse processo garante que a base de código permaneça integrada e que todos possam continuar trabalhando de maneira eficiente.
Regras e princípios da CI
- Manter um repositório central de código
O armazenamento temporário de código de desenvolvedores diferentes em diversas equipes em repositórios separados ou sistemas separados deve ser mantido no mínimo.
- Commit/check em código para o repositório principal de linha com frequência
Quanto mais tempo o desenvolvedor manter o código sem criá-lo ou testá-lo, mais provável será que ele seja inconsistente com o armazenado no repositório central.
- Manter servidores de build e teste separados
As equipes devem manter máquinas dedicadas somente para fins de compilação. Isso acelera o processo de compilação e minimiza o impacto sobre os fluxos de trabalho de outros desenvolvedores.
- Builds e testes devem ser automatizados
Cada bloco de código comprometido com o repositório central de código-fonte deve ser desenvolvido e testado automaticamente com ferramentas de integração contínuas.
- Use ambientes de teste similares à produção
Os ambientes de teste devem simular o ambiente de produção final. Isso garante a utilidade do ambiente de teste e mantém as expectativas consistentes ao longo da implantação.
- As equipes de garantia de qualidade devem ter acesso às builds
Quando o QA tiver acesso às builds, qualquer falha em atender aos requisitos de produção poderá ser detectada com antecedência, reduzindo o risco de precisar refazer as builds de código posteriormente.
Entrega contínua x implantação contínua
Implantação contínua e distribuição contínua são práticas usadas para levar novos códigos para a produção da maneira mais rápida e eficiente possível. A entrega contínua segue a CI. Você pode pensar nisso como uma fase de checkpoint no pipeline de desenvolvimento antes que o produto final seja lançado aos clientes. Após a validação das alterações de código, elas são enviadas automaticamente ao repositório central.
A implantação contínua acompanha a CI no ciclo de vida de DevOps, mas os dois processos estão relacionados. A CI integra código à build com automação; o CD conclui esse processo. As automações de DevOps avaliam a qualidade das atualizações. Assim que não houver erros, eles são implantados automaticamente em produção.
O que é entrega contínua?
A entrega contínua se refere à criação, teste e entrega de alterações de código em software. Neste processo, o código passa por vários ambientes de teste, como testes automatizados de unidade, testes de integração e testes de sistema, antes de ser levado para a produção. A distribuição contínua acontece em ambientes de estágio de produção, onde as QAs revisam o código, corrigem bugs e executam testes automatizados para garantir que as builds sempre sejam implantaveis e prontas para lançamento.
Com entrega contínua, o objetivo é manter os conjuntos de alterações pequenos o suficiente para que nenhuma atualização da build principal comprometa o status “pronto para produção” do produto final. O produto final pode conter erros menores, mas nada substancial o suficiente para comprometer a experiência do usuário.
Praticar distribuição contínua significa que os desenvolvedores podem gastar menos tempo testando internamente, pois a prática garante que apenas código estável alcance a fase de entrega em primeiro lugar. Ele torna a detecção de bugs um processo mais simples, acelerando o tempo até a resolução.
O que é implantação contínua?
A implantação contínua visa implantar continuamente alterações de código na produção do repositório central assim que a build for estável. A equipe de operações implanta o código compilado e instala o software em diferentes ambientes (developer/test, estagiamento e produção). Cada alteração passa por um pipeline automatizado que leva uma versão funcional do aplicativo para a produção. A implantação pode ter diferentes formas. Um lançamento escuro é uma implantação oculta aos usuários, enquanto os comutadores de recurso ou comutadores podem ser usados para implantar subconjuntos específicos de um conjunto de alterações em um grupo de usuários para testes e feedback.
A implantação contínua traz diversos benefícios para desenvolvedores e clientes. Os desenvolvedores que usam soluções de implantação contínua não precisam mais se preocupar com a implantação de build manual e podem se concentrar em tarefas mais baseadas em habilidades. A automação reduz os laços de feedback, o que significa que os produtos podem ser atualizados mais rapidamente com base nas contribuições do cliente. Com implantação contínua, o código é executado e mantido em um ambiente simulado que garante a qualidade e permite o monitoramento em tempo real do produto. O principal objetivo da implantação contínua é lançar versões mais recentes do código de maneira consistente e implantar automaticamente essas alterações aos usuários finais.
Qual é a relação entre CI/CD e DevOps?
Todo desenvolvimento de software começa com pré-produção (a fase de planejamento), seguida de produção (codificação e criação de assets). DevOps é uma cultura e um processo destinados a tornar esses processos mais eficientes. CI/CD é uma fase dentro do ciclo de vida de DevOps que obriga a implementação de pequenas, mas estáveis, fluxos de atualizações de código ao longo do tempo para garantir melhorias contínuas e iterativas do produto final.
Lançamentos regulares e frequentes de software podem ser alcançados usando ferramentas e produtos específicos para habilitar a integração, entrega e implantação de alterações de código — isso é chamado de pipeline de CI/CD.
Um pipeline de CI/CD é um conjunto específico de fases vinculadas a ferramentas e automação que permitem que o ciclo de vida de DevOps aconteça. Embora a CI/CD seja uma parte integral da cultura DevOps, DevOps abrange muito mais em todo o ciclo de vida de desenvolvimento de software — desde colaboração até estrutura de equipe, observabilidade, Version Control e muito mais.
A implementação do DevOps varia muito de acordo com as organizações, mas, no seu núcleo, o DevOps não pode ser realizado sem CI/CD. Um pipeline de CI/CD está intrinsecamente ligado a uma cultura DevOps e seu processo de lançamentos pequenos e frequentes.
Benefícios da CI/CD
Iteração rápida
A adoção de práticas de CI/CD como parte do seu ciclo de vida de DevOps acelera o desenvolvimento ao automatizar o trabalho manual de validação e implantação de alterações na base de código.
- Código limpar
Verificar diversas alterações pequenas ao longo do dia reduz significativamente o risco de erros de quebra de build serem introduzidos em seu código-fonte.
- Correções de bugs mais rápidas
Mesclar conjuntos de alterações menores com mais frequência com CI/CD facilita a identificação de erros de código e a correção deles antes que se tornem um problema maior.
- Ciclos de feedback mais curtos
A CI/CD ajuda a encurtar os laços de feedback – um princípio central DevOps – porque mudanças menores e iterativas são mais fáceis de integrar, testar e implantar.
Melhor colaboração
CI/CD traz clareza ao trabalho ao definir processos e cronogramas para commits de código e lançamentos de build. Com metas mais claras, as equipes podem avançar com maior agilidade.
- Clientes mais felizes
Como as builds estão sempre prontas para lançamento com CI/CD, os clientes sofrem menos interrupções de serviço e seu feedback pode ser integrado muito mais rapidamente.
Agile é igual a CI/CD?
Um fluxo de trabalho ágil e CI/CD estão relacionados, mas eles não são os mesmos! Eles descrevem aspectos completamente diferentes do pipeline de desenvolvimento de software. Desenvolvimento ágil, refere-se ao processo ou às metodologias para gerenciar fluxos de trabalho, cadências de reuniões e organização da equipe no desenvolvimento de software. Uma metodologia ágil adota mudanças enquanto acelera a entrega, ouvindo e respondendo às necessidades do cliente e envolvendo-o em cada estágio do processo de desenvolvimento.
CI/CD depende da automação para eliminar os elementos humanos que criam gargalos na versão e melhoria do software. Em CI e CD, os testes são automatizados em todo o pipeline e são feitos com frequência para minimizar os custos e o tempo necessário para corrigir os defeitos.
Com que frequência você deve implantar para produção com implantação contínua?
Com CI/CD, os lançamentos sempre devem ser frequentes para evitar problemas futuros e garantir que seu software esteja sempre em um estado de lançamento — normalmente implementado várias vezes por dia. Um pressuposto comum com equipes de CI/CD deve ser implementar lançamentos "constantes", no entanto, isso nem sempre acontece. Seu ciclo de lançamento pode variar muito dependendo do seu produto, das builds e de outros fatores que talvez você queira considerar, como:
1. É uma correção crítica ou menor?
2. Você está rastreando contagens de regressão da build à build?
3. Há alguma equipe de QA integrada?
4. A base de código tem testes de unidade?
5. Há alguma duplicação de código?
Esses são apenas alguns exemplos de aspectos que devem ser considerados ao pensar em uma estratégia de lançamento e um pipeline, mas isso varia drasticamente de equipe para equipe. Produtos diferentes exigem abordagens diferentes.
A implantação contínua vale a pena?
Não há respostas suficientes para esta pergunta. Antes de investir na implantação contínua, uma empresa deve primeiro avaliar quais são os maiores riscos de seu produto e, depois, determinar as vantagens na forma como deseja implantar o software.
O sucesso de seu produto depende da capacidade de iterar rapidamente, receber feedback de seus clientes e continuar fazendo alterações. A implantação contínua será altamente impactante e lucrativa se você priorizar a redução dos ciclos de feedback e a criação de uma empresa altamente responsiva.
No entanto, se sua empresa não tiver muitos clientes, os benefícios da implementação de incrementos de implantação adicionarão menos valor e mais custos. O ambiente de teste escolhido para implantar depende das necessidades, do fluxo de trabalho e do orçamento de sua empresa.
A entrega contínua incentiva a configuração pois ela faz alterações contínuas no código original na configuração. Isso garante que a configuração seja acompanhada por erros de código que podem ocorrer ao longo do tempo.