Ir para o conteúdo

Turbine seu negócio digital em até 200x com DevSecOps

As metodologias ágeis permitiram otimizar o desenvolvimento de softwares, mas não consideram os processos adicionais necessários para entrega de novas versões aos usuários. O desenvolvimento é rápido, mas a entrega continua lenta. A cultura DevSecOps eleva essas metodologias a um novo nível para que seja possível otimizar a entrega de novos releases para garantir inovação sem comprometer a conformidade, performance e segurança esperados. 

DevSecOps é um conjunto compreendido de práticas e valores culturais que comprovadamente ajuda organizações de todos os tamanhos a melhorar seus ciclos de lançamento de software, qualidade, segurança e capacidade de obter feedback rápido sobre o desenvolvimento de produtos.

Esteira DevSecOps da Yaman

Por que adotar DevSecOps?

O principal problema enfrentado pelos profissionais da área de desenvolvimento de software é: como transformar uma boa ideia em um sistema e entregá-lo aos usuários o quanto antes? 

A empresa Puppet Enterprise, famosa pelo seu sistema de gestão de configuração largamente usado, fez uma pesquisa em 2016 com mais de 25.000 profissionais de TI ao redor do mundo sobre o uso da prática DevOps ao longo de 5 anos e disponibilizou um relatório onde destaca-se:

  • Organizações que praticam DevOps de forma eficaz conseguem uma taxa de deploy até 200 vezes mais frequentes e gastam menos da metade do tempo com este processo. 
  • Costumam apresentar 3 x vezes menos falhas e, quando ocorrem, conseguem se recuperar em até 24 x menos tempo que empresa de baixa performance que não adotam DevOps.
  • Essas empresas gastam também em média 22% menos tempo com trabalhos não planejados ou retrabalhos e, como resultado, elas podem gastar 29% mais tempo em novos trabalhos, como novos recursos ou códigos.
  • E sobre segurança, costuma gastar 50% menos tempo com correções de vulnerabilidades.

Adoção do DevOps no mundo

Baixe os relatórios para verificar outras métricas e todos os detalhes:

Benefícios ao adotar DevSecOps

  • Tempo de ciclo reduzido para entregar valor mais rapidamente e aumentar
    o lucro. 
  • Redução de esforços para aumentar a eficiência e reduzir custos
    com suporte. 
  • Aumentar a previsibilidade sobre o ciclo de vida de entrega de software para tornar o planejamento mais eficaz.
  • Capacidade de adotar e manter uma atitude de observância com qualquer regime de regulamentação a que a empresa possa ser submetida.
  • Determinar e gerenciar os riscos associados com a entrega de
    software efetivamente. 
  • Custos reduzidos por meio de melhor gestão de risco e menos problemas na entrega de software.

Conceitos Gerais do DevSecOps

DevSecOps visa estabelecer uma cultura e ambiente onde a construção, testes e liberação de software e serviços podem acontecer rapidamente, com frequência e com suporte mínimo, a fim de aumentar continuamente a vantagem do negócio e a satisfação do cliente. DevSecOps leva as práticas Continuous Integration, Continuous Deployment e Contínuos Delivery.

DevSecOps é baseado no conceito Lean, uma prática que essencialmente consiste em direcionar recursos e esforços de produção apenas aquilo que agrega valor ao cliente final, eliminando tarefas adicionais que são consideradas desperdícios. 

No contexto DevSecOps e com base neste conceito Lean, o software que não é entregue com frequência é como o estoque conservado em um armazém. Custou dinheiro para fabricá-lo, mas não produz qualquer retorno financeiro, na verdade, custa dinheiro também para armazená-lo.

Software não entregue é um desperdício. 

Lean, via Wikipedia

É preciso, portanto, focar esforços em reduzir o desperdício para criar um fluxo de entrega baseado em valor para o cliente.

Redução no time-to-marketing

A aplicação desse conceito leva a um negócio Just-in-Time: um sistema de produção que cria e entrega apenas o necessário, quando necessário e na quantidade necessária.

Para que seja possível aplicar este conceito, DevSecOps também se sustenta nas metodologias ágeis de desenvolvimento que possibilitam criar pequenas e recorrentes versões de softwares para validar e ajustar continuamente escopos de entregas planejadas para que possam refletir o que os usuários entendam como valoroso, eliminando desperdícios e criando uma cadeia de produção orientada a um fluxo de valor para seus usuários. 

