Os fundamentos da implantação contínua no DevOps

Quando se trata de desenvolvimento de software, as empresas de hoje costumam enfrentar dois grandes desafios: enviar software com rapidez e inovar em grande escala. O DevOps ajuda a resolver esses problemas aplicando automação em todo o ciclo de vida de desenvolvimento de software (SDLC) para facilitar a entrega rápida de softwares mais confiáveis e seguros.

A implantação contínua, ou CD, é um dos exemplos mais avançados de automação em uma prática de DevOps. Ela requer uma combinação de testes rigorosos, colaboração sólida entre equipes, ferramentas avançadas e processos de fluxo de trabalho em todo o processo de design e desenvolvimento de aplicações.

Quando implementada com êxito, a CD funciona. Descobriu-se que as organizações de DevOps que adotam a CD enviam código com mais rapidez e superam outras empresas em 4 a 5 vezes.

Neste guia, exploraremos:

Os benefícios da CD
O processo da CD
A diferença entre a entrega contínua e a CD
A explicação dos pipelines de implantação contínua
Um modelo de pipeline de implantação contínua
Como fazer a CD funcionar na organização

Os benefícios da CD

Quando implementada com êxito, a CD torna mais fácil para as empresas responder rapidamente às demandas dos clientes e enviar atualizações de software de forma ágil, muitas vezes em minutos após mudanças de código no commit.

Ainda assim, implementar a CD pode ser uma mudança radical em relação ao gasto de dias, ou mesmo semanas, preparando-se para o lançamento de software. Porém, as empresas que investem em tempo, recursos e ferramentas veem vantagens concretas.

Alguns benefícios comuns incluem:

Ciclos de implantação totalmente automatizados. Isso permite que as organizações passem mais tempo criando softwares em vez de pausar o trabalho de desenvolvimento em preparação para o “dia do lançamento”.
Implantações incrementais mais regulares. Isso leva a um trabalho de desenvolvimento de produtos mais rápido e ajuda a facilitar um modelo de melhoria contínua.
Ciclos de feedback rápidos sobre novos recursos. As organizações podem obter feedbacks rapidamente em tempo real sobre novos recursos, atualizações e alterações de código.

O que é o processo de CD?

Dica profissional: este guia pressupõe que você conheça a integração contínua e o conceito de pipelines automatizados. Se tiver dúvidas sobre essas práticas de DevOps, leia nosso guia.

O DevOps busca aumentar a velocidade da inovação e da entrega de valor aplicando automação a todas as fases do SDLC. Com essa visão, a CD é o objetivo primordial do DevOps: um SDLC totalmente automatizado que efetua push de todas as alterações de código para a produção se forem aprovadas em um conjunto predefinido de testes.

De certa forma, criar um pipeline automatizado é uma das partes mais fáceis da adoção de um modelo de CD. Contudo, pouquíssimas organizações iniciam a jornada de DevOps criando uma prática de implantação contínua devido à mudança cultural que isso significa e à maturidade do pacote de teste exigida.

A disponibilidade de integrações prontas para uso com nossas ferramentas existentes é uma parte importante do apelo do GitHub. O GitHub ajuda mesmo a dar vida ao DevOps.

Danilo Suntal, Líder ágil e DevOps, P&G

Diante disso, é melhor compreender o processo e a jornada necessários para alcançar uma prática de implantação contínua totalmente funcional.

O gráfico abaixo mostra um mapa de jornada de alto nível sobre como as organizações normalmente começam a pensar em automatizar o SDLC.

Para começar, as organizações precisam criar uma prática de integração contínua (CI). Os elementos fundamentais de uma prática sólida de CI (commits regulares de código, uma estratégia de teste, ferramentas de controle de versão e uma plataforma de CI) preparam o terreno para que as organizações comecem a desenvolver uma prática de implantação contínua.

Saiba como começar a criar uma prática de CI na sua organização >

Na sua forma mais básica, a CD reúne compilações, testes e implantações automatizados em um único fluxo de trabalho da versão. O objetivo é automatizar a implantação de compilações de software na produção. Cada empresa precisa identificar a combinação certa de testes unitários, funcionais e de estresse que compõem o pacote de teste. Também é fundamental espelhar as pressões do ambiente de produção em um ambiente pré-produção para preparar e testar com eficácia compilações e a versão Release Candidate.

