Reuniões causadas por deploys lentos (2015)

Deploys lentos causam reuniões

• O design de software é um exercício de relacionamentos interpessoais. O mesmo vale para outras habilidades usadas no desenvolvimento de software.
• A reclamação de que há tantas reuniões a ponto de não conseguir fazer deploy do código pode ocorrer por causa da limitação de capacidade de deploy.
• Chuck Rossi observou no Facebook que o número de mudanças que pode ser tratado em um único deploy é fixo. Se quisermos mais mudanças, precisamos de mais deploys.
• O Facebook aumentou a velocidade de deploy nos últimos cinco anos de semanal para diária e, em seguida, para três vezes ao dia, enquanto o ciclo de deploy de apps móveis foi reduzido de 6 para 4 e depois 2 semanas.
• “Mudanças por deploy” é uma métrica inflexível: melhorias são possíveis, mas levam tempo. Quando o número de mudanças ultrapassa o limite atual, é preciso reduzir a quantidade de mudanças.
• Aumentar a sobrecarga organizacional inicia um ciclo de feedback positivo: menos trabalho -> mais pressão -> mais erros -> menos mudanças por deploy -> mais sobrecarga -> menos trabalho.
• Para processar mais mudanças, é preciso aumentar a capacidade de deploy. Isso pode ser feito reduzindo o ciclo de deploy ou aumentando as mudanças por deploy.
• As tentativas de reduzir a sobrecarga acabam, em última análise, se traduzindo em reuniões. Isso impede a tentativa de fazer deploy de código em excesso.

Software Design: Tidy First?

• O design de software é um exercício de relacionamentos interpessoais. Melhorar o domínio técnico é uma forma de melhorar relacionamentos.

[roxie]

Achei muito boa essa opinião.

[GN⁺]

Opinião do Hacker News

• Melhorar os testes e características organizacionais para reduzir o risco de implantação é importante, mas não é a única abordagem

  • Reduzir a quantidade de mudanças por implantação é mais eficaz
  • Ao implantar mudanças pequenas com frequência, é possível entregar valor mais rapidamente e experimentar falhas menores
  • Combinado com implantação canário e rollout gradual, implantar deixa de ser um grande risco
  • Pesquisas da DORA, e os livros Accelerate, The Phoenix Project e The Goal apoiam essa abordagem

• Tentando explicar o conceito de "alfabetização em software"

  • Refere-se à capacidade de uma empresa operar por meio de código
  • A organização tem baixa alfabetização em software quando os tomadores de decisão não focam no código
  • A empresa precisa operar com novas abordagens

• Decidiu-se focar em recuperação depois que o tempo de teste no pipeline de CI ficou longo

  • Simplificou os testes e focou em recuperação, usando implantação canário como estratégia
  • Essa abordagem foi uma experiência nova

• As organizações podem atrapalhar melhorias de implantação

  • Enfrentar burocracia é impossível na maioria das organizações
  • Implantação lenta é um problema, mas não o único problema

• Há aumento de testes por medo de mudanças grandes

  • Há uma tendência de a reunião se tornar o objetivo
  • Há necessidade de orientação sobre como conduzir mudanças técnicas e de gestão por parte de não técnicos

• Pergunta sobre por que o CloudFormation é lento

• Microsserviços permitem escalar horizontalmente a frequência de implantação

• O desempenho de software, ou seja, o desempenho humano, é importante

  • Testes automatizados rápidos são necessários para iterações rápidas e redução de risco

• Implantações rápidas provocam reuniões de resposta a incidentes