Entregas pequenas e sistema de engajamento

Mas entregar pequenas e recorrentes novas versões de softwares em um ritmo constante envolve uma série de desafios. Cada nova versão a ser lançada é um evento potencialmente crítico e que, caso apresente falhas, poderá comprometer a experiência do cliente e consequentemente diminuir o valor do negócio. É importante agregar novos valores, como inovações e velocidade, mas é acima de tudo é preciso garantir que os valores possam ser experimentados adequadamente. Esses dois polos são desafios comuns em qualquer empresa e conhecidos como sistemas SoE (System of Engagement ou Sistema de Engajamento) e SoR (System of Register ou Sistema de Registro)

O SoE é o termo usado para representar as ações da empresa necessárias para se manter ágil e inovadora. Da mesma forma, o SoR representa outra parte que tem como necessidade manter tudo funcional. O problema é como fazer o SoR se adaptar rapidamente às mudanças esperada no SoE a fim de manter a continuidade do negócio. Esse desafio é conhecido como TI bimodal. Equipes de Desenvolvimento é um setor que representa as motivações SoE de uma empresa, enquanto a equipe de Operações, as SoR. A prática de DevSecOps leva a consolidação desses dois sistemas para que seja possível ser ágil sem comprometer a continuidade do negócio.

Integração Contínua (CI – Continuous Integration)

A primeira ação comumente adotada para alcançar DevSecOps é a implantação de um processo de Integração Contínua ou comumente conhecida como CI (do inglês Continuous Integration). Esta é a técnica de maior valor para empresas que desejam otimizar seus processos de desenvolvimento. A Integração Contínua realiza automaticamente os processos de build e aplicação de testes funcionais a cada commit realizado, fornecendo feedback, métricas e relatórios instantaneamente a toda equipe de desenvolvimento. 

É muito comum em projetos tradicionais e menos otimizados a aplicação em desenvolvimento estar em um estado não funcional por longo período. Principalmente em projetos grandes, com muitas branches, a nova versão em desenvolvimento encontrar-se em um estado inutilizável na maior parte do seu desenvolvimento. Mesmo quando há testes unitários executados pelos desenvolvedores em suas máquinas não é raro levar muito tempo para eles descobrirem se a aplicação continuará funcional quando as novas funcionalidades forem mescladas porque dependem exclusivamente de testes feitos somente nos estágios posteriores de Aceitação.

fluxo de integração contínua

O processo desta forma apresenta muitos problemas. Pode-se, por exemplo, gastar muito tempo na codificação de um novo recurso e só descobrir que ele não funciona após muito tempo, quando o programador nem mais se recorda dos detalhes do código criado, o que dificulta sua correção. E pior ainda, pode-se descobrir tardiamente que a nova versão não atende ao propósito ao qual foi planejada. 

Há outro problema que pode ocorrer nesses fluxos: como a equipe de desenvolvimento demora para receber respostas sobre a conclusão das validações necessárias para a nova versão entrar em produção, quando preciso resolver algum bug, elas já estarão alocadas e outras tarefas e haverá uma concorrência entre concertar código impróprio dado como concluído e novos recursos em desenvolvimento, sufocando essas equipes e atrasando prazos de entrega planejados. 

Em contrapartida, em projetos que adotam a Integração Contínua o software em desenvolvimento está em um estado não funcional por apenas alguns minutos, quando estão sendo aplicadas as mudanças, que são pequenas e incrementais. A Integração Contínua exige que a aplicação seja compilada a cada nova alteração e um conjunto abrangente de testes funcionais automatizados sejam executados automaticamente para garantir em poucos minutos que o trabalho realizado pelos desenvolvedores realmente atingiu um estado de pronto. 

Com a Integração Contínua, sempre que uma compilação falhar, a equipe de desenvolvimento recebe um feedback automático e interrompe qualquer trabalho em andamento para correção da nova alteração. Software não funcional não tem valor para os usuários e é um desperdício. 

O objetivo da Integração Contínua é manter o software em um estado funcional o tempo todo.

Integração contínua representa uma mudança de paradigma. Sem ela, o software será considerado como não funcional até que se prove que ele funcione, o que normalmente acontece durante o estágio de testes de aceitação ou de integração. Com integração contínua, assume-se que o software está funcionando (desde que haja um conjunto considerável de testes automatizados) a cada mudança – você sabe quando a aplicação deixa de funcionar e pode consertá-la imediatamente. 