Acertar em tudo isso leva a uma recompensa significativa: versões mais rápidas e estáveis. O processo também posiciona as organizações para obter implantação contínua com um pipeline de CI/CD totalmente automatizado.

Idealmente, uma prática de DevOps torna-se tão aperfeiçoada no regime de teste, nos acionadores de automação, na composição de fluxo de trabalho e nas plataformas de CI/CD que leva à implantação contínua de maneira espontânea. Na verdade, a necessidade de intervenção humana para orquestrar um lançamento de software se dissipa com o tempo.

Na prática, porém, obter um modelo de CD durável e escalável exige investimentos significativos em recursos e ferramentas de engenharia. Além disso, embora as plataformas de CI/CD e as ferramentas associadas contribuam muito para estabelecer uma prática de implantação contínua, é fundamental uma mudança cultural que enfatize a colaboração entre as equipes e os commits regulares de código.

Qual é a diferença entre entrega contínua e CD?

A entrega contínua e a implantação contínua são duas práticas de automação de DevOps que costumam ser confundidas uma com a outra. O fato de ambas serem frequentemente abreviadas como CD e lidarem com responsabilidades semelhantes contribui para a confusão.

Porém, enquanto a CD automatiza todo o processo de lançamento, a entrega contínua automatiza tudo, até a implantação ou lançamento em si. Nesse momento, a intervenção humana é necessária para preparar a implantação.

Simplificando, a entrega vem antes da implantação.

Uma maneira útil de pensar sobre a diferença entre a entrega contínua e a CD é o que cada uma faz. Em uma prática de entrega contínua, o software é criado de forma que possa ser lançado manualmente a qualquer momento. A automação é usada para garantir que as alterações no código sejam revisadas, mescladas, testadas e empacotadas, depois sejam movidas para um ambiente de produção para que o software esteja pronto para ser enviado aos clientes.

Por outro lado, a CD automatiza todo o processo, incluindo o lançamento do próprio software. Se o merge for feito com êxito nas alterações do código e elas forem aprovadas em todos os testes automatizados predefinidos, serão imediatamente enviadas aos clientes.

Em muitos aspectos, a CD é uma evolução natural da entrega contínua. Se um pipeline de entrega contínua for configurado corretamente e projetado para testar todos os elementos de uma compilação de software antes do lançamento, a necessidade de alguém lançá-lo manualmente para os clientes diminui com o tempo.

Explicação dos pipelines de implantação contínua

Um pipeline de implantação contínua é um fluxo de trabalho automatizado que reúne compilações, testes e implantações para efetuar push de alterações de código para a produção. Cada etapa do fluxo de trabalho produz uma saída que fornece uma entrada para a próxima etapa. Monitoramento e testes automatizados ocorrem em um pipeline de implantação contínua para detectar possíveis erros, problemas funcionais e bugs. Isso fornece alertas em tempo real e evita que possíveis problemas cheguem ao branch main do software ou à produção.

O resultado final? As equipes de engenharia podem efetuar push de alterações de código para o branch main e rapidamente vê-lo sendo usado na produção, geralmente em minutos. Essa abordagem no desenvolvimento de software ressalta o objetivo principal do DevOps: entrega contínua de valor aos usuários finais. É também a razão central de muitas das aplicações e serviços baseados na Web que usamos regularmente receberem novos recursos e alterações no sistema.

Vamos explorar como é um pipeline de implantação contínua na prática.

Um modelo de pipeline de implantação contínua

Primeiro, uma observação: não existe um “modelo” único de CD. Cada organização cria um pipeline de implantação contínua exclusivo para as próprias necessidades, práticas de desenvolvimento de software e demandas dos clientes.

Apesar disso, existem quatro fases comumente aceitas em qualquer pipeline de implantação contínua que toda organização deve incluir nos planos de engenharia. Elas incluem:

Verificação

