DevOpsのリリース管理の概念とベストプラクティス

DevOpsにおけるリリース管理とは、本番環境へのソフトウェアリリースを計画、調整、およびデプロイするためのプロセスを指します。リリース管理の目的は、新機能、バグの修正、機能強化を信頼できる方法で効率的に素早く提供することです。

リリース管理は、迅速かつ信頼できる方法でソフトウェアをエンドユーザーに提供するのと同時に、エラーやダウンタイムのリスクを最小限に抑える役割を担います。そのため、リリース管理はDevOpsにとって極めて重要な要素です。このブログ記事では、次の内容について説明します。

• リリース管理の概要
• DevOpsとその他の環境の違い
• リリース管理の各フェーズ
• ベストプラクティス
• DevOpsのその他のリソース

リリース管理とは

ソフトウェア開発とIT運用におけるリリース管理とは、計画からビルド、テスト、そしてデプロイに至るまで、ソフトウェアデリバリーのライフサイクル全体を管理する仕組みのことです。ITILとDevOpsのどちらにとっても、これは一般的なプロセスです。ただし、DevOpsではデリバリープロセスの全フェーズでコラボレーションと可視化を推進します。そうすることで、フィードバックループを短縮し、リリース管理の簡素化と迅速化を図ります。

ITIL®とDevOps間で、リリース管理の全体的な概念に違いはありませんが、そのアプローチは以下の2点で異なります。

• ITILはITサービス管理に特化したフレームワークですが、DevOpsはソフトウェア開発とIT運用のコラボレーションを重視しています。
• DevOpsの導入にはさまざまな方法がある一方、ITILには規範的な一連のインストラクションがあります。

ここでは、ITILチームとDevOpsチームのそれぞれにおけるリリース管理について見ていきましょう。

ITILにおけるリリース管理

ITIL 4のリリース管理プロセスでは、計画からリリースまでのすべてのフェーズでスケジュールを設定し、新しいデプロイの整合性を維持します。ITILでは、IT運用チームがソフトウェア開発チームからコードを受け取ります。そして、既存のサービスのアップタイムを維持しながら、いつどのようにサービスをデリバリーするのかを決定します。

DevOpsにおけるリリース管理

DevOpsのリリース管理でも、ソフトウェア開発とソフトウェアデリバリーのプロセスを計画、スケジュール、制御します。しかしDevOpsでは、プロセスの最初から最後まで開発チームとIT運用チームが協力します。その結果、フィードバックループの回数が減り、間隔も短くなり、迅速なリリースが可能になります。

DevOpsチームは、デリバリーするサービスについて共同で責任を負い、コードを所有し、オンコールに対応します。ソフトウェア開発者とITの専門家の両方がデリバリーライフサイクル全体とオンコール対応に取り組むことで、リリースプロセス中もその後も、インシデントの検出と解決をスピードアップできます。

DevOpsのリリース管理の各ステージ

リリース管理には、計画、テスト、デプロイ、監視など、いくつかのステージがあります。これらのプロセスは一般に、以下の3つのフェーズに分類されます。

1. 開発チームが新しいコードや機能を作成します。
2. 次に、開発チームがステージング環境でその新しいコードや機能をテストします。
   
3. 徹底的なテストを行い、承認を得たら、そのコードや新機能を本番環境にリリースします。

こうしたソフトウェアのアップデートは、ビジネスモデルに応じて、そのまま顧客に公開される場合とされない場合があります。たとえば開発者の立場からは、何かを開発したらすぐに本番環境にリリースしたいと考えるかもしれませんが、営業的な観点から、または特定のタイムラインに合わせるために、そのコードをユーザーベース全体にリリースするのを保留する場合もあります。その中間的なアプローチとして、ユーザーの一部に限定してベータ版をリリースするといった方法を採ることもあるでしょう。

DevOpsのリリース管理のベストプラクティス

定義を明らかにしたところで、DevOpsの重要な理念をいくつか確認し、それらがリリース管理のベストプラクティスにどのように反映されているかを見てみましょう。

成功の基準を定義する

