A implantação contínua (CD) estende o processo de integração e entrega contínuas (CI/CD), implantando automaticamente cada alteração de código bem-sucedida na produção.
A implantação contínua leva a prática DevOps de automatizar as etapas de build, testes e implantação ao máximo. Quando uma alteração de código passa com sucesso por todas as etapas do pipeline, ela é automaticamente implantada na produção sem qualquer intervenção manual. A adoção da implantação contínua significa que você pode entregar novos recursos para seus usuários o mais rápido possível, sem comprometer a qualidade.
A implantação contínua é sustentada por um processo maduro e bem testado de integração contínua e and entrega contínua:
Depois de ter um processo de CI/CD robusto e confiável, você pode automatizar a etapa final e começar a implantar as alterações para os usuários automaticamente. Com a implantação contínua, o lançamento se torna um evento secundário que ocorre várias vezes ao dia.
Dito isso, a implantação contínua não deve ser considerada o objetivo final de todas as equipes de DevOps. Se você está criando aplicativos, APIs ou softwares instalados, seus usuários podem não querer receber atualizações várias vezes ao dia. A entrega contínua pode ser mais adequada nesse caso.
Mesmo que você não queira um pipeline de implantação completamente automatizado, talvez seja interessante selecionar algumas práticas e aplicá-las aos seus próprios processos de CI/CD. Vamos explorar exatamente no que consiste a implantação contínua e o que considerar antes de dar o salto em direção ao todo contínuo.
É fácil confundir as duas, mas a implantação contínua e a entrega contínua são partes distintas no lado CD do pipeline de CI/CD. Com a entrega contínua, o lançamento final para produção precisa ser acionado manualmente, enquanto que, com a implantação contínua, os lançamentos são automáticos, desde que todas as etapas anteriores tenham sido concluídas com sucesso.
Implantação contínua | Entrega contínua | |
---|---|---|
Modelo de lançamento | Acionada automaticamente sempre que uma alteração de código conclui com êxito cada estágio do pipeline. | Iniciada manualmente para alterações que concluíram com êxito cada estágio do pipeline. |
Frequência de lançamentos | Até várias vezes por hora (dependendo do tamanho da equipe e da velocidade do pipeline). | Normalmente, são semanais ou mensais, mas podem ser tão frequentes ou infrequentes quanto você desejar. |
Mais adequado para | Sites e aplicativos Web. | Aplicativos móveis, softwares de desktop e APIs. Também podem ser usados como um trampolim para a implantação contínua. |
Processo de teste | Deve ser totalmente automatizado e muito robusto. Gates de qualidade ajudam a dar aos desenvolvedores e às partes interessadas a confiança de que os testes identificarão todos os bugs. | Testes automatizados devem ser usados sempre que possível. Um processo de lançamento menos frequente retém capacidade para aceitação manual e testes exploratórios. |
Considerações adicionais | Implantações canário e builds azuis/verdes podem minimizar o impacto de quaisquer problemas lançados na produção. O monitoramento é essencial para identificar problemas na produção o mais cedo possível. | Embora os lançamentos sejam acionados manualmente, o processo em si deve ser automático. Opções para reverter ou implantar correções rapidamente ainda precisam ser consideradas. |
Saiba mais sobre as diferenças com nosso guia sobre Integração x entrega x implantação contínuas.
Se os seus processos de integração e implantação forem completamente manuais – com congelamentos de código, uma estratégia de teste prática e uma ansiedade de prender a respiração no dia do lançamento – implantações de hora em hora podem soar como uma fantasia distante.
No entanto, a realidade é que muitas organizações estão adotando essa abordagem mais regular. De grandes nomes como Netflix, Etsy e Amazon até empresas menores e menos conhecidas, muitas estão adotando um sistema de implantação contínua para tentar acompanhar o ritmo do mercado. Esse método permitiu que muitos criadores de software reduzissem o tempo de lançamento de semanas ou meses para horas.
Com a pressão cada vez maior para fornecer recursos e responder aos feedbacks rapidamente, a implantação contínua oferece uma estratégia para lançamentos regulares sem comprometer a qualidade.
Como extensão da integração e entrega contínuas, a implantação contínua depende de um processo de build, teste e implantação totalmente automatizado. Essa abordagem garante que a velocidade não prejudique a qualidade. No entanto, a implementação efetiva da implantação contínua precisa de mais do que apenas uma base sólida.
Antes de começar a lançar alterações sem qualquer envolvimento manual, você precisa de total confiança no seu processo de CI/CD. Em particular, você precisa garantir que suas builds automatizadas e testes automatizados estejam verificando seu código de maneira eficaz. É nessa etapa que os gates de qualidade do código podem ajudar.
Gates de qualidade especificam os critérios para que o código avance para a próxima etapa do seu pipeline. Para alguns estágios, você pode definir um limite simples, como exigir uma taxa de aprovação de 100% com 90% de cobertura de código para testes de unidade. Para outros testes automatizados, você pode permitir uma porcentagem de avisos, mas reprovar a etapa se algum erro for produzido. Às vezes, talvez você queira sinalizar erros ou avisos para análise manual antes de reprovar a etapa.
O uso de gates de qualidade automatizados nos principais estágios do pipeline oferece controle e visibilidade do processo e uma trilha de auditoria completa da devida diligência realizada em cada lançamento.
Ao planejar como implementar um sistema de implantação contínua, uma questão importante a ser considerada é como suas alterações serão lançadas. Colocar servidores offline em cada implantação resultará em interrupções frequentes nos serviços online e, portanto, geralmente é preferível uma estratégia de atualização contínua. Você também pode implementar uma extensão do seu processo de teste automatizado usando implantações canário (canary).
Uma implantação canário (canary deployment) limita a implantação do código atualizado a uma pequena porcentagem dos usuários, que se tornam testadores involuntários na produção. Ao monitorar o comportamento do usuário e as métricas de uso, você pode verificar se o novo lançamento não introduziu novas falhas antes de implementá-lo de maneira mais ampla.
Algumas empresas têm levado a automação mais longe com uma pontuação de confiança canário, que compara automaticamente uma série de métricas em relação a uma linha de referência. A implementação automatizada apenas continuará se a pontuação exceder o limiar especificado. Se a pontuação for baixa demais, a análise de métricas fornece um ponto de partida para uma investigação mais aprofundada sobre os possíveis problemas.
Um processo de implantação de build azul/verde é uma técnica comum para organizações que implementam um sistema de implantação contínua. Implantações azuis/verdes facilitam a reversão de um lançamento em caso de problema, mantendo o código antigo online até que você tenha certeza de que as alterações funcionarão conforme o esperado. Se necessário, você pode seguir uma implantação canário inicial com um lançamento azul/verde.
Esteja você executando uma implantação azul/verde ou implementando substituições diretas, monitorar a integridade do sistema de produção é essencial se você quiser responder rapidamente a bugs que passaram pelo processo de testes automatizados.
Comece identificando as principais métricas que indicam a integridade do seu sistema. Elas podem incluir métricas de integridade do sistema, como espaço em disco e uso da CPU, bem como métricas de uso, como o número de solicitações ou transações. Comparar essas métricas com uma linha de base saudável pode fornecer um sinal de alerta precoce se as coisas não estiverem se comportando como deveriam. Em seguida, você pode decidir se deseja reverter a alteração ou colocar uma correção no pipeline.
Antes de entrar na onda da implantação contínua, reserve um momento para considerar algumas das coisas que você precisará fazer para garantir que a adoção da CD tenha sucesso.
O ciclo de vida de desenvolvimento de software envolve bem mais que apenas alterações de código. As equipes de pesquisa de usuário, marketing de produto, design de interação, documentação, comercial, jurídica e de suporte têm todas um papel a cumprir.
Se você não estabeleceu as bases com as partes interessadas e não se envolveu com elas para entender o que elas precisam do processo de lançamento, mudar para lançamentos automatizados pode fazer com que sintam que o desenvolvimento está fora de controle. Isso pode levar as partes interessadas a exigir pontos de verificação manuais e estágios de revisão, retardando o processo e prejudicando os benefícios da CI/CD. Na pior das hipóteses, todo o sistema de implantação contínua pode ser rejeitado como um experimento fracassado.
Criar uma cultura de colaboração é essencial para que a implantação contínua funcione bem. Envolver outras equipes por todo o processo de desenvolvimento para que suas opiniões - quanto a design, questões de segurança, terminologia ou conformidade - possam ser incorporadas desde o início é um exemplo de como ciclos curtos de feedback podem tornar o ciclo de vida de desenvolvimento de software mais eficiente.
Tão importante quanto estimular o compartilhamento de opiniões é fornecer visibilidade sobre o que está sendo lançado e quando. Mantenha as partes interessadas informadas automaticamente com a ajuda de um servidor de CI. Dependendo da sua escolha de ferramenta de implantação de build contínua, você poderá disseminar informações por meio de dashboards e notificações.
Às vezes, a visibilidade do que está sendo feito, por si só, não é suficiente. Quando você está trabalhando num recurso maior ou precisa controlar a programação de um lançamento, simplesmente implantar cada commit e colocar o serviço no ar depois de passar em todos os testes não é o ideal.
Sinalizadores de recursos são uma opção para controlar a visibilidade do código em produção. A vantagem é que o código está ativo, então você pode monitorar seu software em busca de falhas inesperadas.
Outra abordagem é usar um branch dedicado e um pipeline separado que não envia automaticamente para produção, combinando assim a entrega contínua e a implantação contínua para atender às suas necessidades.
Quando bem feita, a implantação contínua pode ajudar as equipes a fornecer alterações aos usuários com mais frequência, minimizando os bugs. A chave para isso é seguir as práticas recomendadas, incluindo o uso de métricas para otimizar seu pipeline e monitorar seu ambiente de produção para detectar qualquer sinal de problema. Também é importante reconhecer a mudança cultural envolvida e fazer com que toda a equipe participe do processo de CI/CD.
Você pode saber mais sobre como otimizar seu processo de CI/CD e obter melhores resultados com nosso guia de práticas recomendadas de implantação contínua.
O TeamCity facilita o processo de configuração da implantação contínua, com opções de acionamento e executores de build de implantação altamente configuráveis. As configurações de build de implementação dedicadas significam que você pode restringir as permissões de implementação na produção, enquanto os acionadores de build flexíveis permitem definir condições de lançamento. Use o suporte integrado do TeamCity para repositórios de pacotes e registros de containers a fim de gerenciar seus artefatos de build como parte do seu processo de implantação contínua.
Mantenha as partes interessadas informadas sobre o progresso, dando-lhes acesso aos dashboards intuitivos e baseados na Web do TeamCity. O poderoso controle de acesso baseado em funções garante a segurança do caminho para a produção, enquanto as trilhas de auditoria integradas fornecem um registro abrangente de todas as atividades nos seus pipelines.
A integração contínua, ou CI em inglês, é a prática de fazer com que todos que estão trabalhando no mesmo projeto façam merge das suas alterações à base de código num repositório central com regularidade.
Integração, entrega e implantação contínuas são práticas de DevOps. Saiba mais sobre elas.
Saiba como conseguimos lidar com o gargalo da fila de compilação para a instalação do TeamCity que compila todos os projetos da JetBrains.