Continuous Delivery: Passos para implementação

Desenvolvimento de software sempre foi uma atividade bastante dolorida. Já nos anos 70 se falou na primeira “crise do software”, onde pela primeira vez as dificuldades e armadilhas de se desenvolver sistemas complexos foram discutidas francamente.

As causas dessa crise eram projetos estourando prazos e orçamentos, projetos que não atingiam os objetivos de negócio, com baixa qualidade, e que os tornava praticamente insustentáveis de se manter no médio / longo prazo.

Nascia nesta época a engenharia de software, o modelo Waterfall, futuramente processos de desenvolvimento e gestão, o RUP então o SCRUM, agora o KANBAN.

Por um lado, uma tentativa incessante de se melhorar as práticas de engenharia de software olhando por dentro a arquitetura, o código, a gerência de configuração, a integração contínua, as automações de build, teste e deploy, por outro, como conduzir, motivar e reter talentos. Tentamos fazer de tudo! Nos reinventamos a todo o momento para nos livrar da tal crise do software que parece não ter nos largado até hoje.

Do ponto de vista de negócio, os resultados da indústria de software são terríveis. Apenas um terço aproximadamente dos projetos de software no mundo são bem sucedidos, segundo o Standish Group, no seu estudo intitulado “The Chaos Manifesto”, que vem medindo ano a ano os resultados da indústria de software desde 2004.

Os critérios para que os projetos sejam considerados bem sucedidos incluem serem concluídos dentro do prazo, do custo e com o escopo previsto. Imagina se somássemos a estes critérios o índice de felicidade das pessoas que trabalharam nestes projetos, da família destas pessoas e ainda dos usuários que utilizam os sistemas que desenvolvemos. Qual seria o resultado?

Está na pauta de qualquer CIO hoje em dia tratar de ALM (gerenciamento do ciclo de vida da aplicação) e agilidade, sempre pensando em como mudar os resultados históricos obtidos.

Uma visão recente sobre como mudar a forma tradicional de se produzir software e que vem ganhando força é o conceito de Continuous Delivery, que ganhou o mundo a partir de 2010 com a escrita do livro que leva o nome do conceito, por Jez Humble e David Farley.

Falar de continuous delivery significa reduzir o tempo entre um código pronto e seu uso pleno pelos usuários reais, através de automação e melhoria dos processos de desenvolvimento e liberação de software.

Técnicas como automação de testes, integração contínua e automação de build e deploy, permitem o desenvolvimento de software de alto padrão, de fácil empacotamento e distribuição. Isso habilita levar, com baixo risco e com um mínimo de intervenção humana, as melhorias e correções de bugs aos usuários, de forma rápida, confiável e repetível.

Podemos falar de continuous delivery sob várias perspectivas, mais ou menos técnicas, focado na escrita de software, de ALM ou de negócios. Esta matéria aborda a discussão na perspectiva do ciclo de vida das aplicações.

Ela vai contar a história de um time, os Aspiras, abreviação de Aspirantes, que partiu do zero e que foram evoluindo, melhorando suas práticas, processos e ferramentas até alcançar o estado de entregar software de valor continuamente.

Uma coisa que precisa ficar claro neste tipo de leitura, que aborda a discussão sobre níveis de maturidade, é que a análise deve ser feita sempre no contexto de projetos, nunca das organizações.

Normalmente, uma mesma organização possui vários projetos em diferentes níveis de maturidade. Outra coisa importante de ser dita é que nem todo projeto precisa praticar continuous delivery. Para alguns isso pode simplesmente não fazer sentido por uma série de fatores.

Por isso, quando estiver lendo, tente imaginar um dos seus projeto onde pareça fazer sentido.

Uma última questão a ser considerada é que os níveis descritos neste artigo não refletem nenhum padrão definido de mercado. Os níveis são baseados na observação de inúmeras organizações onde o autor do artigo teve a oportunidade de discutir sobre produção e entre ...