パイプライン駆動型組織 - 真の継続的デリバリの実現

原文(投稿日：2019/07/19)へのリンク

導入

Netflix、Amazon、Googleなどの企業のスピードと俊敏性で作業し、1日何回も本番コードに変更をデプロイするには何が必要でしょうか？

多くの中堅企業や大企業が失敗するのはなぜでしょう？

真の継続的デリバリを実現するには何が必要でしょうか？

違いは、もちろん、すべてのソフトウェアの問題と同様に、人です。より具体的には、人がパイプラインでどのように作業するかです。パイプラインに設定した期待により、どの程度、パイプラインが真の継続的デリバリを実現できるかが決まります。

パイプライン駆動型のカルチャにはパイプラインとカルチャの両方が必要です。それでは、パイプラインから始めましょう。

パイプライン

パイプラインは、結果を生成するために特定の順序で実行される1つ以上の自動化されたタスクまたは「ジョブ」のセットです。通常、この結果は次の2つの要素で構成されます。

• 判断結果：パイプラインが合格、失敗、または決定的でない結果を出す（常に「失敗」/「合格」を使用し、決して「決定的ではない」は使用しません。この本の後半でその理由を説明します）。
• 関連するアーティファクト：デプロイされたアプリケーション、バイナリ、ログファイル、またはその他の重要なもの。

タスク

中心となるのは、タスクはコマンドライン（シェル）スクリプトまたはプログラムであり、一部のマシン（ローカルまたはクラウド）で自動的に実行され、特別なコマンドライン「終了コード」を返します。ただし、一部のタスク（場合によっては、コンパイル、テストの実行などの相互に関連する多くのタスク）は除きいます。

成功を示すときに、コマンドラインでゼロの終了コードを持つことは一般的です。ゼロ以外の終了コードは、成功しないことを示します。プログラムまたはスクリプトが終了コードを決定します。

CI/CDサーバ

Jenkinsなどのツール（口語では、「継続的デリバリ」のための「継続的インテグレーションサーバ」、または「CI/CDサーバ」と呼ばれます）は、これらのタスクの上の抽象化レイヤーとして機能します。CIサーバを使用すると、これらのタスク（特別なコードコミットトリガーまたはスケジュールに基づく）を簡単に実行し、タスクの終了コードとその出力（ログ）をリッスンできます。
その後、ログを解析し、結果、エラーログ、およびすべてのアーティファクトを表示する優れたUIを提供します。
CI/CDサーバを使用すると、1つの場所でタスクを管理し、実行の進行状況を監視し、タスクを並行して実行し、異なるマシン（「ビルドエージェント」と呼ばれることもあります）で実行できます。

パイプライン駆動

「パイプライン駆動」は、パイプラインにますます依存して、コードとそれに紐づくアーティファクトに関連する技術的な判断（ジャッジメント）を行い、その判断に基づいてパイプラインをできるだけ自律的に動作させたいということを意味します。

ソフトウェア開発では、2つの異なるタイプの「決定」を認識できます。人々は通常、次のことをしなければなりません。

• 次のような戦略的判断
  • 「この製品を構築する必要がありますか？」
  • 「この機能に注力する必要がありますか？」
• 次のような戦術的な判断
  • 「このブランチをマージしますか？」
  • 「この環境にデプロイする必要がありますか？」
  • 「環境をスピンアップ/破壊する必要がありますか？」
  • 「機能は動作していますか？
  • 「アプリは安全ですか？」
  • 「新しいバグを生みましたか？」

パイプラインは戦術

パイプラインは戦術的な日々の判断と行動に適しており、人々は戦略的な判断と行動に優れていると思います。誰かがパイプラインで、もし、誰かが、人間がサインすることなく次の製品を決定する方法を見つけるなら、私はそれを楽しみにしています。しかし、それは決定アルゴリズムをコーディングできるものではないと思っています。

戦術は通常、マシンのチェックに非常に適しています。ステップをスキップせずに反復的に物事を行い、一連のチェックリストを検証し、データを収集および分析して特定の数値を取得します。
これらの決定は次のようなものに関連しています。

• コードの健全性と機能
• 環境
• 品質
• セキュリティ
• コンプライアンス
• 操作
• デプロイ

...およびソフトウェア開発ライフサイクルに関連するその他の事項。

（従来のアジャイルおよびウォーターフォール組織で通常行うように）パイプラインに人の代わりに、これらの判断をさせることにより、いくつかの利点があります。

• より迅速な決定/判断が行われる
• より信頼性の高い反復決定
• ストレスの軽減
• 真の継続的デリバリの実現

より迅速な判断

人間の代わりにパイプラインを使用して意思決定を行う方が速いのには、主に2つの理由があります。

