リリース管理アプローチ

アプリケーションのリリースモデル、開発手法、組織の文化などによって、組織がソフトウェアを本番環境に展開するプロセスや時間枠に違いが見られます。 組織によっては、業界および規制のコンプライアンスによって新機能を本稼働に移行するのに時間がかかる場合があります。 よりアジャイルなデリバリーモデルをサポートするために、自動テストやコード移行テクノロジーを導入している組織もあります。

組織は、アプリケーション機能を競合他社よりも早くエンドユーザーや顧客にリリースする経済的なメリットを認識しています。 多くの組織では、ソフトウェアデリバリーのライフサイクルを簡素化するためにDevOpsアプローチを導入しています。 DevOpsは、高品質なソフトウェアを自動化されたアジャイルな方法でエンドユーザーに提供するために、開発、品質、および業務の各スタッフのコラボレーションです。 新しいアプリケーション機能を継続的にエンドユーザーに提供することで、組織は市場での競争力を高めることができます。 DevOpsは文化や考え方を大きく変えるものであるため、すべての組織がすぐにDevOpsを導入できるわけではありません。

以下に示すのは、プロジェクトのテクニカルリードとしてのタスクです。

1. 組織の既存のリリース管理プロセスとツールを評価します。 組織によっては、すでに完全に自動化されたリリースパイプラインを使用している場合もあります。 また、制限付きの自動テストや、環境間でソフトウェアを移行するためのスクリプトを使用している場合もあります。 さらに、すべてのリリース管理タスクを手動で行う場合もあります。
2. 組織のリリース管理プロトコルに従って、テストと本番のデプロイメントを通してアプリケーション機能の移行を実現するリリース管理戦略を設計します。
3. テストプロセスをはじめ、時間をかけてリリース管理プロセスを自動モデルに進化させます。 この進化速度は、アジャイルな方法を導入し、自動テスト、ソフトウェア移行ツール、および共有リポジトリに依存する組織の準備状況によって異なります。

自動化された方法でソフトウェアをリリースしていても、ほとんどの組織には、手動（または半自動）のリリースパイプラインがあります。 

次の図で「+」アイコンをクリックすると、DevOpsパイプラインの詳細が表示されます。

変更管理プロセスやガバナンスを重視してソフトウェアをデプロイする組織では、古いやり方との戦いになります。 これらのプロセスを自動化するメリットを説明したうえで、完全に自動化されたデリバリーモデルへの移行には時間がかかることを説明します。 最初の手順で、テストを中心とした手動プロセスが有効であることが実証済みであることを確認します。 次に、時間をかけて少しずつ自動化することで、完全に自動化されたパイプラインが完成します。

DevOpsパイプラインは、継続的な統合、継続的なデリバリー、継続的なデプロイメントの各ステージと自動プロセスで構成され、アプリケーションを開発からテスト、デプロイメントまで迅速に移行します。 

DevOpsについて議論する場合、継続的な統合、継続的なデプロイメント、継続的なデリバリーという用語がよく使われます。

これらの用語は、以下のように定義されます。

• 継続的な統合 – 1日に何度も共有リポジトリに継続的に統合する
• 継続的なデリバリー – いつでも出荷の準備が整っている
• 継続的なデプロイメント – 継続的にデプロイまたは出荷する（手動プロセスは含まない）

自動デリバリーパイプラインでは、テストプロセスの自動化と検証が不可欠です。 Pega Platform機能と業界のテストツールを使用して、自動テストスイートを作成し、進化させます。 それ以外の場合、より高度な環境へのコードの昇格を自動化し、エンドユーザーが見つけたバグの修正にコストがかかる可能性があります。

DevOpsパイプラインの詳細については、「DevOps release pipeline overview」を参照してください。