Close

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.

O que é um pipeline de entrega contínua?

Como um pipeline se relaciona com a entrega contínua (CD)? Como o nome sugere, o pipeline de entrega contínua é uma implementação do paradigma contínuo, em que builds, testes e implementações automatizados são organizados como fluxos de trabalho de versão. 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.

Enfatizamos a qualidade para destacar que não se abre mão dela em prol de velocidade. As empresas não querem que criemos um pipeline que possa enviar um código defeituoso para produção em alta velocidade. Vamos passar pelos princípios de "Mudança para a esquerda" e "DevSecOps" e discutir como podemos mover qualidade e segurança para o início do processo no SDLC (ciclo de vida de desenvolvimento de software). Isso acabará com qualquer preocupação relativa a pipelines de entrega contínua imporem um risco aos negócios.

Frequência significa que os pipelines são executados a qualquer momento para lançar recursos, já que eles 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. Isso também permite que as equipes façam pequenas melhorias incrementais aos produtos sem o medo de grandes catástrofes na produção.

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 esperar o comportamento desejado, sempre. 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 recursos e, então, produtos de maneira segura e auditável.

Artigos sobre a pipeline de entrega contínua

[CONTINUAÇÃO]

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 seu 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" refere-se à validação ser realizada mais cedo no pipeline. A porta do teste até o staging tem técnicas muito mais defensivas criadas atualmente; assim, o staging não precisa mais parecer uma cena de crime!

Historicamente, InfoSec chegava no final do SDLC (ciclo de vida de desenvolvimento de software) e rejeitava versões que pudessem representar ameaças à segurança cibernética para a empresa. Embora as intenções fossem as melhores, isso causava frustração e atraso. "DevSecOps" defende que a segurança seja integrada nos produtos desde a fase de design, em vez de enviar um produto acabado (possivelmente não seguro) 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 uma compreensão em comum dos recursos, 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ódigo ruim de maneira que não acreditamos mais que ele seja ruim. Perspectivas novas podem nos forçar a revisitar esses pontos fracos e refatorar generosamente onde quer que seja necessário.

Testes de unidade são quase sempre o primeiro conjunto de testes de software executados em nosso código. Eles não tocam no banco de dados nem na rede. A cobertura 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 cobertura de código para facilitar a refatoração, é prejudicial determinar metas de cobertura elevadas. Contrário ao que se acredita, algumas equipes com alta cobertura de código têm mais falhas de produção que equipes com menor cobertura de código. Além disso, lembre-se de que é fácil jogar com números de cobertura. Sob pressão intensa, especialmente durante análises de desempenho, os desenvolvedores podem recorrer a práticas desleais para aumentar a cobertura do código. E eu não vou tratar desses detalhes 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 essa fase, o SAST (teste estático de segurança de análises) é um jeito comprovado de descobrir vulnerabilidades de segurança.

Defina as métricas que controlam suas 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 seus referenciais de desempenho com os proprietários dos seus produtos. Integre seus 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, isso rompe o paradigma contínuo.

Grandes organizações sofreram invasões recentemente, e 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 em nossos produtos, seja no código que escrevemos ou nas bibliotecas de terceiros que importamos para nosso código. Na verdade, importantes violações foram descobertas em OSS (software de código aberto), e devemos usar ferramentas e técnicas que sinalizem esses erros e forcem o pipeline a anulá-los. DAST (teste de segurança de análise dinâmica) é 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 subsistema de CD

Fase do sistema CD

Uma vez que os subsistemas atendam às expectativas funcionais, de desempenho e de segurança, o pipeline pode ser ensinado a montar um sistema a partir de subsistemas de acoplamento fraco nos casos em que todo o sistema precisa ser lançado como um todo. O que isso 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 seu 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 um todo, 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, mantenha o foco em testar interfaces e rede, mais do que qualquer outra 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 mudança (CR) para deixar uma trilha de auditoria. A maioria das organizações usa esse fluxo de trabalho para mudanças padrão, ou seja, lançamentos planejados. Esse fluxo de trabalho também deve ser usado para mudanças de emergência ou lançamentos não planejados, embora algumas equipes tendam a pegar atalhos. Observe como o fechamento da solicitação de mudança (CR) pelo pipeline de CD é automático quando os erros o forçam a abortar. Isso evita que as solicitações de mudanças 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
Fase do sistema CD

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 de modo independente ou precisam ser montados em um sistema, esses artefatos são implementados na produção como parte da fase final.

A ZDD (implementação com tempo de inatividade zero) é fundamental para prevenir o tempo de inatividade para os clientes e deve ser praticada do teste ao staging e à produção. Implementação azul-verde é uma 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 totalmente alheia no "azul", que tem as partes antigas. Se a situação apertar, reverta todos de volta para o "azul" e muito poucos clientes serão afetados. Se tudo parecer bem no "verde", transfira lentamente todos do "azul" para o "verde".

Algumas organizações exigem uma porta manual (ou duas) antes de o pipeline ser implementado na produção. Há cenários em que portas manuais são legítimas, por exemplo, as empresas podem querer focar um determinado grupo demográfico ou geográfico da população e coletar dados antes do lançamento para o mundo.

Porém, vejo que há abuso de portas manuais em determinadas organizações. Elas exigem que as equipes obtenham aprovação manual em uma reunião de CAB (conselho de aprovação de mudanças). O motivo costuma ser a interpretação incorreta da segregação de deveres ou da separação de preocupações, e um departamento transfere para o outro buscando aprovação para avançar. 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 os bits e ativá-los. 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 dos testes de sanidade, ative os bits, e o produto ganhará vida nas mãos dos seus 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
Fase de produção de CD

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 uma base sólida, você 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 MTTR (tempo médio para a resolução), 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 isso?

Juni Mukherjee
Juni Mukherjee

Juni is a thought citizen in the DevSecOps space and has made deep investments in the field of Continuous Delivery. She has helped organizations build Continuous Delivery Pipelines, and would love to solve the problems that plague our industry today. She has authored a couple of books.