Continuous Delivery

Para uma empresa ou equipe ter a pretenção de começar a usar continuous delivery, o primeiro passo é fundar os alicerces, algo que demanda tempo,  planejamento e meticulosa execução. Não é fácil não !

1. Processo – Não se automatiza entregas a cada Commit sem “treinar” muito, adotar agilidade, visão de valor iterativo-incremental, gestão visual, senso de equipe, com qualidade e integridade desejadas, só assim para levantar a bandeira de continuous delivery, um deploy a cada commit é trabalho duro;

2. Confiança – Apenas com um histórico de qualidade e resultados práticos consistente por um longo período gerará auto-confiança para negociar com a governança, segurança e middleware um  projeto desta natureza, pois hoje ainda vêem esta automação como de alto risco para nosso ambiente de  produção;

3. Testes Automatizados – Um débito antigo tem que ser superado, deixar de fazer testes manuais, baseados em planos de testes é imperativo, partir para os testes automatizados, unitários, funcionais, regressão, aceitação, não adianta ficar postergando, o momento ideal não existe, tem que começar;

4. Benchmark – Estudar os cases de mercado, quem esta usando o que, fazendo como, aprender com as boas praticas, principalmente evitar erros previsíveis. Aqui é que entram eventos e oportunidades com os players de mercado, como o da DBServer que ocorrerá no dia 12/07 no TecnoPUC.

Reflexões

Pertencimento, cá estamos nós novamente frente a este poderoso valor ágil, o senso de propriedade gera a idéia de comprometimento, usando continuous delivery somos obrigados a ir além, devemos ter real domínio da solução, das suas dependências, componentização, frameworks, …

Não tem como implantar continuous delivery se para colocar cada versão em produção é preciso mobilizar uma equipe inteira, analistas de suporte e de banco de dados, é necessário homologar a solução em produção, antes para aprová-la e depois para ter certeza de que funcionou.

O conceito de Continuous Delivery no desenvolvimento de software não é uma unanimidade,  a possibilidade de publicar novas funcionalidades ou alterações em produção exigem uma grande confiança no domínio da equipe, não só da arquitetura e criação do código, como no gerenciamento de configuração.

A disciplina de DevOps não é a solução para o problema, mas com certeza tem muito o que agregar para o planejamento  do processo e de sua melhoria contínua. Sugiro o post sobre DevOps, se quiser ler, clique aqui.

Livro – Um dos autores do livro Continuous Delivery, Jez Humble, é diretor na ThoughtWorks Studios.