Grandes empresas e a entrega contínua
Essa é uma visão de como o conceito de entrega contínua agrega ao negócio de grandes empresas.
Empresas, independente do segmento, disputam mercado palmo a palmo, o “Market-Share” é um objetivo contínuo a ser alcançado e mantido.
Uma das formas de ganhar mercado é largar na frente, lançando ou evoluindo seus produtos/serviço antes dos outros. Para isso o foco é no famoso “Time-to-Market”, que é o melhor (não necessariamente o menor) tempo para um novo lançamento.
Mas a correria de lançar algo novo no mercado pode se tornar um problema se não for feito com muito cuidado.
Responda as perguntas:
- Meu novo produto tem aceitação? Ele é realmente útil para os clientes?
- Consigo garantir qualidade? Quanto tempo para uma correção?
- Consigo garantir segurança? Quanto tempo para reverter o gap?
Falando em software, do lado da TI, estabelecer um processo de entrega contínua é ponto determinante para conseguir responder a essas perguntas.
Continuous Integration / Delivery
A ideia é segmentar o projeto em pequenos entregáveis, que automaticamente passam por validações de qualidade de código, validações de segurança e uma bateria de testes até chegar em produção. Em produção o processo de deploy também é controlado para garantir que tudo está correto.
Metodologias ágeis são voltadas para gestão desse modelo granular, organizando e controlando sprints, artefatos, impedimentos, entregáveis e etc.
Outro ponto interessante é que a necessidade das automações de processos que envolvem, desde a camada de código até o provisionamento da infraestrutura, acabou por criar um conceito e perfil de profissional que atua tanto na camada de desenvolvimento quando na de operações, o DevOps.
Empresas com esse tipo de processo já maduro conseguem realizar centenas de deploys por dia, o que garante a elas vantagens competitivas por conta da sua agilidade.
Tudo isso permite que a coisa toda aconteça muito rápida e controlada, o que agrega bastante quando falamos de:
MVP (Minimum Viable Product)
O MVP é a forma de testar funcionalidades, aceitação e aderência de novos produtos, disponibilizando no mercado a menor versão do produto mas que agregue o valor esperado. Dessa forma o gasto em tempo e dinheiro é minimizado caso algo de errado e também ajuda a direcionar a estratégia de evolução.
Time-to-Market
Entregas contínuas geram valor contínuo. Não é preciso esperar semanas ou meses para subir para produção uma alteração grande. A ideia é subir diversos pacotes em curtos espaços de tempo.
Acompanhar a estratégia de negócio
O mercado muda constantemente. O comportamento de clientes, a situação econômica do país, acontecimentos imprevistos, sazonalidades, concorrência entre outros fatores obriga o negócio mudar de direção constantemente. Muitas dessas mudanças afetam diretamente a TI que precisa acompanhar e responder o mais rápido possível as alterações.
Qualidade
O processo em si, quando bem definido garante que a grande maioria dos bugs sejam detectados rapidamente, de preferência antes de chegar em produção. Rotinas de testes e validações são executadas de forma automática, tanto nos processos de homologação e deploy quanto em produção logo após a publicação.
Existem métodos de publicação como o “blue-green” e “canary” que tornam a subida em produção mais segura e sem paradas.
Resiliência
O ciclo de entrega contínua contribui para que os sistemas possam se adaptar e responder rapidamente a problemas, uma vez que uma correção pode ser desenvolvida e lançada em pouquíssimo tempo.
Segurança
Durante o pipeline de publicação, os pacotes são submetidos a testes específicos de segurança, verificando se o código segue a práticas de desenvolvimento seguro, procurando por brechas e vulnerabilidades.
Compliance
Cada passo do processo é rastreado, gerando evidências, armazenando logs e passando por aprovações. O fluxo deve ser adaptado conforme a maturidade de compliance da companhia, se conectando as ferramentas de gestão de processos e gerando aderência às normativas como SOX, PCI e etc…
Por fim, a um tempo atrás assisti a uma palestra do Donovan Brown (que é o cara do DevOps da Microsoft). E ele disse que só tem 1 dia no ano em que eles não fazem deploys em produção, dia 25/12 (Natal), todos os outros 364 dias têm publicações. Disse também que nunca fizeram um rollback se quer, as correções são sempre novas publicações.
Até a próxima!
Cristiano Dianese