リリース管理

リリース管理 プロセスブレード(未翻訳)は、ITソリューションを本番環境へ配備する計画、調整、検証することを含んでいる。リリース管理は、ソリューションを作成するITデリバリーチームと組織の運用ITインフラに責任をもつ人たちの協力を必要としている。「自分で作って、自分で動かす」といったDevOpsの考え(未翻訳)を持っている組織の場合、この人々は同じかもしれないが、この状況下でもリリース管理全体への作業を統制することに責任をもつグループをしばしば見かけるだろう。

この記事は、以下のトピックスによって構成されている。

  • なぜリリース管理か?
  • リリース管理プロセス
  • 他のITチームとのワークフロー
  • リリースマネジメントとDevOps

なぜリリース管理か?

エンタープライズがリリース管理を採用するいくつかの理由がある

  1. 複雑な運用インフラをもっている。運用インフラの複雑さが大きくなればなるほど、本番環境への新機能のリリースが問題を起こすリスクが大きくなり、それゆえリリース管理の必要性が大きくなる。多くの技術があり、それらの技術が異なるバージョン、異なる構成で存在し、ソリューションが他のソリューションと高い関連性をもつとき、運用インフラは複雑になる。理想的には、この技術的負債(未翻訳)は返済すべきである。
  2. 多くのデリバリーチームが並列に働いている。運用インフラとは、共有された環境、より正確に言えば共有された環境がいくつか集まったものであり、複数のITデリバリーチームがその環境へと配備する。デリバリーチームの数が増えるにつれて、リリース作業の衝突が起きる機会が大きくなる。
  3. ITデリバリーチームはソリューションを本番環境にリリースするための手助けを必要とする。ITデリバリーチーム、特に新しいチームは、運用環境へソリューションを配備する経験があまりないかもしれない。リリース管理チームは、効果的なリリース戦略を用いることでITデリバリーチームを指導でき、ソリューションが本運用可能な状態のなるよう確実に導くことができ、リリース作業の計画と調整の手助けができる。

リリース管理プロセス

以下のプロセスゴール図は、ディシプリンドアジャイルリリース管理に関連する潜在的活動を表している。
goal-it-release-management-v2-1-jp

リリース管理を考慮するのに必要なプロセス要因は以下である。

  1. ITリリーススケジュールの計画。組織全体のリリーススケジュールには、計画とコミュニケーションが必要となる。多くの組織では、本番環境に配備することが許されていないブラックアウト期間がある(例えば、多くの小売組織ではクリスマスホリデー近辺に重要でないリリースは許されていないだろう)。リリースをスケジューリングする際に利用できる、リリーストレイン、リリースストリーム、アドホックリリースや、リリースウィンドウなど、多くの戦略がある。
  2. ソリューションのリリースのスケジュール。個々のデリバリーチームの作業のリリースには、同じ運用環境に配備したい他のチームのリリースと衝突しないために、スケジュールが必要となる。
  3. インフラ構成の管理。リリース管理チームは、運用環境の構成管理を行うために、運用チームと密接に連携するだろう。実際、リリース管理チームが、運用チームのメンバーであることはよくある。本番環境へ安全に配備するために、現在本番環境に何があるか、ハードウェアやソフトウェアの要素がどのように相互に依存しているかを知っていなければならない。運用インフラがより複雑になり、ITデリバリチームが増えるほど、このプロセス要因がより重要になる。
  4. 本番配備への用意の決定。リリースプロセスの一部に、ソリューションが配備の準備ができていること、利害関係者が配備する準備ができていることを確認することがある。リリースが大きく、頻繁でないほど、この問題は大きくなる。
  5. デリバリーチームのサポート。リリース管理チームが独立して存在しているとき、彼らはITデリバリーチームと密接に連携し、配備に成功するように手助けをする。この手助けは、チームの配備テクニックの指導、計画や配備自動化のための作業といった形で行われるかもしれない。リリース管理チームは、配備テスト(配備することに成功した後での検証)でしばしば手助けをする。
  6. リリースのガバナンス。組織全体のリリース作業のガバナンスは、理想としては可能な限りそれらの作業を合理化した上で行うべきである。このガバナンスは、適切なメトリクスの特定と収集だけでなく、リリースプロセスに関連する方針とガイドラインの開発を含む。これは、ITガバナンス(未翻訳) 作業の一部分である。

他のITチームとのワークフロー

次の図はリリース管理活動を実行する人が他の人と実行する重要なワークフローの概要を示している。この図の興味深い点の一つは、多くのITデリバリーチームが、リリース管理プロセスにプロダクションレディリリースを与えることである。これらのチームは、異なるライフサイクルに従っているかもしれないし、なかには、ディシプリンドアジャイルライフサイクルの一つをカスタマイズしたバージョンに従っているようなチームであったりする。いくつかの組織では、この作業をする独立したリリース管理チームを持つかもしれない。ディシブリンド DevOps 戦略を適用するような別の組織では、デリバリーチームが「ビルド、リリース、実行」という考え方で、リリース管理作業を自分たちで行うようにしていることもよくある。今のところ、焦点をあてるのは、リリース管理を取り巻く活動であり、それをサポートする潜在的な組織構造に関してではない。