1. コンピューターは特定の事実に基づいて人間よりも高速に計算します
2. コンピュータは、ブランチをマージするか、環境をスピンアップあるいはアプリケーションをデプロイするかを決定しようとしているときに、ストレスや不安、または差し迫った運命の感覚を感じることはありません

より信頼性の高い反復的な判断

なぜパイプラインを使用して意思決定を行う方が、反復的な作業に対してより信頼性があるかについて、2つの主な理由があります。

1. コンピューターは、1つのアイテムを忘れたり、毎回異なる方法でチェックしたりすることなく、長いリストを調べて、それぞれを検証するのに優れています
2. コンピューターは、特定のチェックが過去10回失敗したために退屈、不快感、または誰かを窒息させる衝動を感じることがありません。また、なぜ誰もそれについて何もしていないのだろうと考えたり、「もういいや、子供たちと一緒に時間を過ごそう」と思うこともありません。

ストレスと不安の軽減

長くて困難な手動テストプロセスがある会社に行って、リリース前に1つの特別な会議が行われ、リーダーシップチームがテストチームの進捗を見るのは本当に不安です。「このリリースは進めていいですか？」
テストリードを見ることは常に人間の心理学の教訓になります。メジャーリリースをプロダクションにプッシュする承認を得なければならなかった場合、あなたが世界と全員のコードとの間の最後の防衛線だったとき、どう思いますか？

真の継続的デリバリの有効化

最終的に、私たちはその中心になります。

継続的デリバリは、チームが短いサイクルでソフトウェアを作成し、ソフトウェアをいつでも確実にリリースできるようにするソフトウェアエンジニアリングアプローチです。

継続的デリバリで成功するための鍵は、人間のボトルネックを戦術的な意思決定の連鎖から取り除き、パイプラインがコードを決定およびプッシュして、本番環境に至るまでほぼ自律的に動作できるようにすることです。パイプラインには、人が感じる恐怖や疑いがなく、コードの振る舞いについての迅速なフィードバックを受け取ることができます。

パイプラインに動き方を教える

パイプラインを十分に信頼し、その決定に頼ることができるようにするには、プロセスに人間がいなくても戦術的な判断ができるようにソフトウェアパイプラインに教えることを開始する必要があります。パイプラインに教えることができる戦術上の決定はすべて、真の継続的デリバリへの道で人間のボトルネックが少なくなることです。

教えるということは、自動化されたステップ、スクリプト、品質ゲートをパイプラインに追加することを意味します。それにより、必要なさまざまな結果や指標に基づいて、さまざまな手順が失敗したり合格したりするさまざまなステップが作られます。これにはいくつかの種類があります。

• 自動テストの結果に基づいた不合格/合格
• 測定中の特定のメトリックに基づいた不合格/合格（コードカバレッジが大幅に低下）
• サブまたはパラレルパイプラインの結果に基づいた失敗/合格
• ログファイルに基づく失敗/合格
• （BETAの読者はアイデアがあればメールしてください[roy at osherove.com]）

Netflix、Google、Amazonなどの領域は、パイプライン駆動型であると説明できます。チームのパイプラインが日々の戦術的な判断を行い、関連するアクションを、人が判断する代わりに自動的に実行できるようにします（NetflixおよびWazeでSpinnakerを使用した大規模な継続的デリバリ（Cloud Next '18））。

彼らは、実行された作業の分ごと、時間ごとの戦術的な判断で人が統制を握っているという概念を手放し、パイプラインに進歩を促します。その後、人々はパイプラインに戦術的な決定を自動的に判断して行う方法を教える人となり、多くの戦術的なプロセスからボトルネックとしてのヒューマンファクターを取り除きます。

パイプライン駆動フローが日々の仕事の原動力をどのように変えるか

従来（パイプライン駆動ではない）、パイプラインは、すべてが問題ない（テストに合格し、コンパイルに合格した場合）かどうかを「尋ねたり」、「通知」します。 次に、次のステップが実行可能かどうかの判断に基づいて、ボタンを押して別のパイプラインまたはジョブをトリガーする必要があります。

画像: 従来のアジャイルパイプラインは、SDLCプロセスで次のパイプラインをトリガーするかどうかを判断するために、知識のサイロと人間の判断によって分離されている

パイプライン駆動型フローでは、人がパイプラインを十分に信頼しているため、すべてが正常であれば、次のステップが自動的にトリガーされます。前提として、パイプラインは、何かがOKかどうかを適切に判断する方法をパイプラインが知っており、人間が次のパイプラインまたはジョブをトリガーするのを待たずに、次のアクションを続行するだけです。

上の図では、組織内のさまざまな知識サイロが、自動化されたパイプライン内に決定ロジックを埋め込む役割を果たしていることがわかります。決定はパイプライン実行の一部として自動的に実行され、次のアクションを承認または続行するために「外側」の人間を待つ必要はありません。

