Ainda depois de mais de 11 anos praticando agilidade, muitas são as equipes de desenvolvimento de software que sonham em realizar um deploy a partir de um simples click. O que geralmente ocorre é que as organizações e seus respectivos times/produtos muitas vezes não estão preparados para este grande passo. 

Para ilustrar e enriquecer este post, acompanhe algumas dicas e aprendizados adquiridos através de experiências e treinamentos como por exemplo com o autor do livro Continuous Delivery, @jezhumble.

O quão ágil é o seu time?

Hoje em dia não raros são os times de desenvolvimento de software que se consideram “ágeis”, ou que buscam nas praticas ágeis a base para seus ciclos de desenvolvimento. @Jezhumble costuma questionar o quão ágil um time de desenvolvimento é. E o mais importante, como chegar a uma métrica para mensurar tal informação. A reposta mais simples possível vem do mesmo @jezhumblee, onde ele sugere mensurar o quão rápido seu time consegue entregar software de qualidade a seus clientes. #ficaadica

Seu time está preparado para entregar software de forma contínua?

Ainda falando em desenvolvimento àgil de software, temos como premissa a entrega de software agregando valor ao negócio do cliente. Desta forma muitas equipes pecam na tentativa de estabelecer uma linha de entrega contínua a seus clientes, onde os motivos vão desde erros operacionais básicos das equipes até mesmo o despreparo por parte do cliente em relação ao modelo de entrega proposto.

Para evitar os pecados mencionados anteriormente, procure criar uma cultura de entrega continua. Faça com que a entrega de versões ou a simples entrega de uma nova funcionalidade faça parte do planejamento de cada equipe e não apenas após finalizado a codificação da mesma. Discuta estratégia de entregas. Discuta, reforce, defina o conceito de “PRONTO” com o seu time e lembre-se, tarefa pronta significa valor entregue ao cliente em produção.

Automação

Novamente parafraseando @jezhumble “… automação é tudo” ou talvez seria para tudo? O fato é que automação é um ponto chave para quem busca realizar entregas consistentes independentemente do tamanho do ciclo de desenvolvimento trabalhado.

Garanta através de “mecanismos de segurança” constantes validações sob a versão ainda em desenvolvimento, gerando feedback constante e garantindo que a linha de produção não pare, ou se caso venha parar que volte a produzir o quanto antes possível. Entre estes mecanismos estão a automação de testes validando a versão a cada commit realizado. Integrar continuamente a versão corrente evitado surpresas ao fechar versões para produção ou então rodar noturnamenta suites de regressões antecipando não conformidades geralmente identificadas apenas na validação de versões pré-produção.

Eliminar processos complexos e consequentemente dificeis de serem executados é um fator muito importante na automação de tarefas. Se uma tarefa é complexa para ser executada, talvez necessite ser executada com mais frequência buscando assim alternativas e soluções mais simples de serem executadas.

Não elimine a intervenção das pessoas no processo de entrega, pessoas são ótimas em heuristica.

“… se é demorado é porque é dificil, se é dificil é porque é manual, se é manual precisa ser automatizado”

 Continuous Deployment e Continuous Delivery

Os termos Continuous Deployment e Continuous Delivery podem nos gerar confusão. Pois bem vamos exemplificar o conceito de cadas um deles abaixo:

• Continuous Deployment: É caracterizado pelo fechamento de builds de software funcionais.

Ex.: Realizar o fechamento de versão e realizar o deploy no ambiente de homologação a cada nova funcionalidade uma vez validada pelos testes. Note não estamos entregando software em produção. 

• Continuous Delivery: Pode ser considerado o passo de simplesmente agregar valor ao negócio propriamente dito. Conforme o ambiente, baterias de validações podem fazer parte deste processo intermediado diretamente pelo pessoal de negócio, ou simplesmente em ambientes automatizados este mesmo time decide qual o melhor entregável deve ser promovido para produção clicando no botão “release”. http://goo.gl/QkaO 

Cultura DevOps 

Leve para dentro de seu time a cultura DevOps, fazendo o time de desenvolvimento sentir as dores atuais para realizar a liberação de uma nova versão. Fazer do time de operações uma extensão do time de desenvolvimento ou vice-versa.

Esta maior integração propicia ao desenvolvedor uma maior responsabilidade dentro do processo de liberação de novas versões. A prática de code refactoring não pode ser vista como ato de heroísmo e sim de responsabilidade e respeito para com o time. Um desenvolvedor deve garantir que após realizar uma refatoração em uma parte do sistema, tudo deve continuar funcionando conforme anteriormente.

Realize eventos para apresentar grandes mudanças no software, evitando assim também grandes surpresas e processos de rollbacks/fallbacks traumáticos. Mas esteja sempre preparado para executá-los da melhor forma possível.

Estude melhores práticas e formas de modo a facilitar o bom andamento do ciclo de desenvolvimento de seu time tais como:

• Feature Toogles;
• Feature Branching; 
• Blue-Green Deployment;
• Virtualização etc …

Pratique Chaos Monkey! Aprenda com suas falhas e a melhor forma de fazer isso é falhar frequentemete. Certifique-se de que sua infraestrutura pode ser recriada através do seu controle de versão, incluindo scripts de toda e qualquer espécie.