決定版メディアライブラリ
リリース管理プロセスにおける決定版メディアライブラリとCMDB

最終版メディア ライブラリは、組織の最終版の承認済みバージョンのソフトウェア メディアが保存され、保護されている安全な情報技術リポジトリです。組織が新規または変更されたアプリケーション ソフトウェアを運用環境にリリースする前に、そのようなソフトウェアは十分にテストされ、品質が保証されている必要があります。最終版メディア ライブラリは、展開準備が整ったソフトウェア オブジェクトの保存領域を提供し、適切な品質保証チェックに合格した管理されたソフトウェア メディア構成アイテム(CI) のマスター コピーのみを格納する必要があります。これには通常、調達されたアプリケーションと特注のアプリケーション、ゴールド ビルドのソース コードと実行ファイルが含まれます。ITIL [1]ベスト プラクティス フレームワークのコンテキストでは、最終版メディア ライブラリという用語は、ITIL v3 より前のバージョンで参照されていた最終版ソフトウェア ライブラリという用語に取って代わります。

構成管理データベース(CMDB)と組み合わせることで、データ センターのDNA 、つまりインストールと構成の CMDB レコードに接続された すべてのアプリケーションおよびビルドソフトウェアメディアを効果的に提供します。

決定的なメディア ライブラリは、組織のリリースおよびプロビジョニング フレームワークとサービス継続計画の主要コンポーネントです。

背景

管理されたIT環境では、承認されたバージョンのソフトウェアのみが本番環境に導入されることが極めて重要です。承認されていないソフトウェアバージョンが本番環境に導入された場合、深刻な事態を招く可能性があります。成熟した組織では、通常、このような事態を防ぐための厳格な変更管理およびリリース管理プロセスが存在します。しかし、こうしたプロセスには、承認されたソフトウェアバージョンを安全に保存し、アクセスできる場所が必要です。ITIL第3版で提案されたソリューションは、決定的メディアライブラリ（DML）と呼ばれています（バージョン2で以前は決定的ソフトウェアライブラリ（DSL）と呼ばれていました）。ITILでは、DMLは物理ストレージまたは仮想ストレージのいずれかで使用できると提唱されており、どちらの方法にも利点と欠点があります。しかし、DMLソリューションの成功には重要な要素があることは明らかです。つまり、本番環境に導入する必要があるソフトウェアは、厳密にテストされ、動作が保証され、ライセンスが付与されている必要があり、安全かつ一貫して導入できるようにパッケージ化されている必要があります。また、DMLには、承認されたユーザーのみが簡単にアクセスできる必要があります。このように、仮想 (電子) ストレージ領域は、ほとんどの場合に優れたソリューションを提供します。つまり、DML を集中管理して、必要に応じてリモートまたは通常の営業時間外にアクセスできるようになります (配布を参照)。

範囲

DMLは開発フェーズから本番フェーズへの移行をサポートする上で重要な役割を果たします。DMLソリューションは、開発フェーズまたはソフトウェア進化フェーズをサポートするソフトウェア構成管理またはSCM（ソフトウェア変更および構成管理と呼ばれることもあります）などの他のソフトウェアおよびソースコードリポジトリと区別する必要があります。これは重要な区別であり、しばしば混乱を引き起こします。本質的に、SCMツールまたはリポジトリは、最終的に承認された製品までのすべての開発バージョンとコード（または作業成果物）のリビジョンを保存および管理しますが、DMLはコードまたは製品の最終的に承認されたバージョンのみを保存します。これは、製品が設計会社から工場、倉庫、そして店舗へと移動する、つまり、 実店舗の製品ライフサイクルに似ています

  • 製品の設計、開発、製造方法に関する記録（メタデータ）が保存されます。これにより、品質管理中やその後のサービスにおいて欠陥製品が発見された場合、どのプロセスに問題があるかを追跡することが可能になります。
  • ソフトウェアがDMLから本番環境にインストールおよび展開された場所に関する記録（メタデータ）は、構成管理データベースに保存されます。各インストールまたは展開は、対応する本番環境変更要求によって承認され、その結果生じた変更は、DMLアーティファクトとそれが展開されたプラットフォームとの関係として構成管理データベースに記録されます。

より成熟した、または進化した状態では、2 種類の構成管理形式の間に区別はなく、プロセスはサービス提供とサービス運用のライフサイクル全体を継続的にサポートします。これは、エンタープライズ構成管理と呼ばれています。ただし、この場合でも、開発ベースの成果物は、展開可能な品質保証された最終的なマスター バージョンの管理とは区別して分離しておく必要があります。アウトソーシングまたはマルチベンダー契約では、一貫性があり安全な形式のサプライヤー アクセスの有無によって、ソフトウェア構成管理が受動的に実行されるか (サプライヤーが独自の SCM ツールを導入して完成品を納品する外部)、能動的に実行されるか (サプライヤーが中央でホストされた SCM ツールを利用して内部で監視) が決まります。ただし、承認された展開可能な形式のすべての完成品 (アプリケーション ソフトウェア) は、中央の DML 内に保存する必要があります。

DML が保存する一般的な CI には次のようなものがあります。

  • パッケージ化された社内アプリケーションソフトウェア
  • 市販の既製品（COTS）生メディア
  • カスタマイズされた COTS ソフトウェア (拡張機能、カスタマイズされた構成などを含む)
  • リリースパッケージ
  • パッチ（パッチ（コンピューティング）を参照）
  • ゴールド ビルド (クライアント、サーバー、ネットワーク、ストレージ デバイスなど)
  • システムイメージ
  • 複数のテクノロジースタックとディストリビューションテクノロジー（例：Wintel、UNIX、ORACLE、メインフレーム、ネットワーク、ストレージなど）

