Fundamentos sobre a pipeline de entrega contínua
Saiba como builds, testes e implementações automatizados são encadeados em um fluxo de trabalho de lançamento.
Juni Mukherjee
Representante do desenvolvedor
O que é um pipeline de entrega contínua?
Um pipeline de entrega contínua é uma série de processos automatizados para entrega de novo software. É uma implementação do paradigma contínuo, em que builds, testes e implementações automatizadas são orquestrados como um único fluxo de trabalho de lançamento. Em resumo, o pipeline de CD é o conjunto de etapas pelo qual as mudanças de código vão passar para chegar até a produção.
O pipeline de CD entrega de modo automatizado, de acordo com as necessidades comerciais, produtos de qualidade com frequência e previsibilidade, desde o teste até o staging e a produção.
Para começar, a gente precisa concentrar nos três conceitos: qualidade, frequência e previsibilidade.
A gente enfatiza a qualidade para destacar que não se abre mão dela em prol de velocidade. As empresas não querem que a gente crie o pipeline que possa enviar algum código defeituoso para produção em alta velocidade. A gente vai passar pelos princípios de "Mudança para a esquerda" e "DevSecOps" e discutir como a gente pode mover qualidade e segurança para o início do processo no SDLC (abreviação de ciclo de vida do desenvolvimento de software, em inglês). Isso vai acabar com qualquer preocupação relativa aos pipelines de entrega contínua oferecerem algum risco aos negócios.
A frequência indica que os pipelines são executados a qualquer momento para lançar funções, já que são programados para que sejam acionados com commits na base de código. Assim que o MVP (produto mínimo viável) do pipeline estiver desenvolvido, ele pode executar quantas vezes for necessário com custo de manutenção periódica. Essa abordagem automatizada tem escalabilidade sem sobrecarregar a equipe. Também permite que as equipes façam pequenas melhorias incrementais aos produtos sem o medo de grandes catástrofes na produção.
Ver solução
Crie e opere softwares com o Open DevOps
Material relacionado
O que é o pipeline de DevOps?
Por mais que pareça clichê, a noção de “errar é humano” ainda é verdadeira. As equipes se preparam para problemas durante os lançamentos manuais, pois esses processos são delicados. Previsibilidade significa que os lançamentos são de natureza determinística quando feitos por meio de pipelines de entrega contínua. Como os pipelines são infraestruturas programáveis, as equipes podem sempre esperar o comportamento pretendido. Acidentes podem acontecer, é claro, já que nenhum software é livre de bugs. No entanto, os pipelines apresentam superioridade exponencial em comparação com os processos de lançamento manual propensos a erros, já que, ao contrário dos seres humanos, os pipelines não cometem erros sob a pressão de prazos agressivos.
Pipelines têm portas de software que promovem ou rejeitam automaticamente a aprovação de artefatos com controle de versão. Se o protocolo de versão não for cumprido, as portas do software permanecerão fechadas, e o pipeline será anulado. São gerados alertas e enviadas notificações a uma lista de distribuição incluindo membros da equipe que potencialmente poderiam ter rompido o pipeline.
E é assim que um pipeline de CD funciona: um commit, ou um pequeno lote incremental de commits, chega à produção sempre que o pipeline é executado com sucesso. Por fim, as equipes enviam funções e, então, produtos de maneira segura e auditável.
Fases em um pipeline de entrega contínua
A arquitetura do produto que flui pelo pipeline é um fator essencial que determina a anatomia do pipeline de entrega contínua. Uma arquitetura de produto altamente acoplada gera um padrão de pipeline gráfico complicado em que vários pipelines ficam emaranhados antes de acabarem chegando à produção.
A arquitetura do produto também influencia as diferentes fases do pipeline e quais artefatos são produzidos em cada fase. Vamos discutir quatro fases comuns em entrega contínua:
Mesmo se forem previstas mais ou menos de quatro fases na organização, os conceitos descritos abaixo ainda se aplicam.
Um equívoco comum é pensar que essas fases têm manifestações físicas no pipeline. Elas não precisam ter. Essas são fases lógicas e podem mapear para marcos ambientais, como teste, staging e produção. Por exemplo, componentes e subsistemas podem ser compilados, testados e implementados no teste. Sistemas ou subsistemas podem ser montados, testados e implementados no staging. Sistemas ou subsistemas podem ser promovidos para produção como parte da fase de produção.
O custo dos defeitos é baixo quando eles são descobertos no teste, médio quando são descobertos no staging e alto quando são descobertos na produção. "Mudar para a esquerda" se refere à validação ser realizada mais cedo no pipeline. A porta do teste até o staging tem técnicas muito mais defensivas criadas hoje em dia; assim, o staging não precisa mais parecer a cena do crime!
Ao longo do tempo, InfoSec chegava no final do ciclo de vida do desenvolvimento de software, quando as versões rejeitadas podem representar ameaças de segurança cibernética para a empresa. Embora as intenções fossem as melhores, causava frustração e atraso. "DevSecOps" defende que a segurança seja integrada nos produtos desde a fase de design, em vez de enviar o produto acabado (podendo ser inseguro) para avaliação.
Vamos analisar melhor como "Shift left" e "DevSecOps" podem ser abordados no fluxo de trabalho de entrega contínua. Nessas próximas seções, cada fase vai ser discutida em detalhes.
Fase de componente de CD
O pipeline primeiro cria os componentes — as menores unidades distribuíveis e testáveis do produto. Por exemplo, uma biblioteca criada pelo pipeline pode ser chamada de componente. O componente pode ser certificado, entre outras coisas, por revisões de código, testes unitários e analisadores de código estático.
Revisões de código são importantes para as equipes terem compreensão em comum das funções, dos testes e da infraestrutura necessários para o produto ser ativado. Um segundo olhar muitas vezes pode fazer maravilhas. Ao longo dos anos, podemos ficar imunes a códigos ruins de maneira que não acreditamos mais que ele seja ruim. Perspectivas novas podem nos forçar a revisitar esses pontos fracos e refatorar com generosidade onde quer que seja necessário.
Testes de unidade são quase sempre o primeiro conjunto de testes de software executados no código. Eles não tocam no banco de dados ou na rede. A forma de verificação do código é o percentual do código que foi tocado pelos testes de unidade. Há diversas maneiras de medir a cobertura, por exemplo, cobertura de linha, cobertura de classe, cobertura de método etc.
Embora seja ótimo ter boa forma de verificação do código para facilitar o refatoramento, é prejudicial determinar metas de cobertura elevadas. Contrário ao que se acredita, algumas equipes com maior forma de verificação do código têm mais falhas de produção que equipes com menor forma de verificação do código. Além disso, se lembre que é fácil jogar com números de cobertura. Sob pressão intensa, em especial durante análises de desempenho, os desenvolvedores podem recorrer a práticas desleais para aumentar a forma de verificação do código. E eu não vou discutir essas informações aqui!
A análise de código estático detecta problemas no código sem que ele seja executado. É um jeito barato de detectar problemas. Como testes de unidade, esses testes são executados no código-fonte e têm baixo tempo de execução. Os analisadores estáticos detectam possíveis vazamentos de memória, além de indicadores de qualidade de código, como complexidade ciclomática e duplicação de código. Durante esta fase, o teste estático de segurança de análises (SAST) é algo comprovado de descobrir vulnerabilidades de segurança.
Defina as métricas que controlam as portas de software e influencie a promoção de código da fase de componente para a fase do subsistema.
Fase do subsistema de CD
Componentes fracamente acoplados compõem subsistemas, as menores unidades implementáveis e executáveis. Por exemplo, um servidor é um subsistema. Um microsserviço em execução em um contêiner também é um exemplo de subsistema. Em oposição a componentes, subsistemas podem ser comparados e validados com relação a casos de uso do cliente.
Assim como uma interface do usuário do Node.js e uma camada da API Java são subsistemas, bancos de dados são subsistemas também. Em algumas organizações, RDBMS (sistemas de gerenciamento de banco de dados relacional) é processado manualmente, embora uma nova geração de ferramentas tenha surgido para automatizar o gerenciamento de alterações do banco de dados e realizar entrega contínua de bancos de dados com sucesso. Pipelines de CD envolvendo bancos de dados NoSQL são mais fáceis de implementar que RDBMS.
Os subsistemas podem ser implementados e certificados por testes funcionais, de desempenho e de segurança. Vamos estudar como cada um desses tipos de teste validam o produto.
Testes funcionais incluem todos os casos de uso de cliente que envolvem internacionalização (I18N), localização (L10N), qualidade de dados, acessibilidade, cenários negativos, etc. Esses testes garantem que seu produto funcione conforme as expectativas do cliente, cumpra a inclusão e atenda ao mercado para o qual ele foi criado.
Determine os referenciais de desempenho com os proprietários dos produtos. Integre testes de desempenho ao pipeline, então use referenciais para aprovar ou reprovar pipelines. Um mito comum é que testes de desempenho não precisam se integrar a pipelines de entrega contínua, porém, essa medida rompe o paradigma contínuo.
Grandes empresas sofreram invasões nos últimos tempos. Ameaças à segurança cibernética estão em seu nível mais elevado. Precisamos nos preparar e garantir que não haja vulnerabilidades de segurança nos produtos, seja no código que escrevemos ou nas bibliotecas de terceiros que importamos para o código. Na verdade, importantes violações foram descobertas em OSS (software de código aberto). Por este motivo, devemos usar ferramentas e técnicas que sinalizem esses erros e forcem o pipeline a anular. DAST (teste dinâmico de segurança de análises) é uma maneira comprovada de descobrir vulnerabilidades de segurança.
A ilustração a seguir articula o fluxo de trabalho discutido nas fases de Componente e Subsistema. Execute etapas independentes em paralelo para otimizar o tempo total de execução do pipeline e obter feedback rápido.
A) Certificando componentes e/ou subsistemas no ambiente de teste
Fase do sistema CD
Quando os subsistemas atendam às expectativas funcionais, de desempenho e de segurança, o pipeline pode ser ensinado a montar o sistema a partir de subsistemas de acoplamento fraco quando todo o sistema é lançado no geral. O que essa ação significa é que a equipe mais rápida consegue avançar na velocidade da equipe mais lenta. É como o velho ditado: “A corrente é tão forte quanto o elo mais fraco”.
A gente não recomenda essa composição antipadrão na qual os subsistemas são combinados em um sistema a ser lançado como um todo. Este antipadrão deixa todos os subsistemas presos no caminho para o sucesso. Se investir em artefatos implementáveis com independência, é possível evitar esse antipadrão.
Quando os sistemas precisam ser validados como no geral, eles podem ser certificados por testes de integração, desempenho e segurança . Ao contrário da fase do subsistema, não use simulações ou stubs durante os testes nesta fase. Além disso, é importante manter o foco em testar interfaces e redes mais do que qualquer coisa.
A ilustração a seguir resume o fluxo de trabalho na fase de Sistema, caso você precise montar seus subsistemas usando composição. Mesmo que você possa colocar seus subsistemas em produção, a ilustração a seguir ajuda a estabelecer as portas de software necessárias para promover o código dessa fase para a seguinte.
O pipeline pode fazer o arquivamento automático de solicitações de alteração (CR) para deixar uma trilha de auditoria. A maioria das empresas usa esse fluxo de trabalho para alterações padrão, ou seja, lançamentos planejados. Esse fluxo de trabalho também deve ser usado para alterações de emergência ou lançamentos não planejados, embora algumas equipes tendam a pegar atalhos. Observe como o fechamento da solicitação de alteração pelo pipeline de CD é automático quando os erros o forçam a abortar. Essa ação previne que as solicitações de alteração sejam abandonadas no meio do fluxo de trabalho do pipeline.
A ilustração a seguir articula o fluxo de trabalho discutido na fase de Sistema de CD. Observe que algumas etapas podem envolver intervenção humana, e essas etapas manuais podem ser executadas como parte de portas manuais no pipeline. Quando mapeada em sua totalidade, essa visualização de pipeline assemelha-se fortemente ao mapa de fluxo de valor de seus lançamentos de produto!
B) Certificando sistema e/ou subsistemas no ambiente de staging
Depois que o sistema montado é certificado, deixe o conjunto inalterado e promova-o para a produção.
Fase de produção de CD
Não importa se os subsistemas podem ser implementados com independência ou montados no sistema, os artefatos são implementados na produção como parte da fase final.
A implementação sem tempo de inatividade (ZDD) previne tempo de inatividade para os clientes e deve ser praticada do teste ao staging e à produção. Blue-green deployment é a técnica de ZDD popular em que novas partes são implementadas em um pequeno grupo da população (chamado "verde"), enquanto a maior parte fica toda alheia no "azul", que tem as partes antigas. Se a situação apertar, reverta todos de volta para o "azul" e muito poucos clientes vão ser afetados. Se tudo parecer bem no "verde", transfira devagar todos do "azul" para o "verde".
Porém, vejo que há abuso de portas manuais em determinadas empresas. Eles exigem que as equipes obtenham aprovação manual na reunião do conselho de aprovação de alterações (CAB). O motivo é, na maioria das vezes, a má interpretação da segregação de funções ou separação de interesses. Um departamento passa para outro buscando aprovação para seguir em frente. Também vi alguns aprovadores de CAB demonstrarem uma compreensão técnica rasa das alterações que estão entrando na produção, assim tornando o processo de aprovação manual lento e tedioso.
Esta é uma boa transição para observar a diferença entre entrega contínua e implementação contínua. A entrega contínua possibilita portas manuais, enquanto a implementação contínua não oferece essa possibilidade. Embora ambos sejam chamados de CD (na sigla em inglês), a implementação contínua exige mais disciplina e rigor, já que não há intervenção humana no pipeline.
Há uma diferença entre mover e ativar os bits. Execute testes de sanidade na produção, que são um subconjunto dos pacotes de testes de integração, desempenho e segurança. Depois da aprovação nos testes de sanidade, os bits ficam ativos e o produto ganha vida para os clientes!
O diagrama a seguir ilustra as etapas realizadas pela equipe nessa fase final da entrega contínua.
C) Certificando sistemas e/ou subsistemas no ambiente de produção
A entrega contínua é o novo normal
Para ser bem-sucedido em entrega contínua ou implementação contínua, é fundamental realizar bem a integração contínua e o teste contínuo. Com a base sólida, você vai vencer em todas as três frentes: qualidade, frequência e previsibilidade.
Um pipeline de entrega contínua ajuda as ideias a se tornarem produtos por meio de vários experimentos sustentáveis. Se descobrir que a ideia não é tão boa quanto pensou que era, é possível voltar rápido com outra ideia melhor. Além disso, os pipelines reduzem os problemas de produção do tempo médio para a resolução (MTTR), reduzindo assim o tempo de inatividade para os clientes. A entrega contínua acaba gera equipes produtivas e clientes satisfeitos e quem não quer algo assim?
Saiba mais no tutorial de entrega contínua.
Compartilhar este artigo
Próximo tópico
Leitura recomendada
Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.