Por que agilidade não é agilidade sem entrega contínua

Enviar no fim de cada sprint está ao seu alcance. Veja aqui como começar.

Ian Buchanan Ian Buchanan

As práticas ágeis podem ser vistas de duas maneiras: receitas e sensores. Pessoas com muita experiência em software escreveram as práticas que as tornaram mais produtivas. Além disso, as práticas revelam as maneiras pelas quais somos improdutivos amplificando os problemas que causam.

A entrega contínua faz parte da receita ágil e também é um grande revelador de ineficiências. Além disso, para colher os benefícios do ágil, você precisa ser ágil em todas as fases do ciclo de vida de desenvolvimento de software. O planejamento e o desenvolvimento iterativos não contam muito se suas histórias de usuários e atualizações de segurança definharem em um repositório por semanas a fio antes de as partes interessadas e os clientes darem uma olhada nelas.

Você é tão #agile quanto sua capacidade de lançar com frequência e sem drama.

A essência do ágil é "inspecionar e adaptar". Mas você não precisa colocar seu sistema de build e implementação sob um microscópio para avaliar se a metodologia está dificultando ou ajudando a agilidade de sua equipe. E o fato de você estar fazendo esta leitura é um bom sinal de que já colocou seu sistema na categoria de "obstáculos". Então, agora é hora de se adaptar.

Vivendo com frustração contínua

Há um estado comum de software que eu chamo de "frustração contínua". É a ausência de qualquer prática de integração contínua ou entrega contínua. Parece com isto...

  • Você faz o commit à ramificação principal e fica esperando ser culpado por alguém.
  • Sua linha de código principal é instável.
  • Bugs se escondem em um emaranhado de muitas alterações de código, e você teme o esforço que tem pela frente para encontrar o bug (imagine fazer a correção) porque muito tempo passou desde que você trabalhou nessa área de código.
  • Quando os testadores querem testar um recurso, eles têm que incomodar todos os desenvolvedores para conhecer o status atual e encontrar um build que funcione.
  • Lançar requer um congelamento de código. Alguém se torna um gargalo artificial para as alterações de código de forma que ele possa estabilizar a versão. Nesse meio tempo, ninguém para de trabalhar. Vocês só param de fazer o commit das alterações de código, então uma torrente de código não comprovado inunda o repositório como se fosse esgoto assim que o congelamento é desfeito.

Erro | CI/CD da Atlassian

Se essa história é assustadora de tão familiar, saiba que há esperança.

Pense em como "inspecionar e adaptar" melhorou seu processo de planejamento e extrapole essa ideia para os processos de desenvolvimento e entrega. Imagine que você possa detectar problemas em cada commit que fez. Agora imagine que você consegue detectar problemas em sua estação de trabalho local, mesmo antes de fazer um commit. O que acabou de imaginar chega ao cerne do porquê o ágil precisa de entrega contínua: os desenvolvedores precisam de feedback rápido.

A parte boa de embarcar na jornada para a entrega contínua é que ela começa com você. Você não tem que vender nada a ninguém ou convencer sua equipe que você deve ser mais como o Etsy. E ninguém está usando tecnologia tão única que os princípios básicos, práticas e ferramentas de entrega contínua não se aplicam. Há algumas coisas fáceis que você pode fazer agora que vão tornar sua vida melhor.

Comece com um script e um servidor

No passado, havia apenas Make, mas muitos desenvolvedores foram acometidos pela mania do espaço em branco. Mais tarde, Ant substituiu o espaço em branco por colchetes angulares. Agora, você pode pular essas gerações anteriores. Claro, você ainda vai ver muitos projetos de código aberto usando Maven ou mesmo Ant. Só os marque como velhos hábitos. Mas você pode recorrer a linguagens de build baseadas em XML como uma opção de fallback.

A última geração de linguagens de build é muito mais fácil de aprender e usar. Na maioria dos casos, é possível usar uma linguagem de build escrita no mesmo idioma que usa ao criar seu aplicativo, o que torna tudo mais fácil para você (e sua equipe).

Gráfico de linguagem de código e ferramenta recomendada correspondente | CI/CD da Atlassian

A parte "contínua" da entrega contínua significa obter feedback sobre cada commit, e é por esse motivo que os servidores de build escutam automaticamente seu repositório e vão acionar um build quando algo mudar. Ser contínuo também significa consertar o build quando ele quebra. Como desenvolvedor, você se beneficia do isolamento da mudança. A melhor maneira de evitar que as atualizações de segurança fiquem complicadas e difíceis é evitar que elas se acumulem em primeiro lugar. Servidores de build, como o Bamboo, são fáceis de instalar. Para começar, o objetivo é simplesmente executar seu script de build em um ambiente limpo. Em certo sentido, a primeira coisa que seu servidor de build faz é ajudar a detectar problemas em seu script de build.

Comece a detectar problemas automaticamente

Como você pode imaginar, seu servidor de build pode detectar muito mais do que problemas com o script de build. Há coisas fáceis, como ativar avisos de compilador (para alguns idiomas), e coisas mais difíceis que todo agile coach vai dominar, como testes automatizados. O motivo é que o teste apenas manual é um gargalo para entrega contínua. Se você acaba de começar a fazer testes automatizados, encontre a camada — unidade, integração, aceitação, interface do usuário — que vai trazer o feedback mais rápido.

Vamos acabar com a controvérsia: o teste automatizado NÃO é uma ameaça para os testadores manuais.

Na verdade, os testadores humanos criam excelentes guias quando se trata de decidir o que (e o que não) automatizar. Uma estratégia de automação inteligente depende da pergunta: "Que tipos de problemas seriam mais valiosos de detectar?" Você precisa de humanos experientes que se especializem em qualidade de software para conseguir essa resposta.

As sementes da entrega contínua

Qualquer um pode começar. Mas se você estiver sozinho, ninguém vai reconhecer como entrega contínua. O próximo passo é trazer esses blocos de construção para sua equipe.

Use livros e artigos sobre integração contínua e testes ágeis como inspiração. Mais tarde, você vai encontrar mais e mais motivos do porquê estar pronto para implementar é útil. Em seguida, você pode se inspirar na entrega contínua e na implementação contínua.

O ponto de partida para todos é bastante comum, mas o estado final vai ser algo único para seu produto e sua empresa.