リリース管理

一言でいうと

ソフトウェアの変更を、いつ、どの手順で、誰の承認を得て本番環境へ反映するかを計画し、統制する活動です。

提唱者と登場年

リリース管理は、ITサービスマネジメントの枠組みであるITILの中で、プロセスの一つとして体系化されました。ITILは1989年に公開され、30冊の書籍に広がった枠組みです。2001年の第2版ではリリース管理が一つのプロセスとして扱われ、2007年の第3版で、リリース・展開管理、サービスの妥当性確認とテスト、評価の3つのプロセスに分かれました。

英語版Wikipediaは、リリース管理を、ソフトウェアのビルドを複数の段階と環境にわたって管理、計画、スケジュールし、統制する過程と説明しています。アジャイル開発でリリースの頻度が上がるにつれ、継続的デリバリーと自動化の比重が高まったことにも触れています。

何を解決するか

本番環境への変更が原因の障害を減らし、起きたときの影響を小さくします。複数のチームが同じシステムに変更を入れる組織では、変更の組み合わせや順序によって、個別には問題のない変更が障害を引き起こすことがあります。リリースの単位と順序を決め、反映前に何を確認するかを定めることで、この種の事故を防ぎます。

切り戻しの手順を事前に用意しておくことも目的に含まれます。問題が起きたときに誰が切り戻しを判断し、どの状態まで戻すかが決まっていなければ、対応が遅れて影響が広がります。

実際の進み方

リリースに含める変更を確定し、テスト環境で検証したうえで、反映の日時、手順、確認項目、切り戻しの条件を文書にします。承認者が内容を確認して可否を判断し、反映後は動作を監視して完了を判定します。

継続的デリバリーを採る組織では、この流れの多くをパイプラインに組み込みます。承認や確認をツールで自動化し、人の判断は影響の大きい変更に絞ります。リリースの頻度が高い組織ほど、1回あたりの変更は小さくなり、切り戻しの範囲も狭くなります。

導入でよくある失敗

• 承認の手続きを重くしすぎ、変更をまとめて出すようになって1回あたりの影響が大きくなる
• 切り戻しの手順を用意しても試しておらず、本番で使えない
• 反映後の確認項目が決まっておらず、問題の発見が利用者からの問い合わせまで遅れる

求人票にこの語がある場合に読み取れること

リリース管理が独立した業務として書かれている場合、本番環境への変更を統制する担当を置くほど、変更の件数や関係するチームが多い組織だと推定できます。承認の会議や手順書を中心に運用しているのか、パイプラインによる自動化を中心に運用しているのかで、求める経験が異なります。候補者には、リリースの頻度、切り戻しを実際に行った経験、承認の基準を誰が決めていたかを確認してください。

隣接手法との違い