A implantação contínua baseia-se na integração contínua: é nessa fase que a CI para e a CD começa. Depois que são feitos o commit e a integração de um novo trecho de código na base de código, isso aciona o processo de verificação automatizado que executa uma série de testes na compilação de uma versão Release Candidate. Isso pode incluir testes funcionais, de integração, de segurança e do nível de produção para garantir que uma versão Release Candidate funcione após a implantação.

Práticas comuns de verificação

Testes automatizados: Uma série de testes predefinidos que vão desde testes funcionais até testes de integração e aceitação.
Testes de requisitos não funcionais: Os testes de segurança e desempenho, entre outras coisas exigidas pelas necessidades de uma organização, costumam ser executados antes da implantação.

Implantação

Depois que o código é verificado por meio de testes, o processo de implantação automatizado se inicia. Implementações mais avançadas normalmente criam fluxos de trabalho de automação que movem o código para a implantação imediatamente após fazerem commit dele (claro, pressupondo que o código seja aprovado em todos os testes predefinidos na fase de CI).

Práticas comuns de implantação

Implantações automatizadas: Automatização de implantações de código depois que uma compilação é aprovada também em testes predefinidos.
Controle de versão: rastreia o histórico de alterações à medida que pessoas e equipes colaboram em projetos de software.
Implantações azul-verde: Permite uma implantação em que o sistema move gradualmente o tráfego de usuários de uma versão antiga de uma aplicação para uma nova.
Testes de produção: Testes automatizados de qualidade e funcionais são aplicados a uma compilação após a implantação para garantir a estabilidade da produção.
Dark launch: Liberar alterações de código para um pequeno grupo de usuários para ver o uso em tempo real e as demandas do sistema antes de orquestrar um lançamento em grande escala.

Monitoramento

O monitoramento contínuo é um elemento crítico no qual as organizações precisam investir para apoiar a CD. O monitoramento deve ocorrer em todo o SDLC. Contudo, é fundamental ter a capacidade de ver o que está ou não funcionando e receber alertas em tempo real antes, durante e depois das implantações. Ferramentas que ajudam as equipes a visualizar métricas de desempenho e mostrar as sobrecargas do sistema são um investimento útil.

Práticas comuns de monitoramento

Monitoramento de aplicações: Monitore a integridade da aplicação com as principais áreas de foco, incluindo tempo de atividade, respostas de API e estabilidade de front-end e back-end.
Monitoramento de infraestrutura: Monitore as demandas do sistema em tempo real e como a infraestrutura principal dá suporte a elas.
Monitoramento do comportamento do usuário: Rastreie o comportamento do usuário em uma aplicação para acompanhar possíveis erros do sistema no nível de produção ou elementos que atrapalhem a experiência do usuário. Esse monitoramento também pode ser usado para informar o desenvolvimento futuro de aplicações.
Monitoramento de segurança: Rastreamento de atividades de agentes maliciosos, bem como quaisquer vulnerabilidades de segurança que apareçam no código em produção.

Resposta

Seja para resolver um erro de sistema no nível de produção, seja para identificar um incidente de segurança ou um possível novo recurso para desenvolvimento, ser capaz de responder a eventos é um elemento crítico de um pipeline de implantação contínua. Um benefício da CD é o código ser imediatamente lançado para a produção. Isso também significa que as organizações precisam estar preparadas para responder e resolver quaisquer problemas que surjam após a implantação. As métricas comuns usadas para avaliar os tempos de resposta incluem o MTTR (tempo médio de resolução), que as organizações acompanham para avaliar a melhoria ao longo do tempo.

Práticas comuns de resposta

Reversões de implantação: Reverta uma aplicação para uma compilação anterior a fim de resolver quaisquer problemas que apareçam em uma nova versão.
Verificações de infraestrutura: Implementar controles para impedir que qualquer configuração no nível de produção ou alterações no ambiente ocorram após uma implantação.
Logs de atividades: Mantenha logs de atividades quem ajudam a recriar comportamentos do usuário e execuções de processos para ajudar as equipes a isolar possíveis problemas.

Fases e ambientes de CD

