O que é CI/CD? Pipelines e ferramentas de CI/CD explicados

Ao longo de uma geração, o CI/CD deixou de ser um tema de nicho e se tornou uma abordagem comum para o desenvolvimento e a entrega de software, hoje praticamente indispensável no setor. Embora muitas pessoas usem o termo com confiança, os significados exatos de CI e CD são frequentemente confundidos e mal interpretados.

CI/CD explicado

Quais são os principais componentes de um pipeline de CI/CD?

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

Integração contínua (CI) é geralmente entendida como uma prática de desenvolvimento que consiste em integrar regularmente o código em desenvolvimento em uma única branch. Essa branch costuma ser chamada de “trunk”. As equipes podem criar branches para situações específicas (por exemplo, para corrigir rapidamente um sistema em produção), mas esses casos são considerados exceções à regra.

Para gerenciar o trabalho em andamento, usam-se “feature flags” para garantir que o código não seja ativado até estar pronto. Essa abordagem de branch única contrasta com outras formas de desenvolvimento, como o GitFlow, que usa várias branches de longa duração para permitir diferentes frentes de desenvolvimento.

A importância da CI no framework de CI/CD

Com a CI, você evita o problema tradicional do “dia de merge”, quando diferentes frentes de desenvolvimento precisam ser conciliadas com cuidado. Essa conciliação pode ser complexa e sujeita a erros, além de reduzir a confiança na hora de lançar mudanças no código. A prática de CI também ajuda a promover outras boas práticas, como uma cadência regular de testes unitários ou de integração, caso você tenha um pipeline de CI automatizado. Do ponto de vista técnico, a CI exige que os desenvolvedores enviem com frequência seu trabalho em andamento para uma única branch (ou seja, sem criar branches para desenvolver funcionalidades). No uso cotidiano, porém, nem sempre isso é seguido.

O que é entrega contínua (CD)?

A integração contínua garante que as mudanças em desenvolvimento sejam integradas regularmente à linha principal do código. A entrega contínua empacota o código em uma unidade pronta para implantação, que pode ser implantada pelos próprios desenvolvedores (em um modelo DevOps puro) ou, se necessário, por uma equipe de operações separada. Muitas vezes, isso é confundido com a “implantação contínua”, que se refere ao processo de implantar mudanças automaticamente em produção. Na prática, porém, o segundo uso é mais comum do que a definição técnica.

O que é implantação contínua?

A implantação contínua permite que as organizações lancem aplicações automaticamente, sem intervenção manual. Nessa abordagem, as equipes de DevOps definem os critérios de lançamento com antecedência. Quando esses critérios são atendidos e validados, o código é enviado diretamente para produção. Assim, as organizações conseguem responder às mudanças com mais rapidez e entregar novas funcionalidades aos usuários em menos tempo.

É possível praticar integração contínua (CI) sem entrega contínua (CD) ou implantação contínua, mas a CD depende de uma CI já implementada. Seria quase impossível implantar em produção sob demanda sem os fundamentos de CI, como integrar o código em um repositório compartilhado, automatizar testes e builds e trabalhar em lotes pequenos e frequentes todos os dias.

O que é um pipeline de CI/CD?

A automação é ideal para práticas de CI e CD, pois elas exigem a repetição regular das mesmas ações. A automação dos processos de CI e CD costuma ser chamada de “pipeline”, uma analogia às linhas automatizadas de produção das fábricas. Como a automação é um princípio fundamental do DevOps (o “A” do modelo CALMS), os pipelines de CI/CD são considerados parte integrante das práticas de DevOps. Uma única equipe pode criar e manter o pipeline até a produção (um modelo DevOps mais puro), ou o pipeline de CI/CD pode entregar um conjunto estável e mais testado de artefatos de build a uma equipe de operações separada para implantação.

Benefícios da integração de CI/CD

Um pipeline de CI/CD também facilita a adoção de outras mudanças que podem aumentar a confiabilidade. Por exemplo, é relativamente simples inserir testes unitários ou de integração mais cedo no ciclo de build e implantação. Essa prática é chamada de “shift left” e pode reduzir significativamente os custos, pois os problemas são encontrados mais cedo no processo de entrega.

Da mesma forma, os pipelines favorecem um ambiente em que as mudanças podem ser lançadas “em pequenas doses e com frequência”, o que também reduz os riscos, já que cada mudança menor representa menos risco para o sistema como um todo. Em contrapartida, a abordagem mais tradicional de “big bang” agrupa várias mudanças em um único lançamento grande e esporádico.

Por fim, reduzir a intervenção manual também diminui os riscos, já que as máquinas são mais confiáveis do que as pessoas. É pouco provável que um pipeline automatizado execute o comando errado durante um build ou que alguém se esqueça de fazer um teste de QA como parte do ciclo de lançamento.