Equipes que adotam Integração Contínua de modo eficaz são capazes de entregar software muito mais rápido, e com menos defeitos, do que equipes que não a usam. Defeitos são descobertos mais cedo no processo de entrega, e é mais barato consertá-los, o que representa ganhos de custo e tempo. Dessa forma, consideramos a prática essencial para times profissionais.

Entrega e Implantação Contínua

A Integração Continua traz um grande avanço de produtividade comprovadamente a qualquer empresa, independentemente de seu tamanho. Mas ela não é suficiente. Concentra-se principalmente nas equipes de desenvolvimento e para o software entrar em produção são necessárias validações complementares que certifiquem aspectos não funcionais como capacidade, desempenho, disponibilidade, segurança e usabilidade. É preciso testar os novos releases em ambientes pré-produção iguais ou muito próximos ao de produção para considerar a arquitetura que irá suportar a aplicação. 

Se essas validações não foram feitas em um ritmo constante, sem grandes interrupções e em um tempo próximo ao alcançado com a Integração Contínua, haverá gargalhos no fluxo de entrega e os desenvolvedores continuarão aguardando muito tempo para receberem um feedback sobre a seus releases e quando preciso lidar problemas detectados, provavelmente já estarão alocados em outras tarefas, dificultando as correções e impactando na evolução do software. 

Desta forma será difícil criar a cadeia de produção orientada a fluxo de valor e reduzir desperdício com códigos retidos e não entregues aos usuários. Lembre-se, software não entregue é estoque e, portanto, um desperdício. 

Para que os benefícios da Integração Contínua sejam explorados em sua plenitude a solução é adaptar a integração Contínua a uma visão mais holística, de ponta a ponta, sobre todo processo de entrega. Os releases criados rapidamente precisam entrar em produção o quanto antes. E para isso, todas essas validações complementares precisar ser realizadas em tempo hábil, o que passa pela adoção de automações para reduzir riscos, garantir a conformidade e segurança. Em DevSecOps isso leva a adoção de um pipeline (fluxo) de entrega automatizado que seja previsível, repetitivo e confiável e que é chamado de Entrega Contínua ou Implantação Contínua, dependendo da estratégia de lançamento. 

Na Entrega Contínua, após as validações previstas na CI, a release é provisionada automaticamente em ambientes de pré-produção com as mesmas configurações usadas em produção, onde serão executados testes de aceitação. No entanto, o provisionamento em produção não é automático, sendo uma decisão a ser tomada de acordo com a estratégia de lançamento desejada. 

A adoção deste fluxo leva ao sistema puxado previsto no conceito de Lean. Que, como dito, guia a produção ao que agrega valor ao cliente e elimina trabalhos fora deste contexto. 

Veja a Anatomia de um pipeline CI/CD (Entrega Contínua ou Continuous Dlivery)

Entrega Contínua ou Continuous Deployment (CI/CD)

A Implantação Contínua, ou Continuous Deployment em inglês, é idêntica a Entrega Contínua, mas difere do fato de novos releases após serem validados são provisionados automaticamente em ambiente de produção. Esta é prática é a mais otimizada em DevSecOps e possibilita um ritmo de entrega constante, sem interrupções e à prática plena do conceito de Lean. Mas para aderir é preciso uma alta maturidade em DevSecOps e adoção de estratégias de implantação complementares como Green/Blue e Canary. Assim é mais comum empresas adotarem a Integração contínua inicialmente, avançarem para Entrega Continua e quando mais maduras, evoluírem para Implantação Contínua

Como não é possível praticar a Entrega Contínua sem a Integração Contínua, esse fluxo é conhecido como pipeline CI/CD pelo mercado e é a manifestação prática da cultura DevSecOps. 

Comparação entre Integração, Entrega e Implantação Contínua

Apesar da pipeline CI/CD prevê testes automatizados em vários níveis é comum a adoção de testes manuais de aceitação exploratórios e complementares.

Artigo escrito originalmente por Rodrigo Dias e editado pela equipe de Marketing Yaman

Fique por dentro das novidades do mercado

Assine a nossa newsletter e fique por dentro de tudo que há de novo em aplicações, performance, segurança e tecnologias.

Quer suas aplicações com qualidade, performance e segurança na velocidade que seu negócio precisa?

Fale com nossos especialistas

Partners