goal-it-release-management-v2-1-jp-external

以下のテーブルは図で表現されたワークフローを要約したものである。

プロセスブレード プロセスブレード概要 リリース管理とのワークフロー
継続的改善(未翻訳)  

軽量で協調的な方法でチームを横断したプロセスと組織構造の改善をどのようにサポートするか言及している。チーム内での改善経験のサポートの仕方や IT部門とのプロセス改善の統制の仕方。

継続的改善の取り組みは、他のチームから得られる、リリース管理を行っている誰もが学ぶことができる改善提案をもたらすべきである。
エンタープライズアーキテクチャ 協調的、進化的調査、潜在的なモデル化に対する戦略や状況に応じた方法で組織のアーキテクチャエコシステムのサポートについて言及している。 エンタープライズアーキテクトは技術ロードマップを作成し、現在の運用環境に反映される。同様に、期待する方向付けを示し、運用環境はそれを目指す。この情報は、リリース管理活動をサポートするための技術戦略を決定するインプットとして利用される。リリースインテリジェンス、すなわちリリース管理活動の指標(本番環境へのリリース数、各リリースの時間/コストや、配備テストの結果など)は、エンタープライズアーキテクトの意思決定プロセスのインプットとなり得る。
ITデリバリー ディシプリンド・アジャイルの流儀でソリューションを開発する方法に言及している。ITデリバリーは、DADフレームワークでサポートされている4つのライフサイクル (基本/アジャイル、アドバンスド/リーン、継続的デリバリー、探索的)に加えて、プログラム管理(未翻訳) ブレード (効果的に大きなチームが従う一つ以上のライフサイクル)を含んでいる。 リリース管理戦略は、組織内の様々な開発・デリバリーチームをサポートできる必要がある。それぞれのチームは、独自の固有な方法で作業する可能性があるため、(存在するならば)リリース管理プロフェショナルは、選択された戦略を反映した方法でチームと連携するために十分な柔軟性を求められる。
ITガバナンス(未翻訳)  

様々なガバナンスの視点の統合、メトリクスの定義、測定の実施、測定のモニタリングとレポーティング、ガイダンスの作成と明文化、役割と責任の定義、組織内のナレッジの共有、ITリスクの管理、そして(EAガバナンスを含む)様々なガバナンスの尽力の調整に対する戦略について言及している。

ITガバナンスチームは、リリース管理活動を行っている人を含め、すべての ITチームに指針を提供する。リリースインテリジェンスは、ITガバナンスチームにリリース管理の尽力の有効性についての洞察をあたえるために提供される。
オペレーション システムの運用やITインフラの発展、オペレーションエコシステムでの変化の管理、災害の緩和、ITオペレーションの統制方法について言及している。 オペレーショングループは、リリース管理の決定を導くために利用されるオペレーションインテリジェンズ(現在のシステムの状態を含む様々な指標)を提供する。 例えば、プラットフォームが現在ダウンしている場合(おそらく、アップグレード中)、利用可能になるまでその環境に配備することをブロックするだろう。リリース管理活動は、オペレーションスタッフがオペレーションインフラの使いやすさを意思決定に使用するリリースインテリジェンス指標を作成する。例えば、様々なプラットフォームに配備するために必要な作業のレベルを知ることに興味があるかもしれない。
ポートフォリオ管理(未翻訳) ITの挑戦が支えるビジネス価値を特定し、潜在的な挑戦を発掘してより詳細に理解し、その挑戦の優先順位づけを行い、挑戦の口火をきり、そのベンダーを管理し、ITポートフォリオを統制する方法について言及している。 組織のポートフォリオ管理の監視活動は、利用可能なリリースインテリジェンスを活用する。

リリース管理とDevOps

リリース管理は、ディシプリンド DevOps 戦略の重要な一部である。すでに述べたように、多くのIT部門はDevOps アプローチを採用してまだ早期であり、有効なリリース管理もまだ早い。これは、リリース管理にどのようにアプローチするかは、DevOpsの採用具合によって変化することを示唆している。例えば、すべてのリリース管理活動でDevOpsが全くされていない場合、ITデリバリーチームとは完全に独立したチームによってリリース管理活動が行われているに違いない。DevOps の考え(未翻訳)を採用する過程で、リリース管理は、ITデリバリーチームとリリース管理チームの間の共同作業となっていく。DevOps戦略を完全に採用した場合、リリース管理は、主としてデリバリーチーム自身によって行われる。

 

オリジナル: Release Management
http://www.disciplinedagiledelivery.com/release-management/
(翻訳 東 勲)

Pocket