ソフトウェア エンジニアリングのリリースとは何ですか?
ソフトウェア エンジニアリングでは、リリースは新しいソフトウェアまたは変更されたソフトウェアとその作成プロセスです。リリースはソフトウェアの完全に機能するバージョンを構成し、ソフトウェア開発とエンジニアリング プロセスのクライマックスです。アルファ版とベータ版のソフトウェアは通常、リリースの前にリリースされます。
アルファ版とベータ版のリリースはアルファ リリースやベータ リリースとも呼ばれますが、特異な形では、リリースは一般的にソフトウェアの最終バージョンを指します。また、リリースがローンチやインクリメントと呼ばれることもあります。
ほとんどの組織は、連続して更新される一意の数字や文字のセットを持つリリースを特定します。この命名プロセスはソフトウェアバージョン管理と呼ばれています。これらの一意の識別子がリリースからリリースに変わる方法に関する業界全体のルールはありませんが、各企業は一貫して独自の社内基準に従っています。
リリース管理プロセスとは何ですか?
組織は、リリース管理に焦点を当てることで、ソフトウェアの構築や更新の品質、スピード、効率を向上させます。これは、リリースの開発、テスト、展開、サポートの段階を通じて、ソフトウェア ビルドの計画、スケジューリング、管理のプロセスです。アジャイル開発、継続的デリバリー、DevOps、リリース自動化などのテクニックが、リリース管理の最適化に役立ちました。このプロセスの速度は最近加速しており、数年前に Amazon が 年間 5,000 万個のコードデプロイを達成しました。 1 秒あたり 1 つ以上です。
リリース管理は、ソフトウェア エンジニアリングにおける比較的新しい分野ですが、テクノロジーの迅速な革新のおかげで急速に成長しています。規律として、従来のビジネスに焦点を当てたプロジェクト管理と、システム開発ライフサイクル (SDLC) に関する技術的知識と、IT サービス管理の一連のプラクティスである IT インフラストラクチャ ライブラリの両方から生まれます。
リリース管理の目的とメリット
リリース管理を効果的に行うことで、組織によるリリースの成功数を増やし、品質の問題を減らすことができます。生産性、コミュニケーション、調整が改善され、組織はリスクを減らしながらソフトウェアをより迅速に提供できます。
これらの改善は、チームが市場投入までの時間を短くして品質の高いソフトウェアを繰り返し生産できることを意味し、会社が運用環境に対してより応答性を高めることができます。
リリース管理は、開発と運用プロセスの標準化と合理化にも役立ちます。チームは監査可能なリリース コントロールを実装し、ライフ サイクルを通じてすべてのリリースのリポジトリを作成します。すべてのリリースに従う必要がある、文書化された単一のプロセスを持つことで、組織の成熟度が向上します。標準化が強化され、製品に焦点を当てることで、チームは経験からより有用な教訓を引き出し、今後のリリースでそれらを適用できます。
オペレーション部門は、驚きが少ないため、開発者との調整の強化に感謝しています。このため、開発部門からリリースを「丸投げ」され、運用部門は短納期のために火消しに追われ、「パッチを当てて祈る」ような状態になることを避けることができるようになったのです。また、開発環境と運用環境の間で構成の問題を解決する機会も増えています。
要するに、リリース管理は、IT組織の複数の機能にわたるチームの障壁を打破します。その結果、製品の納品を全体的に改善できます。
Gabriel Gutierrez, a Solutions Architect at Boeing and former Release Manager at Costco, says that when executing a release, it’s important to give adequate consideration to the impacts on other areas of the organization. “Companies must provide a common forum where changes are fully vetted and put through thorough architectural and design reviews that eventually lead to integrated testing. Cross-functional and technical reviews are essential to minimizing the inevitable pain after go-live. A smooth post-go-live operation is a critical success factor of any release,” he explains.
リリース管理の簡単な歴史
リリース管理の台頭は、ソフトウェア エンジニアリングがプロジェクトベースから製品ベースのオファリングに移行したことで生まれています。プロジェクトベースの開発パラダイムでは、ソフトウェア開発者は各リリースを製品ではなくプロジェクトと見なします。完全に開発されたソフトウェアは、主に開発者の役割の終わりを示しました。
しかし、時間の経過とともに、ソフトウェア開発プロセスは、製品が長い間サポートされ、改善され、繰り返し再起動される製品サイクルによく似ています。このフレームワークでは、リリースは開発の最終目標ではなく、サポートと修正の移行ポイントでした。
この複雑さが増す中で、フェーズを調整する必要性が高まりました。そのため、現在のリリース管理プラクティスは、アフターサービスのサポートやさらなる開発にまで及ぶ、ビジネスに焦点を当てたプロジェクト管理の原則に影響を受ける部分もあります。
リリース管理は、関係者の要件が無限に流動的に見え、コンプライアンスと規制の 状況が変化し続けるソフトウェア開発の本質的な混乱に対処する、より大きな IT 変更管理の分野の一部です。この環境に対応するには、ソフトウェア エンジニアリング プロセスをうまく同期させる必要があり、リリース管理がこれを達成するのに役立ちます。(注: チェンジ マネジメントは、文化の再構築、人の離職、組織の内部リストラである組織の変化と混同しないようにします。)
A “common pitfall is disregarding the importance of a well-thought-out change management process,” says Jen Dunbeck, a release manager at automated IT services provider BitTitan. “A change control board's or change advisory board's significance cannot be underestimated in a release. A key function of their job is to help the organization assess risk and impact with impartiality. They also help root out technical dependencies that may not have been evident as individual contributions to the deployment,” she adds.
変更管理プロセスを開発するには、プロジェクトの変更を提案し、変更が承認され、行われた際に記録するための標準的な方法を用意しておくと便利です。変更提案書と変更管理ログ用の以下の無料テンプレートをダウンロードして、作業を開始してください。
変更提案テンプレート
変更提案書は、変更の種類と規模を概説し、多くの場合、変更管理プロセスの最初のステップです。変更が必要な理由、期待される結果と影響、必要な時間とリソース、レビューが必要なその他の要因を説明します。このテンプレートには、説明的な情報を追加するスペースや、コストとメリットを計算するためのセクションも含まれています。
変更管理ログ
変更管理ログとは、誰がいつ、どのような変更をリクエストしたか、変更リクエストのステータス、優先度、解決情報を追跡する文書です。より詳細な記録が必要な場合は、変更の種類や影響などの他の詳細を含めます。このログ テンプレートは、重要な情報を追跡できるように設計されているため、変更リクエストの優先順位付け、対処、後での参照が簡単に行えます。
リリース管理の仕組み: 概要
すべてのソフトウェアが同じように作成されるわけではありません。プログラムの機能やアプリケーションによって、ソフトウェア エンジニアリング プロセスは厳格さと強度によって異なります。
たとえば、航空機で使用できるように設計されたソフトウェアは、厳格なテストを受けます。狭いパフォーマンス許容誤差を満たしていない場合は、広範なドキュメントを作成し、複数の修正を実装する必要があります。機能要件と品質指標は厳しく、ソフトウェアは飛行機に近くなる前に多くの承認層を経る必要があります。
規律正しいリリース管理プロセスは、ソフトウェアが主要な関係者の規定に沿って構築、テスト、提供されることを保証するのに役立ちます。チームはソフトウェアをチェックして、ソフトウェアが何をすべきか、スケジュールどおりに準備ができているかどうかを確認します。
リリース管理では、次の要素が 1 つの中央リポジトリにまとめられます。
- 顧客に必要なときに必要なものを提供するビジネス上の不可欠事項
- 品質保証とコンプライアンスの技術的タスク
- ソフトウェア アーティファクトの管理
リポジトリから、アーティファクトはアプリケーション展開用のクライアント本番環境にリリースされます。リリース管理は、ソフトウェア エンジニアリングを含む相互接続されたが異なるタスク (設計、開発、テスト、展開、メンテナンス、ビジネスおよび顧客の要件) を結び付ける接着剤と考えることができます。
リリースは、単なるコアソフトウェア エンジニアリング機能以上の機能で構成されます。開発者はリリースが最終製品の納品に成功したと明らかに見ていますが、営業担当者やカスタマー サポート スタッフのトレーニング、新しいリリースの広告やマーケティングなど、いくつかの支援ビジネス活動が関与しています。これらのアクティビティはリリース テンポと同期して行う必要があります。これにより、リリース管理プロセスが複雑になります。
さらに、リリース管理は新しく設計されたソフトウェアだけではありません。変更されたソフトウェアは、関係者が望むものを確実に得るために、同じプロセスを経ます。
実際のリリースは手動で行うこともできますが、リリース管理プロセスの成熟状況に応じて、自動化することも増えています。(Amazon は自動リリース プロセスを使用して、毎秒新しいリリースを達成しています。過去、毎週、毎月、四半期ごとの更新は、ソフトウェア開発チームの方が一般的でした)。
リリースは、ボックス内の物理的な製品、Web サイトやサーバーからのダウンロード、モバイル アプリ ストアからのデバイスへのプッシュ、または Web ベースのアプリケーションへのシームレスな更新など、さまざまな形式で提供されます。
大小を問わず、すべての業界で、すべてのソフトウェアエンジニアリング グループがリリース管理を使用してプロセスをスムーズに進めます。内部で使用されるソフトウェアや製品として販売されているソフトウェアに適用される場合があります。ソフトウェア エンジニアリング グループは、大小さまざまな業界でリリース管理を採用しており、結果として得られるソフトウェアを使用して自社の製品やシステムを実行したり、製品としてクライアントに販売したりすることができます。
リリース管理に最も役立つ開発アプローチの 1 つは、開発と運用を組み合わせて形成された用語である DevOps と呼ばれています。その名の通り、DevOps はソフトウェア開発のすべての段階で自動化と監視を組み合わせて市場進出時間を短縮し、顧客満足度を向上させることで、開発者とソフトウェア エンジニアリングのオペレーション間の調整を強化しようとします。
リリース管理の主な用語
リリース管理をマスターするには、一般的に使用される用語を理解する必要があります。
開発作業指示書: ソフトウェア アプリケーションまたはシステムの開発または変更のための作業指示書です。
DevOps チーム: DevOps の本質は開発部門と運用部門の連携を強化することなので、別チームを作ると語弊が生じます。名前にもかかわらず、この用語は通常、2 つの機能を調整するために働く開発側とオペレーション側の両方の主要なチーム メンバーを指します。
インストール作業指示書: 開発作業指示書と同様に、インストール作業指示書はソフトウェア アプリケーション、システム、またはインフラストラクチャー コンポーネントをインストールするための作業指示書です。
製品所有者: 開発プロジェクトの製品所有者が主な関係者です。通常、ビジネスや製品の (最終的な) ユーザーを表し、製品のビジョンを定義します。
プロジェクト マネージャー: プロジェクト マネージャーが 1 つの製品の方向性を担当します。製品ロードマップとビジョンを定義し、成果物を交渉する責任があります。通常、プロジェクト マネージャーの中核となる責任は、単一の製品や密接に関連する製品ファミリを超えるものではありません。
リリース: リリースは 1 つ以上のリリース単位で構成されます。
リリース マネージャー: リリース マネージャーの役割は、リリースを構成するすべての項目を計画、調整、管理、スケジュールすることです。これらの項目はすべて必ずしも同じ製品から発生する必要はありません。たとえば、このマネージャーは、新しいリリースと統合するように設計された他の製品に対する作業も調整する必要があります。
リリース ポリシー: これは、ライブの運用環境にリリースを展開する方法に関する一連のルールです。影響や緊急度などの要因に応じて、リリース ポリシーが異なるリリースに適用されます。
リリース記録: リリース記録には、計画から開発プロセスの終了まで、リリースの履歴が記録されます。
リリース単位: この用語は、チームが承認された変更を実装するためにライブ環境で同時にテストとリリースを行う一連の構成項目を指します。さらに、構成項目は、構成管理下にあるインフラストラクチャの構成要素であり、製品の属性とパフォーマンスが設計、要件、運用情報と一致していることを確認するプロセスです。
サービス所有者: サービス所有者は、特定の IT サービスに対する大まかな説明責任を引き受けます。彼らはサービスを提供するために必要な日々の業務にあまり関心を持てません。それがサービス マネージャーの役割です。
品質マネージャー: 品質管理者は、リリースが規定された基準を満たしていることを確認します。リリース マネージャーから報告を受ける場合があります。
リリース管理の主な概念
リリース管理は、いくつかの相互接続されたが明確な分野を監督することを含むので、スーパー規律として記述されることがあります。構成管理の専門家サルマン・クワジャに注意してください。
リリース管理の中心的なプラクティスの 1 つは、コンピューター コードの変更を管理するプロセスであるコード管理です。コード モジュールやコード行の集まりを使用して、コード管理は、コードやメンテナンスやデバッグなどのコード関連の活動に変更を加える行為を簡素化し、スピードアップします。リリース管理の重要な側面を構成するコード管理の 1 つのタイプは、バージョン管理です。これは、比較と参照を目的とした、同じソフトウェアの異なるリリースのコード管理を指します。コード管理は、記録管理の原則の多くに従います。
その役割を効果的に果たすには、リリース マネージャーは、主にチーム間だけでなく、チーム内でも進行役と共同作業を促進する必要があります。リリース マネージャーは通常、経験豊富な専門家自身であるため、ピッチインを求められる場合があります。
プロセスとポリシーは、効果的なリリース管理に不可欠です。問題は必ず発生し、問題に対処するためのプロトコルが必要です。リリース マネージャーは、プロダクション コードのゲート キーパーまたはガーディアンとしても機能します。コード アーティファクトが組織外に移動するたびに、彼らは知っています。
多くのリリースで、生産性とスループットの指標を測定して、リリース管理の効率を確認することが可能になります。一般的な指標 には、速度やバーンダウン率などが含まれます。
リリース管理のサイクル
リリース管理は通常、明確に定義されたパスに従います。これは、組織全体のリリース スケジュールの作成から始まります。ソフトウェア更新プログラムを継続的にリリースする企業もあれば、設定されたスケジュールを好む企業もあります。次に、製品またはソリューション リリースのスケジュールを設定します。
リリース管理は通常、リリース マネージャーが変更や新機能のリクエストを受け取ると、開発サイクルの最初の段階から始まります。リクエストの承認を得て、チームは新しいリリースを設計し、計画が開始されます。開発者は新しいソフトウェアを構築します。開発後、リリースはテストに入り、チームはリリースを受け入れる前に変更を加える場合があります。その後、リリースは展開に移行し、そこで完全に使用できるようになります。展開後の段階では、ここでチームが文書化するバグやユーザー ストーリーが、新しいリリースの材料として開発サイクルにフィードバックされる可能性のあるサポートです。
シンプル リリース計画テンプレート
シンプルなリリース計画には、以下のテンプレートを使用してください。特に複雑で予算の高いプロジェクトでは、ここにダウンロード876
シンプル リリース計画テンプレートをダウンロード — Word
リリース管理が対処に役立つ課題
これまで、多くの企業はリリース サイクルを管理するプロセスを欠いていました。しかし、問題は収益に打撃を与える可能性があり、バグやクラッシュには多くの時間とコスト (信頼性と評判) が必要になるため、リリース管理は一般的な課題に対処するための規律として生まれました。
組織によっては、開発からテスト、本番環境へのコードの展開に苦労している場合もありますが、収益への影響は少ないかもしれませんが、オペレーション スタッフの懸念の原因にもなります。
また、組織の内部構造がチーム間の対立を引き起こしたり、リリース管理によって摩擦が減る場合もあります。同様に、デリバリー チームが多く連携していると、あるチームの仕事が他のチームを混乱させるリスクが高くなります。効率的なリリース管理プロセスは、組織がさまざまな問題を回避するのに役立ちます。
アジャイルの世界でのリリース管理と DevOps
一般的なアジャイルの原則に基づいてソフトウェア開発を行う組織は、通常、より頻繁なリリースを生成します。ソフトウェア リリースに対するアジャイルアプローチは、継続的デリバリーと呼ばれ、いつでも展開可能なコードを作成することを目的としています。統合とテストの従来の段階をほぼ完全に排除し、非常に短いサイクルでリリース プロセスを自動化します。
Software product development expert and author Jon Quigley of Value Transformation notes that studies have shown an inverse relationship between project size and success. He also says research suggests that customers do not use 45 percent of developed features. These statistics argue for small, focused releases that prioritize features highly valued by customers. “The upshot of all of this has driven deliveries of software or development of increments of software that are small, the smaller the better,” he says.
継続的デリバリーでは、リリース管理は開発と生産の間の重要なコネクタであり続けます。リリース管理では、コードの整合性を検証し、計画通りに機能することを確認します。アジャイル手法では、Waterfall 手法でよく見られるサイロ化を分解しますが、アジャイルでは徹底的なドキュメントが必要であるため、プロセスは明確です。
ボーイング社の Gutierrez 氏は、継続的デリバリーと、もう 1 つの一般的な方法である継続的な展開に関して多くの混乱があると述べています。「継続的な展開とは、パイプラインの結果が成功した場合、コード ベースで行われたすべての変更がほぼ即座に本番環境にデプロイされるという概念です。継続的デリバリーとは、コード ベースに対するすべての変更が、非本番環境に展開する時点までパイプラインを通過するという概念です。チームは、コード ベースのリリースを計画する際に、後ではなくすぐに問題を発見し、対処します。コード ベースは常にリリースに安全な品質レベルにあります。コード ベースをプロダクションにリリースするタイミングは、ビジネスによって決まります。」と彼は説明します。
コード ベースを効果的かつ効率的にプロダクションにリリースするために、リリース マネージャーは自動化、DevOps の考え方、継続的インテグレーションの 3 つのことに依存しています。自動化は主にテスト機能に関連しますが、DevOps の考え方は、前者から後者への急激な移行の可能性をスムーズにするために、開発と運用の調整 (デリバリーとインフラストラクチャの人々は同じかもしれません) を大幅に改善します。
一方、継続的インテグレーションとは、開発者が自分の作業するコードのコピーを通常は 1 日に 1 回程度メインラインに更新する方法です。継続的インテグレーションは、厳格な自動化テスト システムに依存しており、エラーをすばやく排除し、変更プロセスをスピードアップする傾向があります。
アジャイル リリース計画テンプレート
アジャイル リリース計画は最初のスプリントの前に行われるため、リリース目標、機能、リソースの割り当てに集中できます。このアジャイル リリース テンプレートを使用すると、すべてのタスクをリスト化し、各タスクをスプリントに割り当て、開始日と終了日に基づいて期間を計算できます。また、ドロップダウン メニューから各タスクのステータスを示し、対応する各目標を定義することもできます。
アジャイル テスト計画テンプレート
アジャイル プロジェクトでは、テスト フェーズは、最新の情報を使用してテストを定義し、スコープの誤解を避けるために、動的で反復的なプロセスです。このテスト計画テンプレートは、アクション、期待される結果、実際の結果、テストが合格したか失敗したかを追跡するスペースを提供します。
アジャイル テスト計画テンプレートのダウンロード — Excel
IT インフラストラクチャ ライブラリ/IT サービス管理を使用したリリース管理
IT サービス管理とは、組織が提供する IT サービスの設計、計画、提供、運用、制御に使用する活動のスーパーセットです。これらの中には、情報テクノロジー インフラストラクチャ ライブラリとして知られている詳細な実践セットがあります。ITSM、特に ITIL を使用して IT オペレーションを管理する組織では、リリース管理は ITIL の原則に従います。
ITIL 2011 として知られる現在の形式では、ITIL は 5 つのボリュームで構成されています。リリース管理は、これらのボリュームの 3 分の 1 であるサービス移行量に含まれており、これはサービスの運用への提供に関するものです。ご想像のとおり、リリースおよび展開管理プロセスは、「テストおよびライブ環境へのリリースの移動を計画、スケジュール、制御する」を目的としています。変更管理も第 3 ボリュームに含まれています。
ITIL 組織のリリースは、アジャイル組織よりもはるかに頻繁に発生しません。ITIL のリリース プロセスは、ITSM チケット システムを使用して管理されており、自動化されたリリース プロセスにそれほど重点を置いていません。だからといって、効果が低いわけではありません。ITIL プラクティスを実装する組織は、リリース プロセスの効率を高めるよりもはるかに多くのことを行うことができます。また、金銭的利益を実現し、提供するサービスのビジネス価値を高めることもできます。
エンタープライズ リリース管理
エンタープライズ リリース管理 (ERM) は、医療システム、大企業、大学など、大規模または複雑なソフトウェアを持つ組織レベルでリリースの全体像を管理します。ERM は、個々のソフトウェア リリースの調整と、それらが組織の大規模な計画、戦略、カレンダーにどのように適合するかを扱います。
なぜこれが重要なのですか? 複雑なソフトウェア システムを開発する組織を想像してみてください。複数の開発グループが、これらの大規模なシステムのさまざまなコンポーネントに取り組んでいます。この構造は、開発者が専門化し、集中力を高め、コンポーネントを一つ一つ構築できるため、内部的に理にかなっています。しかし、最終的には、単一のシームレスに統合されたシステムで収束する必要があります。エンタープライズ レベルでリリース管理を包括的に行わないと、組織の IT ポートフォリオは一貫性を欠くでしょう。
ERM を使用すると、組織は統合された全体と同様に機能する大規模なソフトウェア製品を展開でき、効率的にこれを行うのに役立ちます。通常、ERM の取り組みでは、多くのリリース マネージャーが連携して作業し、それぞれのリリースを同期させる必要があります。
リリース マネジメントと PMI の主要な知識領域
2000 年のプロジェクト マネジメント協会年次セミナー シンポジウムで、フランク・アギールは、ソフトウェア開発企業の間で、リリースの管理のみに焦点を当てた専門的な分野が必要であるという新たな実現について議論しました。プロジェクト マネージャーははるかに広範な優先順位を持つので、プロジェクト マネージャーではなくリリース マネージャーがこの役割を果たします。
Aguilh 氏は、リリース管理の成功は、競争上の圧力と技術の進歩を念頭に置きながら、期限内に展開し、予算内で展開し、既存の顧客に無視できる影響を与え、新しい顧客の要件を満たすという 4 つの主な目標を達成するプロセスであると述べました。また、リリース管理は、異なる「組織」によって実行されるいくつかの「主要なタスク」を含むプロセスであると説明しました。
リリース管理では、組織内の多くの部門間の調整が必要で、それぞれが専門的な役割を果たします。Aguilh の「組織」は、セールスやマーケティングから R&D、オペレーション、システム エンジニアリング、カスタマー サポート、法務まで、広がっています。
「リリースを成功させるには、部門を超えた同期性が必要です。」と BitTitan のダンベックは言います。「開発者は適切な場所でコードをチェックする必要があります。QA はチェックを実行する必要があります。オペレーションではブランチを管理し、デプロイの準備を整える必要があります。しかし、これらは単なる技術的な構成要素です。社内で変更を伝える方法がない場合は、機能やボタンの変更があるデモを顧客に見せると、営業担当者は驚くでしょう。サポート チームは入ってくる質問に答えられませんし、リリース ノートやヘルプ センターの記事などを通じて変更を伝えていないと、顧客は必要な答えを得られません。」と彼女は強調します。
「これらの問題を解決する最も簡単な方法は、リリースに関する関係者を明確に特定し、プロジェクト サイクルを通じて頻繁に関与することです。組織ごとにコミュニケーションの好みが異なります。会議、チャット チャネル、Wiki ページ、または単なるメールは、全員が情報を共有するための良い方法です。重要なのは、ケイデンスを特定し、それに固執することです。」と、ダンベックは結論付けます。
Aguilh のビジョンによると、リリース管理はプロジェクト管理の原則をソフトウェア リリースに適用することに部分的にかかっています。これには、プロジェクト管理の主なプロセス領域 (開始、計画、実行、管理、終了) が含まれます。
しかし、Aguilh 氏はまた、リリース管理に固有の 9 つのプロセスを提起しました。以下に、これら 9 つのプロセスの説明とそれらが発生する順序を示します。
- 機能製品リクエスト (FPR): これは、「機能グループ」がソフトウェアに追加する新機能や機能のリクエストを正式化するためのメカニズムです。
- ドキュメントプロセス: チームは、今後のリリースに向けた情報共有プロトコルを導入します。
- リリース パッケージング プロセス: このプロセスでは、市場の圧力、コスト、収益、開発時間、統合などの要因に基づいて、最終リリースに何が入っているのかを決定します。
- 開発プロセス/変更管理プロセス: これらの 2 つのステップは並行して実行され、自己説明的です。開発中には、品質ゲートを使用して開発サイクルのマイルストーンを示す場合があります。変更制御はラボ テストとフィールド テストに続き、新しい機能が期待どおりに機能しているかどうかを確認し、既存の機能に影響を与えたかどうかを確認します。
- トレーニング プロセス: これには、技術サポート スタッフ、直販およびマーケティング担当者、テレマーケティング スタッフのトレーニングが含まれます。
- 顧客テスト: このステップは、顧客へのベータ リリースを通じて行われます。
- 顧客通知プロセス: 展開前の最後の段階では、リリースが予定されていることを顧客に通知します。
- 展開: デプロイ自体は、展開前、実際の展開、展開後を含む複数ステージのプロセスです。
Aguilh 氏は、リリース管理のプロセスはプロジェクト管理のプロセスと非常に密接に対応していると提案しました。たとえば、FPR とリリース パッケージは基本的に範囲と計画を考慮し、品質はドキュメント、開発、変更管理、トレーニングに対応します。実行と制御は、トレーニング、顧客テスト、顧客通知、展開に対応します。もちろん、クローズはデプロイにマッピングされます。したがって、プロジェクト管理とリリース管理の間に便利な並行点が引き出され、効果的なリリース マネージャーがプロジェクト マネージャーと同じスキルを持つ必要があることを明らかにします。
ソフトウェア開発ライフ サイクルの段階別のリリース管理プロセス
リリース管理プロセスがプロジェクト管理の中核プロセスとどのように一致しているかをご覧になられました。それでは、リリース管理プロセスがソフトウェア開発ライフサイクル (SDLC) の段階とどのように並んでいるかを見てみましょう。SDLC には通常 6 つのフェーズがあります。
- 要件の収集と分析
- デザイン
- 実装またはコーディング
- テスト
- 展開
- メンテナンス
開発中、マネージャーはリリース管理プロセスの範囲、原則、最終目標を定義するリリース ポリシーをレイアウトします。組織の戦略的目標を使用して、リリース管理プロセスに通知し、ガイドします。例を見るために、公開のためにオープン ソースのソフトウェア プロジェクトを促進する Apache Software Foundation のリリース ポリシー を見てみましょう。
リリース マネージャーは、リリース ポリシーに基づいてリリース計画を作成します。これらの計画は、複数のリリースを展開するための広範なガイドラインです。
設計フェーズでは、リリース マネージャーは、リリースをサポートするハードウェアとソフトウェアのアセットが設計および構成されていることを確認します。次に、コーディングが始まります。
実装中に、開発者はコードを構築して構成します。テスト中に、テスターは運用環境でコードを試します。展開中にスタッフがソフトウェアのライブ バージョンを展開し、品質保証チームは品質レビューを行い、リリースが規定された要件を満たしていることを確認します。リリースが品質レビューに合格した場合、それは検証され、生産が予定されています。この承認印は、承認されたリリースと呼ばれます。バグが残っている場合、チームはリリースを拒否します。承認されたリリースには展開の詳細を含む展開計画があり、会社は今後のリリースについてクライアントとエンド ユーザーに通知します。トレーニングが必要な場合もあります。
リリース ユニットは、完全な立ち上げのために本番環境にデプロイされます。一部の組織では、ライブでリリースがスムーズに実行されるかどうかを確認するために、この段階で実装を検証することを選択します。
メンテナンス段階では、開発者がリリースのレビューを行い、次のリリースで解決すべき問題をログに記録します。
リリース管理スケジュール テンプレート
すべてのリリース アクティビティのタイムラインを明確にするために、リリース管理スケジュールを作成します。このテンプレートを使用して、主要な成果物と締め切りを追跡し、全員が共通認識を持つことができます。
リリース管理スケジュール テンプレートをダウンロード
名前の内容: デプロイ、リリース、出荷
deploy という用語は、リリースと出荷という言葉と同じ意味で使用されることが多いですが、まったく同じ意味を持つわけではありません。展開とは、サーバー上での新しいバージョンのコードのインストールまたは実行を表します。ソフトウェアを使用して「ライブ」に進みます。この展開は、実稼働サーバーではなく、テスト サーバーで行われる場合があります。リリースとは、この新しいバージョンのソフトウェア形式です。これは、開発者だけでなく、組織内の他のユーザーや顧客を超えたオーディエンスを対象としています。リリースには通常、バージョン番号が含まれます。顧客がリリースを展開する際には、通常、ソフトウェアのインストールと説明されます。出荷とは、建物全体、テスト、展開のループを通してコードを取得するプロセスを説明します。
展開は、ソフトウェア開発のライフ サイクルとリリース管理サイクルの両方で重要なポイントです。展開は、新しいソフトウェア バージョンが使用でき、新しいリリースが公開される瞬間を示します。エディンバラ大学インフォマティクス スクールのポール・ジャクソンの言葉では、展開は「ソフトウェアを開発者の手から、ユーザーの手に渡すこと」です。この段階では、エンド ユーザーにはトレーニングが必要な場合があります。
Jackson は、展開はしばしば問題があると指摘しています:委託ソフトウェアの 50% 以上は、展開に失敗するため、使用されません。展開時にソフトウェアが問題に陥った場合、開発者は問題が解決されるまで前のバージョンに「ロールバック」します。
また、ジャクソンは、委託されたソフトウェアへの支出の 80% が展開時と展開後に発生すると報告しています。もちろん、これは必ずしもデプロイ自体が失敗であるとは限りません。単に、開発における問題は展開時にのみ発生する可能性があります。
しかし、展開が問題となる場合もあります。大規模なシステム リリースでは多くの場合、需要が高いため、顧客は単に製品体験の変更に備えていないかもしれません。ソフトウェアの採用不足は、顧客のハードウェアが新しいリリースに対応できないという他の多くの要因によっても生じる可能性があります。お客様がソフトウェアのインストールに問題を抱えている、トレーニングの欠如によって障害が生じる、または新しいインストールによって顧客の他の既存のソフトウェアが「中断」されるなどです。
デプロイに直接関連する問題の多くは、自動化とトレーニングを使用して解決できるため、エンド ユーザーはシステム互換性などについて考える必要はありません。リリース管理のベスト プラクティスに依存することで、これらのソリューションは標準的な運用手順になります。
リリース展開プロセスとは何ですか?
リリース展開プロセスは、ライブ環境でソフトウェアを運用することに重点を置きます。これを実現するには、ソフトウェアはテストを経て、製品所有者や他のビジネス関係者によって正式に受け入れられなければなりません。展開プロセス中に、ユーザーはソフトウェア アップデートに関するトレーニングを受け、チーム メンバーはパフォーマンスと展開方法の評価またはレビューを行います。
リリース管理のベスト プラクティス
リリース管理では、ベスト プラクティスとは、すでに ITIL を成功に導いた企業によって作成され、洗練されたガイドラインです。このガイドラインは、英国内閣府が所有し、公表しています。ITIL リリース管理プロセスは、宇宙プログラム、医療サービス、銀行、エンターテインメント企業によって優れた成果を得て使用されてきました。ガイドラインは、組織独自の要件と能力を満たすように変更する必要があります。しかし、これらは福音ではなく、出発点のフレームワークであることを覚えておきましょう。
リリース管理は、開発から運用への移行中に最も重要ですが、開発中のリリースの計画から始まります。たとえば、組織全体の変化を監督する変更諮問委員会を設立することをお勧めします。また、SDLC 全体で使用できる単一のリリース管理システムを設計することも賢明です。
同様に、リリース プロセス チェックリストを作成することで、透明性が高まり、リリース管理プロセスとそのビジネス価値がどのように生み出されるかについて共通の理解が得られます。Atul Gawande の著書「チェックリスト マニフェスト」を補足すると、チェックリストを使用すると、特に監視する指標がある場合に、リリース プロセスを制御しやすくなります。さらに、積極的なシニアスポンサーを持つのに役立ちます。
“The most common pitfall with release management is not following a release checklist,” says Chris Harding, a Release Manager at Microsoft. “The details in a release checklist are key. You may be having an off day, or something may distract you while you’re configuring a product, but the checklist never lies,” he points out.
Harding は、業界カンファレンスでの正式なデビューに先立ち、2018 年 5 月に Walmart Canada がウェブサイト上でいくつかのビデオ ゲーム タイトルをリリースした背後に、チェックリストでカバーされていたであろうシンプルなエラーがあったと考えています。「タイミングはおそらく製品ページに対して間違って設定され、一般に公開する前に誰もそれをキャッチしませんでした。医療コミュニティでは、チェックリストが命を救います。リリース管理はそれほど劇的ではありませんが、おそらく仕事を節約できます。
ソフトウェア リリース チェックリスト テンプレート
リリースのすべての活動を追跡するには、チェックリストの使用を検討してください。このテンプレートは Microsoft Word、Excel 形式で利用でき、マーケティング、製品開発、QA、エンジニアリング/DevOps、ユーザーエクスペリエンス、技術サポート、サービス、法的タスクに関するメモとステータスを記載するスペースが含まれています。フォームを編集して、プロジェクトのニーズを反映します。
ソフトウェア リリース チェックリスト テンプレートをダウンロード
ベスト プラクティスの中には、本当に一般的な方法もあります。たとえば、継続的インテグレーションは、エラーをすばやくキャッチすることで、最終的なリリースの品質を向上させます。また、何か問題が発生した場合にトラブルシューティングのために仕事の週に時間が残らないので、金曜日にリリースを立ち上げるのは良い考えではありません。また、トラフィックが少ない期間にリリースをスケジュールする価値もあります。顧客がいつ活動しているかを知る必要があります。問題が発生した場合にダメージ コントロールを改善できます。もう 1 つのオプションとして、一度に少数のユーザーだけが機能を利用できるようにする段階的な展開があります。もちろん、データベースはリリース前にバックアップする必要があります。
最後に、リリース管理プロセスの実装自体がプロセスであることを忘れないでください。リリース管理は反復可能で、自動化は少し一度に達成できます。プロセスを強制しようとしないでください。
リリース管理用ソフトウェア ツール
ソフトウェア ツールは、リリース管理プロセスを迅速化し、促進できます。
たとえば、現代のソフトウェア製品は、インターネット ブラウザからアプリケーション サーバー、オペレーティング システムまで、いくつかのプラットフォームをサポートするように構築されています。そのため、リリース前にこれらの環境でテストする必要があります。テストに必要なすべての環境を作成して維持することは、問題となります。しかし、Selenium や SmartBear などの仮想化されたクラウド サービスを使用することで、テスト用のシミュレートされた環境を作成することで、ターゲット プラットフォームの構成を展開するプロセスを簡素化するという簡単な修正があります。
“A common challenge is automating the release but not having good automated testing in place,” notes Brian White, Senior Solutions Architect at custom software developer Small Footprint. “If you don’t have confidence in the quality of your release, it doesn’t matter how fast it can be deployed if it’s always going to break when someone starts using it,” he says.
リリース管理プロセス全体を容易にするために、GitHub、Jira などのソフトウェア開発プラットフォームとリリース管理システムは、リリースを成功させるために必要なコンポーネントを緊密に統合できます。これらは、リリース計画から運用まで、SDLC 全体で使用できます。
このようなツールは通常、組織のニーズに基づいて拡張性があり、更新機能と管理機能を一元化し、SaaS (サービスとしてのソフトウェア) ツールとしてインターネット上でアクセスできる場合に特に便利です。最適なツールは、管理コンポーネントのテストと展開、変更管理、サードパーティーのサービス管理コンポーネントとの統合にも対応し、エンドツーエンドのデリバリー システムを可能にします。IT サービス管理フォーラム ITIL V3 ガイドラインに準拠したツールを探します。
リリース プロセスの少なくとも部分的な自動化を可能にするツールは、大きな助けになります。本番環境へのソフトウェア デリバリーを自動化したり、承認やオンデマンド展開を伴う半自動化された一連のプロセスを設定したりすることもできます。
その他の便利な機能には、バージョン間の変更を追跡する機能があるため、問題の根本にたどり着き、最後の作業バージョンにロールバックする手間を取る構造が簡単です。今後のバージョンのバックログに移動できるアプリケーション フィードバックのログ記録も役立ちます。
さらに、継続的インテグレーションと継続的展開をサポートできるツールも検討してください。継続的デプロイは、継続的デリバリーを超えて 1 ステップ進み、変更がプロダクション パイプラインを通過するとすぐにデプロイされます。このアプローチは、フィードバック プロセスを加速し、効率を大幅に改善します。
リリース管理指標と KPI
リリース管理プロセスが成熟すると、リリース マネージャーはプロセスの改善を目的としてパフォーマンス指標に注意を向けることができます。それでは、いくつかの方法を見てみましょう。
- リリースのダウンタイム: これは最初の重要な指標です。ソフトウェア リリースではダウンタイムのリスクが発生し、その長さは数分から数時間、さらには数日の範囲です。ダウンタイム自体は悪いことではありません。それは多くの場合、必要です。とは言え、さまざまな種類のダウンタイムを区別できることが重要です。たとえば、推定ダウンタイムとは、必要でリリース スケジュールに組み込まれたダウンタイムであり、リリース後に測定される実際のダウンタイムと比較することをお勧めします。また、予定外のダウンタイムもあり、いくつかのリリースで根本問題が修正されていない兆候である可能性があります。
- リリースの種類と優先度: 各リリースは、メジャー、マイナー、またはその間のどこかに分類され、優先度 (高、中、低) が割り当てられます。多くのリリースで、リリースの種類と優先度別の内訳を見てみましょう。サイズと優先度の両方でリリースを十分に組み合わせる必要があります。同じ製品に対して大きなリリースが多すぎると、品質保証に深刻な問題が発生する可能性がありますが、優先度の高いリリースが多すぎると、チームが常に消火活動に追われて、全員が燃え尽きる傾向があることを示唆しています。
- オンタイム リリース数: オンタイム リリースは保証されていないため、リリースの遅延に関する情報と同じくらいです。収集すべき情報の興味深いナゲットはたくさんあります。たとえば、開発チームの中には、他のチームよりも遅刻や期限内のリリースがある場合がありますか? リリースの優先順位付けに基づいて、遅延または期限内の納品のパターンがありますか? 繰り返し遅延リリースの根本原因は何ですか?
企業レベルでも興味深い指標を追跡できます。これには、プロジェクト、システムの展開、機能という 3 つの異なる観点からエンタープライズ リリースの規模が含まれます。もう 1 つの便利な指標セットは、プロジェクト、システム、機能の範囲を変更した数を追跡します。(スコープ解除とは、リリース予定の何かがリリース ゲートを通過できず、エンタープライズ リリースから取り出され、それを保留しないようにする場合です。)
リリース管理のケース スタディ
これまで多くの理論について説明してきましたが、リリース管理が実際にどのように機能するのか疑問に思うかもしれません。Microsoft は見て素晴らしい場所です。
Microsoft のコア サービス エンジニアリング (CSE) は、継続的インテグレーション、継続的デリバリー、Visual Studio Team Services (VSTS) という名前のクラウドホスト型プラットフォームの組み合わせに依存しています。彼らが「現代のエンジニアリング」と呼んだ開発アプローチは、アジャイル開発と DevOps の両方の原則に基づいています。
Microsoft が継続的デリバリーを中心に開発をどのように構築しているかを見て、リリース管理の改善によってどのようにメリットを得られるかを理解できます。Microsoft ソフトウェア エンジニアは、開発者が後のリリースのフィードバックを収集できる一方で、早期採用者を引き付ける、最小限の実行可能な製品の作成に重点を置いています。
Microsoft 開発者は、いつでもあらゆる展開環境でコードを試すことができますが、コンポーネント化を使用してコードの構築が容易になります。Microsoft のリリース管理プロセスでは、リソースを競合することなく、わずか数分で無人ビルドと無人展開を開始できます。さらに、展開検証プロセスも自動化されています。
CSE はまた、自動化を使用してテスト時間を短縮しながら、反復型設計と迅速なプロトタイピングのアジャイルの原則を採用しています。つまり、CSE はリリース サイクルを高速化し、問題をすばやく修正し、継続的な更新と機能強化をより小さなチャンクで提供でき、最後に各機能の開発に費やす時間が少ないため、リスクも軽減されます。
また、リリース管理のメリットを得られるのはテック企業だけではありません。2008 年から 2010 年の間に、トルコの中央証券保管所の IT 部門は、構成管理、依存関係管理、インフラストラクチャ管理、変更管理、データベース管理、アプリケーション構成管理の広範な自動化を行い、リリースの問題を「完全に削除」し、リリース時間を短縮し、展開関連のエラーを大幅に削減しました。
ユナイテッド航空では、計画、調整、実行、自動化を含む 4 ステップのリリース モデルで、広範なデータから情報を得て、スプレッドシートを中心としたリリース管理から、一元化されたダッシュボード リリースの追跡と管理システムに移行しました。
リリース管理を改善する方法
組織のリリース管理機能を改善するには、リリース管理プロセスの現在の状態を理解する必要があります。これは、定量的にも定性的にも、2 つの方法で行う必要があります。
定量的には、リリースの平均時間、リリースの種類と優先度、エラーの数、遅延リリースの数など、いくつかの基本的な指標を収集する必要があります。これらは両方とも、リリース管理の現在の状態を特定し、パフォーマンス ベースラインを把握するのに役立ちます。
定性的には、リリース管理プロセスの一部である人々、特に開発がオペレーションと結びついている場所で話し、彼らがどう思うかを確認します。数字に現れない現実を指摘できます。
定期的なリリース サイクルを確立することで、リリース管理を管理でき、一貫性を構築するのに役立ちます。(もちろん、これはすべてのリリースで可能になるわけではありませんが、事前に計画された大規模なリリースでは可能です。) 当初から文化を発展させるのではなく、軽量なリリースプロセスを実施します。これにより、リリースのインフラストラクチャを早期に確立し、必要に応じてテストおよび修正できます。
時間が経つにつれ、うまく機能するプロセスが標準的な実践になります。リリース管理に関する最初の調査に基づいて、より厳しい品質要件の適用を開始し、効率ベンチマークを改善できるようになりました。ダウンタイムを排除し、リグレッションのテストを行うことで、リリースがユーザーに与える影響を最小限に抑えることができます。この段階では、テストや検証など、プロセスの規則化と自動化について考え始めることもできます。
本当に協力的なリリース文化の成長には時間がかかり、周りに成長するにはリリース インフラストラクチャが必要です。この文化を育むには、スタッフに投資し、リリース管理プロセス全体を俯瞰できるリリース管理ツールやテクニックに投資します。
コミュニケーションと情報へのアクセスを改善することで、調整が必要になります。ポジティブな期待値を設定することは重要であるため、リリースが良くなるということを人々に知らせます。「チームが直面する課題の 1 つは、リリースを純粋に技術的なハードルと見なし、社内や関係者との良好なコミュニケーションを忘れてしまうことです。これを克服するには、チームの全員が目標とリスクを理解し、驚きを避けるためにエンド ユーザーに変更を伝えるようにします。」と、White of Small Footprint は言います。
リリース マネージャーの仕事
開発者とオペレーションを最終目標に向かって進め、制作の締め切りが楽しそうに聞こえる場合は、リリース マネージャーになることを検討してください。
リリース マネージャーは、プロジェクト、開発方法、インフラストラクチャ、関係者の複雑な状況を把握しながら、企業リリースに貢献するすべての人の取り組みを調整する必要があります。また、リリース マネージャーは、CEO まで、組織内のトップ マネージャーに報告する必要があります (しかし、成熟した組織では、リリース管理はより自律的な機能である可能性が高いです)、リリースがうまくいかないと大きな問題を引き起こします。
Microsoft の Harding 氏は、リリース マネージャーが広範なプロジェクト管理スキルを持つことが重要であると述べています。「他のプロジェクト関係者にトレーニングとアクセス権を提供することは、個人への依存を減らす上で重要です。リリース マネージャーは一般的に、かなり具体的な問題解決スキルを持っていますが、他のPMに頼って製品の構成やプロセスの要素を持つことができます。」と彼は説明します。
では、優れたリリース マネージャーの資質は何でしょうか? 開発と運用の作業、つまり技術的な作業と人々の協力方法の両方に精通しています。仕事、時間、特に人に関しては、優れた管理スキルを持っています。彼らは品質、効率、プロセスに全力を尽くしています。自動化を提唱しており、技術的にはソース コード リポジトリの熟練した演算子である必要があります。また、企業リリースを定義する無数のプロジェクト間、機能間、部門間の依存関係に精通しています。
また、リリース管理について何を信じ (そして何をしないのか) も知っています。
ソフトウェア リリースとリリース管理の神話
リリース管理については、従来の知恵がたくさん浮かんでいますが、その塩分の価値はどれくらいですか? 幸いにも、オランダのユトレヒト大学の 2 人の研究者であるスリンガー・ヤンセンと Sjaak Brinkkemper は、すでにコストと価値を比較して この質問に 答え ようとしています。彼らは、多くの神話や誤解が優勢であることがわかりました。
神話 1: 顧客は最新の状態を保ちたいと考えています。実際、顧客は便利な機能を提供する場合にのみ更新を気にしています。リリースで経験が向上しない場合は、気にしません。
神話 2: 顧客は (ベンダーの観点から) 最新の状態を保つ必要があります。これは、ベンダーが最新バージョンのソフトウェアを使用している顧客に対して顧客よりも気にかけている場合です。すでにお知らせしたように、お客様は古いバージョンを使いたいときに更新し、それ以外の場合は満足し続けます。
神話 3: 最新のリリースは常に最高です。顧客のユース ケースによっては、古い (または古い) リリースがうまく機能するのに対し、新しいリリースでは新しいインターフェイスや新機能の学習に時間を費やす必要があるかもしれません。
神話 4: 修正は次のメジャー リリースまで待ちます。残念ながら、「次のメジャー リリース」は期限内に行うことはめったにありません。そして、最終的に解決するまで、問題はそこに残り、顧客を悩ませます。
神話 5: 回避策は、すべてのコストで避ける必要があります。代替案が新しいリリースへの高価で時間のかかるアップグレードである場合、簡単な解決策を気にしない場合もあります。
神話 6: 顧客は常に新機能を求めています。新しい機能が確立された快適なワークフローの邪魔になれば、彼らはそれらを望んでいません。
神話 7: 多くの場合、リリースは悪いです。外部の顧客に毎回リリースしない限り、頻繁なリリースは有害ではありません。頻繁にリリースすると、フィードバック サイクルが短縮されますが、そのほとんどは社内ユーザーやパイロット顧客に限定されます。
神話 8: 静かな顧客は幸せな顧客です。使用の初期段階でサポートに最も頻繁に連絡を取る顧客が、製品に最も多くのコンテンツを提供していることが証明されます。顧客に手を差し伸べましょう。
神話 9: お客様はリリース ノートを読みます。もちろん、彼らはしません。選択によって制限され、専門ソフトウェアを選択する必要がある場合はそうしますが、特定のクラスの顧客として、彼らが知るために必要なことをまとめたターゲットを絞った情報をはるかに好みます。
神話 10: フィールドに多くの異なるリリースを持つことは悪いです。ベンダーが古いバージョンを使用している顧客に継続的なサポートを提供している場合、これは問題になる可能性がありますが、それでもそれは数字ゲームです。古いバージョンのお客様が少ない場合は、管理できない問題ではありません。
リリース管理スペースの大きなトレンド
アジャイルの実践と自動化は、徐々にリリース管理の中核となる考え方になりつつあります。自動化によってリリース時間が短縮され、エラーのリスクを大幅に軽減できます。アジャイル プラクティスでは、ビルドの自動化、テスト自動化、デプロイの自動化、フィードバックの自動化の採用を推進し、開発チームの負担を軽減します。
「自動化も仮想化/クラウド プラットフォームの使用も、リリース管理におけるもう 1 つのホット トレンドである継続的デリバリーを可能にし、サポートします。」とボーイングのリリース マネージャー、ガブリエル・グティエレスは言います。「継続的なデリバリーにより、新しいソフトウェア改訂のたびに自動的に構築、テスト、展開準備が行われ、アイデアが迅速に現実に変わるのです。継続的なデリバリーにより、展開を頻繁に行えるので、顧客からのフィードバックがより頻繁に行われます。その結果、顧客が必要とし、気にかけている変更を行う場合、すぐに学ぶことで無駄な時間が少なくなります。」と彼は付け加えます。
勢いを増しているもう 1 つの傾向は、GIT、Mercurial、Perforce などの分散型バージョン管理システム (DVCS) を使用することで、チームの共同作業方法を根本的に変えています。DVCS を使用すると、ユーザーはフルバージョンの履歴を含む、自己完結型のリポジトリをローカル コンピュータに保存できます。この機能を使用すると、オフラインで作業し、ローカル セットアップにのみ変更をコミットできます。開発者は中央コードに影響を与えることなく変更を行うことができます。これは実験に最適です。
DevOps の文化と実践は大企業で主流になり、すべての段階の自動化が達成可能な目標になると考えられています。一方、スタートアップ企業は、取得から DevOps 手法の採用を開始する可能性が高いです。これは、DevOps が適切に行われるということは、障害時間の短縮、回復率の高速化、展開の数の増加を意味し、最終的には (非常にコストの高い) ダウンタイムの減少を意味するためです。DevOps の採用が増えるにつれ、ライフサイクルの早い段階で自動化されたテストとパフォーマンス監視が行われ、セキュリティ検証がデリバリー パイプラインの一部となる、左に移行するプロセスも変わるでしょう。
「新しい傾向ではありませんが、技術的な課題から関係者からの期待まで、より頻繁かつ迅速な展開が行われています。」とホワイト・オブ・スモール・フットプリントは付け加えます。「関係者は、展開の可能性とメリットについてより多くの情報を得られるので、リリースの間に数週間待つことに満足しなくなり、開発チームにより頻繁にリリースするよう迫られます。チームがしっかりとした継続的インテグレーション/継続的デリバリー インフラストラクチャを導入しなければ、チームに大きなストレスを与える可能性があります。」と彼は結論付けます。
Quigley 氏は、これらの迅速で明確に定義されたソフトウェア コンテンツの実行に成功するには、「顧客に提供されるイテレーションが増えるので、構成管理と製品の成長の追跡に関するレベルの勤勉さ」が必要であると述べています。
リリース管理に関するその他のリソース
リリース管理のより技術的な紹介については、Jez Humble of ThoughtWorks Studios のこのホワイト ペーパーをご覧ください。そして、それが終わったら、Electric Cloud には詳細を掘り下げるさまざまなリリース管理リソースがあります。
リリース管理を職業として考え、すでに Agire に取り組んでいる場合は、Jan-Erik Sandberg on Agilesight のこの短いコースをご確認ください。また、ITIL の認定を受けるのが良いアイデアだと思う場合は、財団レベルから始めて、公式の ITIL 認定コースを提供しています。
最後に、リリース管理ですぐに手を汚したいだけの場合は、ハーバード・インフォメーション・テクノロジーがどのように行うのかを見てみましょう。
ソフトウェア開発のための Smartsheet によるリリース管理の改善
ニーズに合わせ変化に対応できるようデザインされた、柔軟性のあるプラットフォームで、チームの能力を最大限に引き出しましょう。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。