デプロイの遅さが会議を生む（2015）

デプロイの遅さが会議を引き起こす

• ソフトウェア設計は人間関係の練習である。ソフトウェア開発で使う他の技術も同様だ。
• 「コードをデプロイする暇がないほど会議が多い」というエンジニアの不満は、デプロイ容量の上限のために起きている可能性がある。
• チャック・ロッシはFacebookで、1回のデプロイで処理できる変更点の数が固定されていると観察した。より多くの変更が必要なら、より多くのデプロイが必要になる。
• Facebookは過去5年間で、デプロイのペースを週1回から毎日、1日3回へと増やしており、モバイルアプリのデプロイサイクルも6週間から4週間、2週間へと短縮している。
• 「1デプロイあたりの変更点数」は非弾力的な指標であり、改善は可能だが時間がかかる。変更点数が現在の閾値を超えると、変更点数を減らさなければならない。
• 組織的オーバーヘッドを増やすと、正のフィードバックループが始まる: 作業量の減少 -> プレッシャーの増加 -> ミスの増加 -> 1デプロイあたりの変更点数減少 -> オーバーヘッド増加 -> 作業量の減少。
• より多くの変更点を処理するためには、デプロイ容量を増やす必要がある。デプロイサイクルを短縮するか、1デプロイあたりの変更点数を増やす方法がある。
• オーバーヘッド削減の試みは、最終的に会議へつながることがある。これは、過剰なコードをデプロイしようとする試みを抑制する。

ソフトウェア設計: Tidy First?

• ソフトウェア設計は人間関係の練習である。技術を磨くことは、関係を改善する方法の1つである。

[roxie]

この意見はいいですね

[GN⁺]

Hacker Newsコメント

• デプロイのリスクを下げる方法としてテストと組織の特性を改善することは重要だが、唯一のアプローチではない

  • デプロイごとの変更数を減らす方が効果的だ
  • 小さな変更を頻繁にデプロイすれば、より早く価値を届けられ、小さな失敗を経験できる
  • カナリアデプロイと段階的ロールアウトを組み合わせれば、デプロイはもはや大きなリスクではない
  • DORAの研究、書籍『Accelerate』『The Phoenix Project』『The Goal』がこのアプローチを支持している

• 「ソフトウェアリテラシー」という概念を説明しようとしている

  • 会社がコードで運営できる能力を意味する
  • すべての意思決定者がコードに注目しないと、ソフトウェアリテラシーが不足していることになる
  • 会社や製品は新しい考え方で運営できる必要がある

• CIパイプラインでテスト時間が長くなったため、リカバリに注力することにした

  • テストを単純化し、リカバリに集中するためデプロイ戦略としてカナリアを使用した
  • このアプローチは新鮮な経験だった

• 組織はデプロイ改善を阻害する可能性がある

  • 官僚主義と闘うのは、ほとんどの組織で不可能に近い
  • デプロイが遅いことは問題だが、唯一の問題ではない

• 大きな変化への恐れからテストが増える

  • 会議がゴールになりがちだ
  • 非技術系マネジメントと技術的変化を主導する方法について、アドバイスが必要

• CloudFormationが遅い理由に関する質問

• マイクロサービスはデプロイ頻度を水平に拡張できる

• ソフトウェアのパフォーマンス、つまり人間のパフォーマンスが重要

  • 高速な反復とリスク低減のため、テスト自動化を高速化する必要がある

• 高速デプロイはインシデント対応会議を引き起こす