ソフトウェアの展開

ソフトウェアの展開とは、ソフトウェアシステムを使用可能にするすべての活動を指します。 ^[1]

一般的な展開プロセスは、相互に関連する複数のアクティビティで構成され、アクティビティ間の遷移が可能です。これらのアクティビティは、プロデューサー側、コンシューマー側、またはその両方で発生する可能性があります。すべてのソフトウェア システムは一意であるため、各アクティビティ内の正確なプロセスまたは手順を定義することはほとんど不可能です。したがって、「展開」は、特定の要件または特性に応じてカスタマイズする必要がある一般的なプロセスとして解釈する必要があります。^[2]

コンピュータが非常に大きく、高価で、かさばっていた時代 (メインフレームやミニコンピュータ) では、ソフトウェアは製造元によってハードウェアと一緒にバンドルされることがよくありました。ビジネス ソフトウェアを既存のコンピュータにインストールする必要がある場合、システム アーキテクトまたはコンサルタントによる高価で時間のかかる訪問が必要になることがありました。今日の複雑なエンタープライズ ソフトウェアのオンプレミス インストールでは、これがまだ時々当てはまります。

しかし、 1980 年代のマイクロコンピュータの新時代に向けた大量市場向けソフトウェアの開発に伴い 、最初はカートリッジ、次にコンパクト カセット、次にフロッピー ディスク、そして (1990 年代以降)光メディア、インターネット、フラッシュ ドライブという新しい形式のソフトウェア配布が登場しました。これは、ソフトウェアの展開を顧客に任せることができることを意味しました。しかし、時間の経過とともに、顧客によるソフトウェアの構成が重要であり、理想的にはユーザー フレンドリなインターフェイスを備えている必要があることもますます認識されるようになりました (たとえば、顧客が Windows でレジストリ エントリを編集する必要があるのではなく)。

インターネット以前のソフトウェアの導入では、導入 (およびそれに密接に関連する新しいソフトウェアのリリース) は必然的に高価で、頻度も低く、扱いにくい作業でした。したがって、インターネットの普及によってエンドツーエンドのアジャイル ソフトウェア開発が可能になったと言えるでしょう。実際、クラウド コンピューティングとサービスとしてのソフトウェアの出現により、ソフトウェアを数分でインターネット経由で多数の顧客に導入できるようになりました。これはまた、導入スケジュールが顧客ではなくソフトウェア サプライヤーによって決定されるようになったことを意味しています。このような柔軟性により、特にリスクの少ないWeb アプリケーションでは、継続的デリバリーが実行可能なオプションとして台頭しました。

ソフトウェア展開の他のオプションには、ブルーグリーン展開とカナリアリリース展開があります。

リリース

リリースアクティビティは、開発プロセスが完了した後に行われ、展開プロセスではなく開発プロセスの一部として分類されることがあります。リリース アクティビティには、システムを組み立てて、実稼働環境で実行されるコンピュータ システムに転送するための準備作業がすべて含まれます。したがって、システムが許容可能なパフォーマンスで動作するために必要なリソースを決定したり、展開プロセスの後続のアクティビティを計画および/または文書化したりすることが必要になる場合があります。

インストールとアクティベーション

単純なシステムの場合、インストールには、ソフトウェアを実行するための何らかのコマンド、ショートカット、スクリプト、またはサービス(手動または自動) の確立が含まれます。複雑なシステムの場合、システムの構成 (エンド ユーザーに使用目的について質問したり、構成方法を直接尋ねたりして) や、必要なすべてのサブシステムを使用できるように準備することが含まれる場合があります。アクティベーションは、ソフトウェアの実行可能コンポーネントを初めて起動するアクティビティです (デジタル著作権管理システムの機能であるソフトウェア ライセンスに関する一般的な用語であるアクティベーションと混同しないでください)。

サーバー上の大規模なソフトウェア展開では、ユーザーが使用するソフトウェアのメイン コピー (「本番」) が、運用環境の運用サーバー上にインストールされることがあります。展開されたソフトウェアの他のバージョンは、テスト環境、開発環境、および障害復旧環境にインストールされることがあります。

複雑な継続的デリバリー環境やサービスとしてのソフトウェアシステムでは、異なる構成のシステム バージョンが、異なる内部または外部の顧客向けに本番環境に同時に存在することさえあります (これはマルチテナント アーキテクチャと呼ばれます)。また、1 つ以上の並行デプロイメントをキャンセルする可能性があり、異なる顧客グループに並行して徐々に展開されることもあります。たとえば、Twitter は、新機能やユーザー インターフェイスの変更のA/B テストに後者のアプローチを使用していることが知られています。ブルー グリーンデプロイメントの目的で、本番環境のロード バランサーにまだ接続されていないサーバーで構成される「非表示のライブ」グループを本番環境内に作成することもできます。

無効化