Para criar um pipeline de CI/CD escalável, a maioria das organizações investe recursos no desenvolvimento de um servidor de compilação para que a CI compile e teste códigos com mais facilidade. Isso costuma ser combinado com ambientes de pré-produção e produção de CD.

O objetivo dos ambientes de pré-produção e produção é facilitar o teste e a implantação de versões Release Candidate por meio de um fluxo de trabalho automatizado. À medida que as versões chegam aos ambientes pré-produção, diferentes testes automatizados são aplicados à base de código para identificar quaisquer problemas ou motivos para pausar uma implantação.

Normalmente, esse processo acontece em quatro etapas:

É feito o commit das alterações de código em um repositório compartilhado. Isso aciona uma compilação automatizada em um servidor de CI em que as dependências são solucionadas, os testes unitários são aplicados e o código é empacotado e compilado.
Uma versão é implantada em um ambiente pré-produção. Se o código for aprovado em todos os testes no servidor de CI, ele acionará um fluxo de trabalho automatizado que envia uma versão Release Candidate a um servidor de CD.
Mais testes automatizados são realizados. Com a versão em um ambiente pré-produção, são realizados testes adicionais que incluem testes funcionais, testes de segurança, testes de desempenho e outros antes que uma implantação seja lançada para produção.
Uma atualização de software é lançada para os usuários. Depois que uma versão Release Candidate é aprovada em todos os testes automatizados nos ambientes de teste e desenvolvimento, ela é lançada para os usuários finais.

Os melhores ambientes de CD combinam testes rigorosos com alertas e monitoramento contínuo para ajudar as equipes a resolver quaisquer problemas rapidamente. Embora cada ambiente de CD e regime de teste sejam exclusivos da organização que os desenvolve, todos estão unidos por um objetivo simples: entrega contínua e rápida de valor aos usuários finais.

Como fazer a CD funcionar na organização

Como um dos exemplos mais avançados de automação em DevOps, a CD requer tempo, recursos de engenharia e ferramentas para ser adotada com êxito. Também requer uma forte cultura de DevOps que enfatize a colaboração sólida em todas as fases do SDLC.

No GitHub, sabemos que não existe um modelo único de CD. Toda organização precisa criar uma prática que atenda às próprias necessidades e prioridades de negócios. Mesmo assim, vemos práticas recomendadas comuns entre todas as organizações de elite do DevOps que adotam a CD com êxito. Elas incluem:

Foco na integração contínua em primeiro lugar. Uma atividade sólida de CI é fundamental para criar um pipeline e uma prática de implantação contínua bem-sucedidos. Isso inclui adotar uma cultura de CI em que cada desenvolvedor faça mudanças de código no commit várias vezes ao dia. Também envolve expandir uma forte estratégia de testes automatizados que garanta que todos os commits de código sejam avaliados antes de chegarem à produção. O foco das organizações deve ser automatizar o máximo possível do SDLC e manter o branch main do código verde ou livre de quaisquer problemas em potencial. No GitHub, por exemplo, investimos no desenvolvimento dos nossos próprios recursos de CI/CD com o GitHub Actions para termos uma experiência gerenciada rica ou auto-hospedada para as organizações.
Desenvolvimento de uma forte estratégia de teste. Uma prática de implantação contínua significa lançar mudanças de código à medida que são feitas, e quaisquer problemas que não sejam detectados por um teste entram na produção. Isso torna fundamental desenvolver uma forte estratégia de testes automatizados que cubra uma grande parte da sua base de código. A maioria das organizações pretende ter pelo menos 75% de cobertura do teste.

Você também vai querer dedicar um tempo para garantir que os testes, sejam eles unitários, funcionais, de desempenho, de aplicações ou de segurança, sejam eficazes. Uma coisa é a cobertura do teste ser grande. Outra coisa é ter bons testes que fortaleçam sua base de código e garantam que você tenha confiança no código em produção.
Investimento em uma prática de monitoramento contínuo. Um pacote de teste sólido e uma boa cobertura do teste são essenciais em uma prática de implantação contínua. Porém, sem monitoramento em tempo real nos ambientes de teste e produção, você corre o risco de errar. Uma mudança de código ou um novo recurso pode introduzir problemas não intencionais revelados nos testes antes de uma implantação. Mesmo que os testes mostrem que sua base de código é estável, podem surgir problemas de infraestrutura na produção quando a atividade do usuário introduz variáveis inesperadas.

