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