メディアリリースライフサイクル

（上記の「リリース管理プロセスにおける最終的なメディアライブラリと構成管理データベース」の図を参照）

メディア リリース ライフサイクルの手順は次のとおりです。

  1. 新しいサービスや製品に対する需要が生じます。
  2. 要件トレーサビリティツールから抽出された機能要件に基づいて、製品（サービス、ビルド、またはアプリケーション）の製造または購入が決定されます。製品は、アーキテクチャ設計ポリシー（サービス設計）に従って、サービス/製品カタログから作成または選択されます。COTS製品は調達され、資産ステータスが「調達済み」としてDMLに保存されます。新規の場合、製品は承認済み製品カタログに追加されます。社内で作成されたアプリケーションのソースコードは、ソフトウェア構成管理リポジトリで直接管理されます。
  3. COTS 製品またはゴールド ビルドがパッケージ化されている場合、メディアは DML から抽出されます。
  4. 製品はパッケージ化されるか、開発されてパッケージ化されます (この場合、アドオン機能は社内アプリケーションおよびビルドと同じように扱われます)。
  5. スタブ レコードまたは元のベースラインは、ソフトウェア構成管理ツールで作成されます。
  6. 開発コードのリビジョンとパッケージのリビジョンは、開発全体を通じてソフトウェア構成管理ツールに記録されます。
  7. ユニットテストが実行されます。
  8. パッケージ化が完了し、リリース パッケージが作成されます。
  9. 製品パッケージは品質が保証されています (テスト、ステージング、および再作業を含む)。
  10. 完了したメディア パッケージ (ビルド、サービス、またはアプリケーション) は、展開の準備が整った承認済みメディアとして DML に戻されます。
  11. 変更管理の承認後、適切な配布システムを介して製品が資産にリリースされ、論理インストールは CMS (CMDB) に適切なプロセスで記録されます。
  12. DML エンティティは次の場合にすぐにアーカイブされます。
    1. CMSまたはCMDBは、パッケージ化されたリリースがどの場所でも使用されなくなったことを示します（必要な回帰を可能にするために、最後の廃止またはアップグレード後に猶予期間が必要です）。
    2. DMLエンティティは、選択可能な項目として技術カタログまたはユーザー（サービス）カタログから削除されました。

配布

メディアの正規の保管場所としてのDMLはある程度の集中化を意味しますが、グローバルモデルを実現するにはローカルメディアライブラリ（LML）が必要になります。これにより、グローバルネットワークを介した継続的なダウンロードを回避することで、メディアの物理的なインスタンスのリリースと展開を国内でタイムリーに実現できます。非プライムウィンドウでの正規メディアの複製により、必要なパッケージを必要に応じてローカルで利用できるようになりますが、プロセス制御上の理由からDMLは「マスター」として残ります

DML/LML階層は、多くの配布技術やパッケージ管理システムに見られるマスター/セカンダリ配布層と同義です。配布ツールは特定のテクノロジースタック（Wintel、Unix、メインフレームなど）に偏りがちですが、DMLの主な利点の一つは、テクノロジーに依存しない性質と、承認されたすべてのソフトウェアを真に一元的に保存できることです。このように、配布ツールはDMLに接続してソフトウェアパッケージを取得します。アプリケーションのパッケージ化には、自動展開を目的とした標準的かつ構造化されたソフトウェアインストールの準備が含まれます。市販の（COTS）ソフトウェアにもパッケージ化は必須です。パッケージ化により、特定のプラットフォームまたは環境で効率的に動作するようにソフトウェアを構成できるためです。このプラットフォームにわずかな変更（ディスクの交換など）があっても、パッケージが正常に展開されない可能性があります。そのため、ソフトウェアの生のメディア（ISO）バージョンを保持しておくことは非常に重要です。これは、オペレーティングプラットフォームのアップグレードや交換などにより、パッケージ化されたバージョンが展開できなくなった場合（多くの場合、緊急時）に必要となるためです。

利点

DMLは以下をサポートします。

  • リリースおよびデプロイメント管理の基盤として、またリリース可能なすべてのデプロイメントパッケージの中央ストレージ領域として機能します
  • サービス復旧および災害復旧手順で使用するために、すべてのパッケージ化されたアプリケーションと生のメディアのソースを提供することにより、可用性とサービスの継続性を実現します。
  • ゴールドビルドの保存による自動サーバープロビジョニングと合理化
  • COTSソフトウェアライセンス提供に関するメタデータレコードとライセンスキーを提供することで、資産管理を実現します。メディアインスタンスと承認済みメディアセットをライセンスおよびライセンス条件と共に保存することで、ソフトウェア割り当ての最適な管理と、サーベンス・オクスリー法およびBSAの推奨事項に基づく外部コンプライアンスを実現します。
  • 単一ユーザーのクライアントエンド製品リクエスト、または既存のマルチユーザー サービス/アプリケーションを他のホスティング ロケーションに展開するための繰り返しリクエストの観点から、カタログ化されたリクエストの実現。

参照

参考資料

  1. ^ シャーリー・レイシー、アイヴァー・マクファーレン（2007年）『ITILサービス移行』The Stationery Office. ISBN 978-0-11-331048-7。
  • http://wiki.en.it-processmaps.com/index.php/ITIL_Glossary
  • http://www.itsmwatch.com/itil/article.php/3887361/How-to-Set-Up-and-Manage-a-Definitive-Media-Library.htm 2011年12月17日アーカイブ（Wayback Machine）
  • [1]
  • http://www.ibm.com/developerworks/rational/library/edge/09/mar09/rader/
「https://en.wikipedia.org/w/index.php?title=Definitive_media_library&oldid=1326905042」より取得