非アクティブ化はアクティブ化の逆で、システムのすでに実行中のコンポーネントをシャットダウンすることを意味します。非アクティブ化は、他のデプロイメント アクティビティを実行するために必要になることがよくあります。たとえば、ソフトウェア システムは、更新を実行する前に非アクティブ化する必要がある場合があります。使用頻度の低いシステムや古いシステムをサービスから削除する作業は、アプリケーションの廃止またはアプリケーションの廃止と呼ばれることがよくあります。

アンインストール

アンインストールはインストールの逆です。不要になったシステムを削除します。アンインストールしたシステムの依存関係を削除するために、他のソフトウェア システムを再構成する必要がある場合もあります。

アップデート

更新プロセスは、ソフトウェア システムの全体または一部の以前のバージョンを新しいリリースに置き換えます。通常、非アクティブ化とそれに続くインストールで構成されます。Linux などの一部のシステムでは、システムのパッケージ マネージャーを使用する場合、通常、ソフトウェア アプリケーションの古いバージョンもプロセスの一部として自動的にアンインストールされます。(これは、ソフトウェア パッケージがこの制限を回避するように特別に設計されていない限り、Linux パッケージ マネージャーは通常、ソフトウェア アプリケーションの複数のバージョンを同時にインストールすることをサポートしていないためです。)

組み込みアップデート

一部のソフトウェア システムには、更新をインストールするためのメカニズムが組み込まれています ( Linux、Android、iOSなどの一部のオペレーティング システムの場合は、オペレーティング システム自体に組み込まれています)。これらの更新プロセスの自動化は、完全に自動のものから、ユーザーが開始して制御するものまでさまざまです。Norton Internet Security は、ウイルス対策定義とシステムの他のコンポーネントの両方に対する更新を取得してインストールするための半自動の方法を備えたシステムの例です。他のソフトウェア製品では、更新がいつ利用可能になるかを判断するためのクエリ メカニズムが提供されています。

バージョン追跡

バージョン追跡システムは、ユーザーがソフトウェア システムの更新を見つけてインストールするのに役立ちます。例: ソフトウェア カタログには、ローカル システムにインストールされている各ソフトウェア パッケージのバージョンとその他の情報が保存されます。ボタンを 1 回クリックすると、アプリケーションのアップグレード Web ページのブラウザー ウィンドウが起動し、ログインが必要なサイトでユーザー名とパスワードが自動的に入力されます。Linux、Android、iOS では、バージョン追跡の標準化されたプロセス (公式にサポートされている方法でインストールされたソフトウェア パッケージ用) がオペレーティング システムに組み込まれているため、このプロセスはさらに簡単です。そのため、ログイン、ダウンロード、実行の手順を別途行う必要がなく、プロセスを完全に自動化するように構成できます。一部のサードパーティ ソフトウェアも、特定の Windows ソフトウェア パッケージのバージョン追跡とアップグレードの自動化をサポートしています。

ソフトウェア製品の複雑さと多様性により、展開プロセスの調整とエンジニアリングを行う専門の役割が生まれています。デスクトップ システムの場合、エンド ユーザーは、自分のマシンにソフトウェア パッケージをインストールするときに、しばしば「ソフトウェア展開者」にもなります。エンタープライズ ソフトウェアの展開にはさらに多くの役割が関係しており、それらの役割は、アプリケーションがテスト (実稼働前) 環境から実稼働環境へと進むにつれて変化するのが一般的です。エンタープライズ アプリケーションのソフトウェア展開に関係する一般的な役割には、次のものがあります。

• 試作環境の場合:
  • アプリケーション開発者:ソフトウェア開発プロセスを参照
  • ビルド＆リリースエンジニア:リリースエンジニアリングを参照
  • リリースマネージャー:リリース管理を参照
  • デプロイメントコーディネーター: DevOpsを参照
• 実稼働環境では:
  • システム管理者
  • データベース管理者
  • リリースコーディネーター: DevOps を参照
  • 運用プロジェクトマネージャー: ITILを参照

• アプリケーションライフサイクル管理
• 製品ライフサイクル管理
• システム管理
• システムの展開
• ソフトウェアリリース
• 決定的なメディアライブラリ
• お読みください
• リリース管理
• 展開環境

• 標準化の取り組み
  • ソリューション インストール スキーマの W3C への提出リクエスト
  • OASIS ソリューション展開記述子 TC
  • コンポーネントベースの分散アプリケーションの展開と構成に関する OMG 仕様 (OMG D&C)
  • JSR 88: Java EE アプリケーションのデプロイメント
• 記事
  • Carzaniga, Antonio; Fuggetta, Alfonso; Hall, Richard S.; Van Der Hoek, André; Heimbigner, Dennis; Wolf, Alexander L. (1998 年 4 月)。「ソフトウェア展開テクノロジの特性評価フレームワーク - 技術レポート CU-CS-857-98」(PDF)。コロラド州ボルダー:コロラド大学ボルダー校コンピュータ サイエンス学部。
• リソース
  • Visual Studio リリース管理