Por isso é fundamental investir em ferramentas de monitoramento contínuo para rastrear demandas em tempo real, desempenho do sistema e comportamentos das aplicações. As melhores ferramentas ajudam a monitorar o desempenho de aplicações e sistemas, bem como problemas de segurança e quaisquer irregularidades nos sistemas. Elas também fornecem alertas em tempo real e logs de atividades para que suas equipes de engenharia possam trabalhar em possíveis soluções.
Desenvolvimento de testes e códigos ao mesmo tempo. Com cada alteração de código passando para produção, uma prática de implantação contínua significa ter menos tempo para escrever novos testes para verificá-los. Isso é diferente de outras metodologias de desenvolvimento, que costumam deixar mais tempo para as equipes de controle de qualidade trabalharem depois que os desenvolvedores escrevem um novo código e introduzem novos recursos. Uma boa prática para solucionar isso é desenvolver testes à medida que desenvolve um código. É ainda melhor se puder começar a pensar na sua estratégia de teste enquanto suas equipes de produto planejam novos recursos.

Incluir requisitos de teste na fase de planejamento e desenvolvimento é uma prática recomendada com a CD. Isso também traz benefícios de longo prazo à medida que você aumenta a cobertura do teste paralelamente ao trabalho de desenvolvimento de produtos.
Shift left e ênfase na segurança em todo o SDLC. A segurança é um componente essencial do software atualmente, e isso é especialmente verdadeiro para organizações que adotam uma prática de implantação contínua, em que cada commit de código aprovado em todos os testes entra imediatamente em produção. O DevSecOps é uma evolução, ou progressão natural, do DevOps e busca incorporar segurança em todas as partes do SDLC. Isso significa incluir a segurança no SDLC o mais cedo possível (ou fazer shift left) para garantir que as organizações priorizem o desenvolvimento de testes, procurem possíveis vulnerabilidades e fortaleçam os sistemas o máximo possível.

É fundamental ter uma combinação de ferramentas, como o GitHub Advanced Security, e práticas culturais que incentivam todos a abordar o desenvolvimento com uma mentalidade de segurança. Outras ferramentas, como IDEs em nuvem (ambientes de desenvolvimento integrados), também podem ser úteis para garantir que seus ambientes de desenvolvimento sejam seguros.

Crie sua prática de DevOps no GitHub

O GitHub é uma plataforma integrada que leva as empresas da ideia ao planejamento, à compilação e à produção, combinando uma experiência de desenvolvedor focada com uma infraestrutura poderosa e totalmente gerenciada de desenvolvimento, automação e teste.

Compare os Planos de Preços >

Compare as Soluções de DevOps >

Nossa filosofia é criar automação e um excelente DevOps para a empresa que você edificará amanhã.

Todd O'Connor, engenheiro sênior de SCM da Adobe

Passe do planejamento para a criação	Aumente a velocidade dos desenvolvedores
Crie planos de roadmap junto à sua base de código e atribua tarefas aos membros da equipe rapidamente com quadros e tabelas de projeto poderosos que se integram totalmente ao seu projeto. Saiba mais sobre o GitHub Issues >	Reduza o tempo de commit. Elimine o gerenciamento do ambiente e a alternância de contexto para seus desenvolvedores. Simplifique a aquisição e a manutenção de TI com um espaço seguro e gerenciado na nuvem. Explore o Codespaces >

Automatize tudo	Proteja seu código enquanto o escreve
----------	----------
Automatize todos os seus fluxos de trabalho de desenvolvimento de software com o GitHub Actions. Escale de maneira confiável e segura com uma poderosa infraestrutura de desenvolvimento, teste e automação, totalmente gerenciada pelo GitHub. Saiba mais sobre o GitHub Actions >	Proteja seu código, dependências, tokens e dados confidenciais durante todo o ciclo de vida de desenvolvimento de software e resolva vulnerabilidades automaticamente. Veja como ajudamos você a manter a segurança >