A popularidade recente do GitOps se baseia nesse código do pipeline e exige que ele seja representado integralmente no controle de versão. Além disso, o estado da implantação é gerenciado por agentes de controle automatizados, que garantem que ele corresponda ao código-fonte.

Pipelines de CI/CD e segurança

Quando se trata de gerenciar a segurança de software, a crescente popularidade dos pipelines de CI/CD trouxe novas oportunidades, mas também novas ameaças. Um dos benefícios é que os pipelines de CI/CD restringem o acesso irrestrito aos processos de build e implantação. Além disso, é mais fácil conceder a usuários (pessoas e serviços) acesso granular apenas aos recursos de que precisam, sem oferecer privilégios completos de administrador. Os pipelines também aumentam significativamente a auditabilidade do build e da entrega, pois é muito simples registrar, em cada etapa, qual ação foi realizada, qual foi o resultado e o que (ou quem) a iniciou.

Como mencionado, uma desvantagem do CI/CD é, naturalmente, o aumento das ameaças. Desde 2000, diversos fatores levaram à proliferação do código, das fontes e das plataformas de software. Com a aceleração do desenvolvimento e da implantação e o aumento da confiabilidade dos pipelines, o software está sendo implantado mais rápido do que nunca.

A expansão das bibliotecas de software de código aberto, das plataformas e das ferramentas também ampliou muito as opções disponíveis para os desenvolvedores. Por fim, a popularização dos contêineres como tecnologia flexível de empacotamento e implantação, somada à interoperabilidade entre componentes de software por meio de interfaces REST e gRPC, permite criar e implantar esses componentes em conjunto com mais facilidade e rapidez do que nunca.

A combinação desses fatores criou uma onda de novos softwares que os departamentos centralizados precisam tentar gerenciar. As equipes de segurança, operações e arquitetura tiveram de se adaptar a esse ambiente novo e em constante transformação.

Essa pressão deu origem ao DevSecOps, uma extensão do modelo DevOps de responsabilidade compartilhada pelo desenvolvimento, pela implantação e pela manutenção, que integra estreitamente as questões de segurança.

Play Video: CI/CD workflows

Ferramentas de pipeline de CI/CD

Os pipelines de CI/CD começaram como combinações de scripts simples de shell e derivados dos arquivos Make, como Ant e Maven. Com o tempo, aplicações mais completas para essa função se popularizaram. Algumas surgiram como aplicações simples do lado do servidor e depois se tornaram produtos comerciais de sucesso. Os maiores nomes desse segmento são Jenkins e TeamCity. Originalmente, essas ferramentas armazenavam a configuração do pipeline no servidor, de forma com estado, por meio da interface gráfica da aplicação. Mais recentemente, porém, tornou-se comum usar pipelines declarativos como código, carregados de repositórios remotos.

O Snyk pode ajudar você a evitar continuamente vulnerabilidades conhecidas nas dependências, por exemplo, com testes estáticos de segurança de aplicações. Você encontra integrações de segurança do Snyk com TeamCity, Jenkins e muitas outras ferramentas e sistemas de CI/CD. Confira aqui os exemplos de configuração de integração do Snyk no nosso repositório do GitHub.

Play Video: Why and when use Snyk in CI/CD?

Os principais serviços de controle de versão também aderiram a essa tendência. O GitLab foi pioneiro com sua oferta GitLab CI/CD, seguido pelo GitHub Actions. O Snyk oferece integração com o GitLab e o GitHub.

É claro que os principais provedores de nuvem também oferecem esses serviços. O Azure tem o produto Pipelines, e a AWS oferece o CodePipeline. Tanto os produtos Azure quanto os da AWS podem ser integrados ao Snyk.

CI/CD como novo padrão do setor

Desde que o termo CI foi cunhado, em 1991, o CI/CD deixou de ser uma prática relativamente restrita e se tornou o padrão do setor. Ao mesmo tempo, os efeitos combinados e que se reforçam mutuamente da expansão do código aberto, da conteinerização e das aplicações distribuídas provocaram uma explosão de artefatos de software, que abrangem uma variedade aparentemente infinita de ferramentas e tecnologias.

Isso, porém, criou um problema de segurança para quem gerencia pipelines de entrega de software e precisa manter sob controle todos esses novos vetores de ataque. A verificação manual, no entanto, não é sustentável, eficiente nem confiável. Saiba mais sobre os diferentes tipos de auditoria de segurança que você pode adicionar ao seu pipeline.

Reforce a segurança dos desenvolvedores durante todo o processo de desenvolvimento. Integre a automação do seu pipeline à análise de vulnerabilidades do Snyk. Confira todas as integrações do Snyk aqui.