Pipeline de DevOps

1. Integração contínua/entrega ou implementação contínua (CI/CD)

A integração contínua é a prática de fazer commits frequentes em um repositório de código-fonte comum. Ela integra as alterações de código com continuidade na base de código existente para que os conflitos entre as diferentes alterações de código do desenvolvedor sejam identificados com rapidez e relativamente fáceis de corrigir. Essa prática é de grande importância para aumentar a eficiência da implementação.

Acreditamos que o desenvolvimento baseado em troncos é um requisito para a integração contínua. Se você não fizer commits frequentes em uma ramificação comum de um repositório de código-fonte compartilhado, não será integração contínua. Se os processos de compilação e teste forem automatizados, mas os desenvolvedores estiverem trabalhando em ramificações de recursos isoladas e de longa duração, que raramente são integradas a uma ramificação compartilhada, você também não estará fazendo implementação contínua.

A entrega contínua garante que a ramificação “principal” ou “tronco” do código-fonte de um aplicativo esteja sempre pronta para o lançamento. Em outras palavras, se a gerência chegasse à sua mesa às 16h30 de uma sexta-feira e dissesse: “Precisamos da versão mais recente lançada agora mesmo", essa versão poderia ser implementada com o toque de um botão, sem medo de falhas”.

Isso significa ter um ambiente de pré-produção o mais parecido possível com o ambiente de produção e garantir que os testes automatizados sejam executados, de modo que todas as variáveis que possam causar falhas sejam identificadas antes que o código seja mesclado na ramificação principal ou de tronco.

A implementação contínua envolve um nível de testes e operações contínuos tão robusto que novas versões do software são validadas e implementadas em um ambiente de produção sem exigir nenhuma intervenção humana.

Isso é raro e, na maioria dos casos, desnecessário. Em geral, apenas empresas unicórnio, que têm centenas ou milhares de desenvolvedores e muitos lançamentos todos os dias, exigem, ou até mesmo querem ter, esse nível de automação.

Para simplificar a diferença entre entrega e implementação contínuas, pense na entrega como o funcionário da FedEx entregando uma caixa para você e na implementação como o processo de abrir essa caixa e usar o que está dentro dela. Caso seja necessária uma alteração no produto entre o momento em que você recebe a caixa e o momento em que você a abre, o fabricante vai ter problemas!

2. Feedback contínuo

O maior problema do antigo método de desenvolvimento de software em cascata – e, como consequência, o motivo para as metodologias ágeis terem sido criadas – era a falta de feedback em tempo hábil. Quando os novos recursos levavam meses ou anos para ir da ideia à implementação, era quase certo que o resultado final seria algo diferente do que aquilo que o cliente esperava ou queria. Os processos ágeis tiveram sucesso ao garantir que os desenvolvedores recebessem feedback mais rápido dos stakeholders. Hoje, com o DevOps, os desenvolvedores recebem feedback contínuo não só dos stakeholders, mas de testes sistemáticos e monitoramento do código no pipeline.

O teste contínuo é um componente fundamental de todo pipeline de DevOps e um dos principais facilitadores do feedback contínuo. Em um processo de DevOps, as mudanças passam continuamente do desenvolvimento para o teste e a implementação, o que gera não só a lançamentos mais rápidos, mas um produto de maior qualidade. Isso significa ter testes automatizados em todo o pipeline, inclusive testes de unidade executados em cada alteração do build, testes de sanidade, testes funcionais e testes de ponta a ponta.

O monitoramento contínuo é outro componente importante do feedback contínuo. Uma abordagem de DevOps envolve o uso de monitoramento contínuo nos ambientes de staging, testes e até desenvolvimento. Às vezes pode ser útil monitorar ambientes de pré-produção em busca de comportamentos anômalos, mas, em geral, essa é uma abordagem usada para avaliar com continuidade a integridade e o desempenho dos aplicativos em produção.

Existem várias ferramentas e serviços para garantir essa funcionalidade, e elas podem envolver qualquer coisa, desde o monitoramento da infraestrutura local ou na nuvem, como recursos de servidor, rede etc., até o desempenho do aplicativo ou das interfaces de API.

3. Operações contínuas

O termo operações contínuas é relativamente novo e menos comum, e as definições variam. Uma forma de interpretá-lo é como o “tempo de operação contínuo”. Por exemplo, o caso de uma estratégia de implementação azul/verde em que você tem dois ambientes de produção separados, um “azul” (acessível publicamente) e outro “verde” (não acessível publicamente). Nessa situação, um novo código seria implementado no ambiente verde e, quando houvesse a confirmação do status de funcional, um switch seria invertido (em geral em um balanceador de carga) e o tráfego mudaria do sistema “azul” para o “verde”. O resultado é a ausência de tempo de inatividade para os usuários finais.

Outra forma de pensar em operações contínuas é como um alerta contínuo. Essa é a noção de que a equipe de engenharia está de plantão e é notificada quando ocorrem anomalias de desempenho no aplicativo ou na infraestrutura. Na maioria dos casos, o alerta contínuo vem acompanhado do monitoramento contínuo.