ソフトウェアの公開準備が整ったと判断するには、どうすればよいのでしょうか。リリースとテストの両方で明確な受け入れ要件を設定しておけば、より信頼性の高いリリースを行えます。リリースの成功基準は主観的なものであってはいけません。主観的な基準では、失敗から学ぶことも、リリース管理プロセスを繰り返す中で最も効果的な方法を見つけることもできません。

プロダクトオーナー、品質責任者、リリース責任者は、新しいプロジェクトを進める前に主要なリリース指標を定義し、受け入れ基準について合意しておく必要があります。

ユーザーへの影響を最小限に抑えるために常に努力する

有能なリリースマネージャーは、次の2つの事態を避けるべく常に力を尽くします。

• ダウンタイム
• 顧客への影響

事前のテスト、積極的な監視、共同で行うリアルタイムアラート対応は、リリース段階での問題検出を促進するだけでなく、多くの場合は顧客が気付く前の問題検出を可能にします。コラボレーションによるインシデント対応計画も活用することで、チームはインシデントを迅速に解決し、リリースの成功に向けて進むことができます。

ステージング環境を最大限に活用する

ステージング環境を常に維持し、本番環境になるべく近づけることで、リリースの成功をさらに確実なものにできます。プロダクトオーナーからQAまで、全員でステージング環境を念入りに調べてテストを実行し、新しいデプロイの問題を特定する必要があります。

ステージング環境が本番環境とほぼ同じであれば、コードを本番環境にデプロイする前のステージング環境で問題を簡単に見つけられます。ステージング環境を適切に設計することで、以下のようなメリットが得られます。

• 顧客への影響を低減する
• DevOpsチームがリリースの受け入れ基準を迅速に満たす

CI/CDとQAを合理化する

DevOpsではシフトレフトの考え方が一般的です。シフトレフトとは、QA、自動化、テストを開発スケジュールの左側、つまり早い段階にシフトさせる手法です。これにより、DevOpsチームは潜在的な問題を迅速に発見できるようになります。その結果、フィードバックループにかける時間を短縮し、デリバリーパイプラインをスムーズに進めることができます。

開発ワークフローにより多くのテストを組み込むことで、CI/CDパイプラインの一貫性を容易に維持できます。

(DevOpsの枠組みにセキュリティを正式に導入するDevSecOpsについてもご覧ください。)

自動化を活用する

DevOpsの最優先のルールは、自動化によって人、プロセス、テクノロジーの効率化を図ることです。

ソフトウェア開発、QA、IT運用などのいずれの領域でも、人的ミスを減らし、従業員の日々の業務を楽にするためには自動化を導入するべきです。日常業務にかける時間を短縮し、チームが戦略的な業務により多くの時間を費やせるようにすることで、顧客に信頼性の高いサービスを一貫して提供できるようになります。

できるだけイミュータブル(不変)にする

プログラミングにおいてイミュータブル(不変)オブジェクトは、一度作成するとその状態を変更することができません。イミュータブルプログラミングを取り入れたチームは、既存の構成を変更するのではなく、まったく新しい構成をデプロイします。これは、既存の構成を変更することによって生じるエラーやバグを減らすことにつながります。このアプローチによって、リリースの本質的な信頼性が高まり、顧客と従業員の満足度も向上します。

DevOpsのリリース管理は人間中心

DevOpsのプロセスを導入することで、デリバリーライフサイクル全体でコラボレーションとテストのベストプラクティスが生まれるため、自ずとリリース管理の構造が改善されます。多くの人がDevOpsの主な価値として自動化を重視する傾向にありますが、自動化は常に従業員の効率性を高めるためのものであるべきです。従業員の人的ミスが減り、運用効率が高まれば、必然的に信頼性の高いサービスを迅速にリリースできるようになるでしょう。

ここで紹介したDevOpsにおけるリリース管理のベストプラクティスは、出発点にすぎません。技術が進歩して人々が学び続ける中で、私たちのリリース管理プロセスも変化していく必要があります。どのようなDevOpsリリース管理構造においても、人、プロセス、テクノロジーを継続的に改善していくことが成功に不可欠です。

このブログはこちらの英語ブログの翻訳です。