Fechar

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?

How does a pipeline relate to continuous delivery (CD)? As the name suggests, a continuous delivery pipeline is an implementation of the continuous paradigm, where automated builds, tests and deployments are orchestrated as one release workflow. Put more plainly, a CD pipeline is a set of steps your code changes will go through to make their way to production.

A CD pipeline delivers, as per business needs, quality products frequently and predictably from test to staging to production in an automated fashion.

For starters, let’s focus on the three concepts: quality, frequently, and predictably.

We emphasize on quality to underscore that it’s not traded off for speed. Business doesn’t want us to build a pipeline that can shoot faulty code to production at high speed. We will go through the principles of “Shift Left” and “DevSecOps”, and discuss how we can move quality and security upstream in the SDLC (software development life cycle). This will put to rest any concerns regarding continuous delivery pipelines posing risk to businesses.

Frequently indicates that pipelines execute at any time to release features, since they are programmed to trigger with commits to the codebase. Once the pipeline MVP (minimum viable product) is in place, it can execute as many times as it needs to with periodic maintenance cost. This automated approach scales without burning out the team. This also allows teams to make small incremental improvements to their products without the fear of a major catastrophe in production.

Cliche as it may sound, the nation of “to err is human” still holds true. Teams brace for impact during manual releases since those processes are brittle. Predictably implies that releases are deterministic in nature when done via continuous delivery pipelines. Since pipelines are programmable infrastructure, teams can expect the desired behavior every time. Accidents can happen, of course, since no software is bug-free. However, pipelines are exponentially better than manual error-prone release processes, since unlike humans, pipelines don’t falter under aggressive deadlines.  

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: uma confirmação, ou um pequeno lote incremental de confirmações, 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.

Continuous delivery pipeline articles

[CONTINUED]

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:

Even if you foresee more than four phases or less than four in your organization, the concepts outlined below still apply.

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 "Mudança para a esquerda" e "DevSecOps" podem ser abordados no fluxo de trabalho de entrega contínua. Nessas próximas seções, vamos discutir cada fase em detalhes.

CD Component phase

The pipeline first builds components - the smallest distributable and testable units of the product. For example, a library built by the pipeline can be termed a component. A component can be certified, among other things, by code reviews, unit tests, and static code analyzers.

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!

Static code analysis detects problems in code without executing it. This is an inexpensive way to detect issues. Like unit tests, these tests run on source code and have low run-time. Static analyzers detect potential memory leaks, along with code quality indicators like cyclomatic complexity and code duplication. During this phase, SAST (static analysis security testing) is a proven way to discover security vulnerabilities.

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.

Subsystems can be deployed and certified by functional, performance, and security tests. Let’s study how each of these test types validate the product.

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) Certifying components and/or subsystems in the test environment

Fase do sistema CD

Once subsystems meet functional, performance, and security expectations, the pipeline could be taught to assemble a system from loosely coupled subsystems in cases where the entire system has to be released as a whole. What that means is that the fastest team can go at the speed of the slowest team. Reminds me of the old saying, “A chain is only as strong as its weakest link”.

We recommend against this composition anti-pattern where subsystems are composed into a system to be released as a whole. This anti-pattern ties all the subsystems at their hips for success. If you invest in independently deployable artifacts, you will be able to avoid this anti-pattern.

Where systems need to be validated as a whole, they can be certified by integration, performance, and security tests. Unlike subsystem phase, do not use mocks or stubs during testing in this phase. Also, focus on testing interfaces and network more than anything else.

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.

The pipeline can automatically file change requests (CR) to leave an audit trail. Most organizations use this workflow for standard changes, which means, planned releases. This workflow should also be used for emergency changes, or unplanned releases, although some teams tend to cut corners. Note how the change request (CR) is closed automatically by the CD pipeline when errors force it to abort. This prevents CRs from being abandoned in the middle of the pipeline workflow.

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 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.

This is a good segway to call out the difference between continuous delivery and continuous deployment. Continuous delivery allows manual gates whereas continuous deployment doesn’t. While both are referred to as CD, continuous deployment requires more discipline and rigor since there is no human intervention in the 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!

The following diagram illustrates the steps carried out by the team in this final phase of continuous delivery.

C) Certifying subsystems and/or system in the production environment

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.

A continuous delivery pipeline helps your ideas become products through a series of sustainable experiments. If you discover your idea isn’t as good as you thought it was, you can quickly turn around with a better idea. Additionally, pipelines reduce the MTTR (mean time to resolve) production issues, thus reducing downtime for your customers. With continuous delivery, you end up with productive teams and satisfied customers, and who doesn’t want that?

Learn more in our Continuous Delivery tutorial.

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.