Pipeline de entrega contínua no SAFe: as quatro etapas e o CALMR

O Continuous Delivery Pipeline é o fluxo que leva uma ideia até quem usa, em quatro etapas: exploração contínua, integração contínua, implantação contínua e liberação sob demanda. Cada Agile Release Train cria ou compartilha um pipeline, mapeado sobre o próprio fluxo de valor.

A decisão de projeto mais importante dele está na separação das duas últimas etapas. Estar em produção e estar disponível para o cliente são coisas diferentes. Quando se tratam como uma só, o lançamento vira evento de risco, e a data passa a ser definida por janela técnica em vez de estratégia de negócio.

Antes do pipeline, o DevOps

O pipeline não se sustenta sem a cultura que o DevOps propõe: quebrar o silo entre quem constrói e quem opera.

A tensão é real e vale nomear, porque ela não desaparece com boa vontade. Desenvolvimento é otimizado para velocidade de mudança. Operação é otimizada para estabilidade. As duas coisas são legítimas, e o pipeline existe para que uma não precise ser sacrificada pela outra.

O SAFe cita os números da pesquisa DORA, do relatório Accelerate State of DevOps de 2019, comparando times de alto e de baixo desempenho:

• 208 vezes mais frequência de implantação
• 106 vezes menos tempo entre escrever e entregar
• 7 vezes menos falha em mudança
• 2.604 vezes mais rápido para recuperar de incidente

Vale ler esses números com atenção ao que eles dizem junto: os dois primeiros são vazão, os dois últimos são estabilidade. O achado da pesquisa não é que se troca uma pela outra. É que os mesmos times são melhores nas quatro ao mesmo tempo.

E uma nota sobre segurança: o modelo evoluiu para DevSecOps, e no SAFe, quando se fala de DevOps, os atributos de segurança já estão nas práticas. Segurança não é uma etapa no fim, é característica de cada etapa.

CALMR: a abordagem do SAFe para DevOps

CALMR é o acrônimo que o SAFe usa para guiar os trens até a entrega contínua. Cinco frentes que avançam juntas.

Cultura. Responsabilidade compartilhada entre desenvolvimento, implantação e operação. Não é sobre simpatia entre áreas: é sobre quem responde quando algo quebra em produção. Se a resposta for "a operação", o pipeline não vai existir.

Automação. Automatizar o pipeline reduz erro e atraso vindos de ação manual. É a frente mais óbvia e a única que se resolve com investimento.

Fluxo Lean. Manter pacote de trabalho pequeno, limitar o trabalho em progresso e dar visibilidade externa. É o Kanban aplicado ao caminho até produção.

Medição. Medir o fluxo pelo pipeline, com telemetria em toda a cadeia. Sem medida, "o pipeline está lento" é opinião.

Recuperação. Arquitetar para que o lançamento tenha baixo impacto, e para que reversão e correção rápida sejam possíveis. Esta é a frente que costuma ser esquecida, e é a que decide se a organização tem coragem de implantar com frequência. Quem não sabe voltar atrás implanta menos.

Antes da prova Teste seu nível com 30 questões no formato da prova do SAFe Agilist

As quatro etapas

Exploração contínua

Começa entendendo a necessidade de quem usa e propondo solução. É aqui que o Design Thinking opera, e a etapa se divide em quatro práticas:

• Criar hipótese, capturando ideia e definindo como validá-la
• Colaborar e pesquisar, junto com cliente e interessados, para refinar o entendimento
• Arquitetar, visualizando a abordagem técnica que vai sustentar implantação e operação
• Sintetizar, organizando tudo em visão, roteiro e backlog priorizado que alimenta o planejamento

Repare que "arquitetar" está na primeira etapa, e não na segunda. É deliberado: decidir arquitetura depois de comprometer escopo é a origem de boa parte do retrabalho.

Integração contínua

É a fábrica. Aqui as histórias e funcionalidades mapeadas na exploração se tornam código utilizável.

• Desenvolver, implementando as histórias
• Compilar, gerando binário implantável e integrando ramificações no tronco
• Testar ponta a ponta, validando a solução
• Homologar, hospedando e validando em ambiente parecido com produção

O princípio que sustenta a etapa: com integração contínua, o sistema está sempre disponível para implantação. Não existe fase de estabilização antes de poder implantar.

Implantação contínua

Leva o que foi validado em homologação para produção, onde fica preparado para lançamento.

• Implantar em produção
• Verificar que funciona corretamente ali, antes de qualquer cliente ver
• Monitorar, com alarme e relato de problema
• Responder, resolvendo rápido, com correção ou reversão

Implantar pode parecer repetição da integração, e quem já fez sabe que não é. Por mais que homologação seja parecida com produção, produção tem tráfego real, dado real e integração real. O risco não é o mesmo, e é por isso que a etapa tem "verificar" e "responder" como práticas próprias.

Liberação sob demanda

Libera para o cliente, de uma vez ou de forma incremental, com base na demanda do negócio.

• Lançar, entregando a quem usa
• Estabilizar e operar, garantindo funcionamento nas perspectivas funcional e não funcional
• Medir, quantificando se o que foi lançado entrega o valor pretendido
• Aprender, decidindo o que fazer com o que se descobriu e preparando o próximo ciclo

E aqui o pipeline fecha: o aprendizado desta etapa volta a virar hipótese na exploração. É o mesmo ciclo do Lean Startup, operando numa escala maior.

O argumento que justifica a etapa existir separada: o valor do desenvolvimento só é tangível quando alguém está usando. Código em produção que ninguém acessa é estoque, não entrega.

Architectural Runway

Vale fechar com um conceito que sustenta tudo acima e raramente aparece nas conversas sobre pipeline.

A Architectural Runway é tudo que já existe pronto para habilitar as próximas funcionalidades: código, componente, infraestrutura, documentação, arquitetura. A metáfora é de pista de decolagem, e ela funciona: habilitadores constroem a pista, funcionalidades a consomem.

A consequência prática é o que importa. Se a organização só entrega funcionalidade, a pista encurta a cada intervalo, até o momento em que a próxima funcionalidade não tem onde pousar. Aí a entrega trava, e a explicação que aparece é "o time ficou lento".

Por isso o SAFe recomenda capacidade alocada para habilitador, de forma contínua. É o mesmo raciocínio da dívida técnica, com nome melhor: não é débito a pagar, é pista a construir antes de precisar dela.

Onde isso trava

Na minha visão, a parte mais difícil do pipeline não é técnica. Automação se compra e se aprende.

O que trava é a cultura do CALMR e a capacidade para habilitador. A primeira porque exige que produção deixe de ser responsabilidade de uma área e passe a ser do time que construiu. A segunda porque reservar capacidade para trabalho que não aparece na tela é a coisa mais fácil de cortar quando o trimestre aperta.

E existe um sintoma que revela as duas de uma vez: a frequência de implantação. Organização que implanta a cada dois meses não tem problema de ferramenta. Tem problema de confiança na própria capacidade de voltar atrás.

Na sua organização, quanto tempo passa entre um código estar pronto e ele estar em produção? E qual parte desse tempo é técnica, e qual é espera por aprovação?