新しい世界のための新しいスキル

アジャイルプロセスを採用しようとするときに通常遭遇する4つの主なサイロを見ると、この画像から、それぞれが価値のあるスキルを持っており、他のサイロが学習するのに関連していることがわかります。

1. 開発スキル：パイプラインは自動的に実行されるコードの一部であるため、パイプライン関連の主なスキルは基本的なコーディングテクニックを学ぶことです。完全な自動化インフラストラクチャの単純なスクリプトであっても、何もコーディングできない場合、パイプラインに貢献したり、パイプラインがどのように機能し、失敗するのかを理解したりすることはできません。
2. テストスキル：パイプラインは（すべてのパイプラインは本当に）1つの大きなテストです。赤または緑です。「ステップ」で構成されています。各ステップは、それ自体がテストの形式です。失敗した場合、パイプラインは失敗します（通常は）。パイプラインに貢献するとは、パイプラインにステップまたはテストを追加することを意味し、それらのテスト/ステップはコードで記述されます。したがって、コーディングの方法を知る必要があるだけでなく、パイプラインで実行できるテストを記述する方法を知る必要があります。テストに対する考え方が必要です。手動で何かをチェックする代わりに、自動化されたテストを思い描いて作成することができます。
3. 運用スキル：中規模および大規模企業のパイプラインは、従来、運用および開発者の領域にありました。しかし、人がパイプラインでテストすることを期待する場合、パイプラインが基本レベルでどのように機能するか、どのように出力を理解するか、どのようにそれらを構成するか（ステップを追加および削除する）、どのようにそれらにアクセスするか、どのようにそれらを実行するかを知る必要があります。
4. セキュリティスキル：セキュリティは、コード、インフラストラクチャ、構成、デプロイのすべての側面に関係する一連のスキルと考え方です。これは、従来、自分のサイロに住んでいたセキュリティ担当者がセキュリティの知識を共有する必要があることを意味します。なぜなら、この新しい勇敢な世界では、誰もがより多くの力、したがってより多くの責任を持っているからです。誰でもパイプラインに触れて、そこで実行されるコードを書くことができます。これは、彼らが触れるすべてに対してセキュリティについてどのように考えればいいかを彼らに教えることを意味します。

このリストに、より多くのスキルを追加できますが、物事を適切な長さに保つために、ここで止めておきます。私のブログでこれらのそれぞれについて、より広範囲に説明します。

画像: 各ナレッジサイロについて、他のサイロに関連するスキルのどのセットを今後改善する必要があるかを（色付きのドットで）ハイライトしました。  

まとめ: あなたにとってそれは何か？

好むと好まざるとにかかわらず、パイプラインはますます一般的になりつつあり、パイプライン駆動型になる必要性はますます競争力を高めるために増加します。
つまり、知識の共有、自動化、テスト、コード記述の能力により、次の仕事で成功する可能性が高まります。そして、それらのスキルのakcにより、このような世界でうまくプレーできる可能性が低くなります。

多くの組織は、継続的インテグレーションまたは継続的デリバリを実装しようとしていますが、プロセスに行き詰まっています。パイプライン間に存在する人間のボトルネックが多すぎて、ソフトウェアプロセスの次のステップ（デプロイ、テストなど）に進むことができるかどうかを決められません。

より良い意思決定を行うようにパイプラインを指導し、人間の判断をパイプラインにオフロードすることで、パイプラインに本番までの意思決定を任せることができます。したがって、（それが継続的に実行される場合）それらが真の継続的デリバリメカニズムを作成できるようになります。

パイプラインが失敗した場合、デプロイはありません。合格した場合、デプロイします。人間は関与しません。

それは、今日、ほんの一握りの企業のみが全面的に採用しているビジョンです。Amazon、Netflix、Google、その他いくつかの企業です。そして、私はそれが彼らをそのスケールとスピードに導いたマジックの一部であると主張します。彼らは戦術的な決定プロセスから人間を除き、代わりに彼らに仕事をするためにパイプラインを教える方法を彼らに教えました。

これらのパターンの詳細については、パイプライン駆動型組織に関するRoyのブログまたは彼のTwitterページをご覧ください。

著者について

Roy Osherove氏は近々発売される本「 Pipeline Driven」の著者です。彼は「Elastic Leadership：Growing Self Organizing Teams」と「The Art of Unit Testing」の著者でもあります。Osherove氏は、世界の大企業のいくつかでソフトウェア開発の領域で働いてきました。現在、彼はフリーランスのコンサルタント兼トレーナーであり、テスト駆動開発、アジャイルテクノロジーリーダーシップ、継続的デリバリ、パイプラインベースの組織の効果的なメトリックなどのトピックについて世界中の企業を指導しています。Osherove氏のブログはこちらで読むことができ、彼についての詳細はこちらをご覧ください。