Day 2: DevOps: ソフトウェア・デリバリー・パイプラインをもっと使いこなす

2020/9/5 - 読み終える時間: ~1 分

Day 2 DevOps : Getting more out of your software delivery pipeline の翻訳版です。

Day 2: DevOps: ソフトウェア・デリバリー・パイプラインをもっと使いこなす

2020年9月4日

著者: Nick Mathison / Value Stream Manager

多くのチームの DevOps の起源は、2つの方法のいずれかで始まった。最初のシナリオでは、製品のリードやマネージャーがカンファレンスから戻ってきて、突然「 DevOps が必要だ！」と主張し、「すべてを自動化する」というマントラを唱える。もう1つのシナリオでは、不正な開発者が手動インストールの繰り返しに飽きてしまい、自分の悩みを自動化することにした場合です。どのようなアプローチであっても、数ヶ月後には、これらの開発チームは、複数のツール、チーム、依存関係にまたがる行き当たりばったりの自動化の上で日々運用されています。さらに、ログイン認証情報、アプリケーション、実行中のプロセス、成功したか失敗したかのログを解釈する能力が必要なので、デプロイメントタスクを実行する方法を理解しているのは、チームの一部の人だけです。

これらのツールを毎日使用していない限り、単純な質問にすぐに答えることは不可能です。"本番ではどのバージョンが使われているのか？今日のCI/CDの世界では、開発者はパイプラインに目を向けて、一貫性のない自動化された世界に構造を提供し、これらの単純な質問に答えるのを助けようとしています。しかし、パイプラインを深く掘り下げていくと、その答えは全体像のほんの一部に過ぎません。

最も単純な形では、パイプラインはアプリケーション・ディストリビューションと、意図されたホストである環境の交差点です。提示されたインベントリは、新しいバージョンがビルドされ、デプロイされると、左から右へ、パイプラインを通って、環境から環境へと移動します。しかし、毎日の複数の CI ビルドのおかげで、何時間も離れて行われるビルドの違いを見分けることができなくなりました。自動デプロイに暗号化されたバージョンを乗算すると、今では無意味なバージョンがあちこちに存在しています。したがって、以下のようなより深い質問に答えるのに役立つ、より高度なパイプラインが必要になります。"本番環境ではどのような変更が行われているのか」、「変更されたバージョンはどのように本番環境にデプロイされたのか」など、より深い質問に答えるのに役立つ、より高度なパイプラインが必要です。このような知識があれば、問題のある変更が発生したときに素早くピンポイントで特定し、問題のあるバージョンをデプロイ前に停止させることができます。幸いなことに、HCL Accelerate は、パイプライン全体にわたってより深い可視性と厳格なガバナンスを提供するように構築されています。その方法をお見せしましょう

パイプラインの構築

始めるために、コードから一歩引いて、候補となるアプリケーションとその関係者を特定します。CI サーバーから始まり、最終的に顧客の手に渡るまで、ビルドされた成果物の移動を支援する個人を含めたいと考えています。これらの利害関係者には、開発、運用、テスト、パフォーマンスエンジニア、リリースマネージャ、テクニカルサポートなどが含まれます。これらのリソースを特定したら、以下の2つのパートのアジェンダで約2時間のセッションを行うために、これらのリソースを集めてください。

まず、以下の 3 つのリストを作成し、既知のすべてのパイプラインコンポーネントを特定します。

• 開発、テスト、本番、リリースの観点から、アプリケーションのデプロイをサポートするために、どのような環境がアップグレードされ、保守されているか？(注: これらの環境は、必ずしもアプリケーションをホストしているとは限りません。パフォーマンスや統合のためなど、適切なテストを行うために、セカンダリインスタンスが必要になることがよくあります。)
• これらの環境を更新するために、どのような手動または自動化されたプロセスを使用していますか？
• リリース前に、どのようなリリース要件、マイルストーン、サインオフをすべてのバージョンで取得しなければならないか？

次に、この情報を手にして、典型的なバリュー・ストリーム・マッピングの手法を使用して、アプリケーションのパイプラインのフローチャートを構築してください。ホワイトボードを使うのが最も一般的ですが、オンラインのエンティティ関係図ツールでも問題ありません。このモデルでは、環境（#1）、プロセス（#2）、および要件（#3）は、それぞれバブル、入力、および出力で表されます。すべての利害関係者が各コンポーネントの配置に満足したら、HCL Accelerateのパイプラインにきれいにトランスポーズするための明確なアクションプランを持って会議から退散することができます。

余談ですが、様々なエンティティのパターンやグループ化は、パイプラインマッピングプロセスの副作用として認識されていた可能性が高いです。例えば、順次デプロイするのではなく、複数の環境を同時にデプロイすることができます。あるいは、環境ごとに1つの自動化スクリプトを使用するのではなく、1つのスクリプトを複数の環境で再利用することができます。あるいは、リリース要件を左にシフトして、無駄なテストを防ぐことはできませんか？これらのアイデアは、CI/CDパイプラインを最適化し、技術的な負債を減らすために重要ですが、それぞれのリストが変わるたびにパイプラインは進化し続けます。いずれにしても、シンプルなパイプラインを採用することは、開発のエンパワーメントを向上させるための大きな一歩であり、パイプラインには柔軟性を期待すべきです。

提供されるパイプライン戦略は、実装を容易にするために焦点が絞られています。完了すると、チームは「すべてを自動化する」という DevOps のマントラをようやくコントロールできるようになったとマネージャーに警告することができ、自信を持って「どのバージョンが本番であるか」という質問に答えることができるようになる。しかし、それはより大きな DevOps の旅の1日目に過ぎない。どのチーム・メンバーでもパイプラインの中のより深い問題を正確かつ迅速に特定できるようになる2日目の課題を解決するために、パイプラインはどのように役立つのでしょうか？

幸いなことに、HCL Accelerate は、先に述べた挑戦的な Day 2 の質問に答える準備ができています。これまでCI/CDツールについてのみ説明してきましたが、チームは、無料のソースコントロールと課題追跡プラグインを利用することで、バージョン、計画された作業、および計画されていない作業の間で点を結びつけることができます。この関係性により、チームは「本番ではどのような変更があるのか」という質問に明確に答えることができます。さらに、当社のパイプラインのデプロイ計画は、監査とトレーサビリティを通じて、「変更バージョンはどのように本番環境にデプロイされたのか」を説明することができます。そして、より厳しい、あるいはより緩い制御が必要な場合には、当社の堅牢なゲーティングシステムを利用して、パイプラインを流れるバージョンを管理します。Day 2の課題は、HCL Accelerat eの無料の Community Edition で反復的に解決することができます。今すぐダウンロードするにはここをクリックしてください