ポイント: ソフトウェアのデプロイは管理された環境を通じて移動することを含み、リリースはユーザーに利用可能にします。デプロイメントの主要な活動には、計画、検証、実行、確認が含まれますが、リリース管理は機能の可用性に関するビジネス戦略に沿っています。
- デプロイメント技術には、ブルーグリーンデプロイメントやロールデプロイメントが含まれます。
- リリースの種類は、メジャー、マイナー、緊急、メンテナンスリリースとして分類されます。
ソフトウェア開発の世界で関わるすべての作業の中で、顧客がソフトウェアを使用して成果を達成する時に、初めてソフトウェアの価値が実現されます。
毎日、数千のアップデートがアプリストアで利用可能になり、主にバグ修正、セキュリティアップデート、パフォーマンス改善を行い、時にはユーザーが楽しむための最新機能を提供しています。アプリストアのインテリジェンス企業App Annieによれば、2020年第2四半期にはアプリのダウンロード数がほぼ350億に達しました。
サービス管理においては、デプロイメントとリリースの2つの用語が、これらのアップデートの展開を説明するためにしばしば同義語として使用されます。しかし、彼らの間には違いがあるのでしょうか？調査してみましょう。（迅速な回答については、デプロイメントとリリースの重要な違いに進んでください。）
デプロイメントとは何ですか？
デプロイメントは、ソフトウェアを1つの管理された環境から別の環境に移動させることを含みます。ITIL 4の実践ガイドによると、
環境は特定の目的のために使用されるITインフラストラクチャのサブセットです。
最も一般的な環境は次のとおりです：
- 開発。 通常、devと呼ばれ、開発者がコードを構築する場所です。
- 統合。 ここでは、新しいコードが組み合わされ、既存のコードと連携して機能するかが検証されます。
- テスト。 ここでは、機能テストと非機能テストがマージされたコードに対して実施され、組織と顧客の要件を満たしていることが確認されます。
- ステージング。 この環境は、実際のデータを使用してソフトウェアをテストし、使用準備が整っていることを検証するために使用されます。
- 本番。 通常、prodと呼ばれ、ユーザーにソフトウェアが提供される場所です。
デプロイメントは一般的にソフトウェア開発ライフサイクル（SDLC）の最終段階と考えられています：
デプロイメント活動
デプロイメント管理に関与する活動は次のとおりです：
- デプロイメントの計画。承認、リソースの調整、およびスケジューリングを含む準備タスク。
- サービスコンポーネントの検証。単体テストと統合テスト、反復的な修正と再テスト。
- ターゲット環境の検証。 ホスト環境がソフトウェアパッケージを受け入れる準備ができていることを確認するための検証。
- デプロイメントの実行。 環境にソフトウェアをプッシュし、関連するシステムテストを実施します。
- デプロイメントの確認。 顧客の要件が満たされていることを確認するための受け入れテスト。この場でレビューと学んだ教訓活動も実施されます。
デプロイメント技術
従来、デプロイメントはすべての機能が一度にリリースされる「ビッグバンアプローチ」で行われていました。しかし、現在では、技術とリスク管理のために、段階的なリリースを通じたロールアウトまたは段階的デプロイメントが好まれています。
デプロイメントで一般的に使用される手法の1つはブルーグリーンアプローチです。ここでは、2つの同一で別々の本番環境が使用され、現在のコードは「青」の環境で実行され、新しいコードが「緑」の環境でデプロイされます。トラフィックは青から緑に切り替えられ、新しいサービスや機能のパフォーマンスが監視されます。重大な問題が発生した場合は、トラフィックが青に戻され（ロールバックのように）、顧客に大きな影響を与えることなく修正や対処が可能です。
デプロイメント活動の改善
デプロイメントは長年にわたりソフトウェア開発の難しい部分でしたが、最近ではDevOpsなどのプラクティスの進展により容易になっています。CI/CD（継続的インテグレーション/継続的デリバリーまたはデプロイメント）は、統合、テスト、デプロイメントの自動化のおかげで、ソフトウェアのデプロイメントを迅速化し、エラーを減少させています。この分野でのツールは急速に主流のソリューションとなっています。例えば：
しかし、多くの組織は依然として本番環境へのデプロイメントをトリガーするために手動の変更承認を使用しています。通常、2つの主な理由からです：
- ライブサービスに影響を与える場合のリスクを軽減するため。
- コンプライアンスのニーズを満たすため。
ソフトウェアリリースとは何ですか？
ISO/IEC 20000の標準定義によれば、リリースは：
1つ以上の新しいまたは変更されたサービスまたはサービスコンポーネントの集合が、1つ以上の変更の結果として本番環境にデプロイされます。
言い換えれば、リリースはサービスや機能をユーザーに利用可能にします。多くの場合、リリース管理は技術的責任よりもビジネス責任の方が重要です。これは、リリースのスケジューリングに関する決定が、収益またはポートフォリオ管理の観点からビジネス戦略に結びつく可能性があるからです。
企業は、合意されたマーケティング計画に基づいて機能をリリースすることを決定したり、既存製品の食い合いを防ぐためにリリースを段階的に行ったり、競合他社の活動に対抗するためにリリースを調整することができます。機能は企業の製品提供に基づいて、例えばプレミアム顧客が高度な機能を受け取るといった具合に、異なる顧客にリリースされることもあります。
リリースカテゴリ
リリースの最も一般的な分類は範囲に基づいています：
- メジャーとマイナーという用語は、コード、サービス、機能の変更の重要性に関連してリリースを説明するために使用されます。例えば、メジャーリリースはソフトウェアがバージョン2.4から3.1に移行することがあり、マイナーリリースは2.2.1から2.2.2に移行することがあります。
- 緊急リリースは、特にセキュリティまたはパフォーマンスの観点から重大な問題に対処するために迅速に提供されるソフトウェアバージョンまたはパッケージを定義するために使用されます。
- メンテナンスリリースは、バグ修正やパッチ用です。
- 機能リリースは、新しいまたは変更された機能用です。
リリース技術
ソフトウェア開発で使用されるいくつかのリリース技術には次のものがあります：
- カナリアリリース。これは、新機能をユーザーのサブセットにのみリリースすることを含みます。カナリアが鉱山で有毒ガスをテストするために使用されるように、このユーザーグループは問題を発見するためのテストケースです。
- ダークローンチ。カナリアリリースに似ており、ダークローンチは新機能に気付いていないユーザーのサブセットに機能をアクティブ化します（そのため「ダーク」）。これは、組織のニーズに基づいて機能のオンとオフを切り替えることを可能にする機能フラグを使用することで行うことができます。
デプロイメントとリリース: 主な違い
デプロイメントとリリースの主な違いは、ビジネスの根拠です。デプロイメントは、ユーザーが機能にアクセスできることを必ずしも意味しません。これは、関与する異なる環境によって明らかに示されています。一部の企業は、デプロイメントが本番環境で行われると同時にリリースを行うことを選択します。
他の企業は、ビジネスが決定するまで新機能を生産しておくが、ユーザーには利用可能にしないことを選びます。
追加リソース
このトピックについての詳細は、以下のリソースを探索してください：
これらの投稿は私自身の意見であり、必ずしもBMCの立場、戦略、または意見を表すものではありません。