継続的配信のワークフロー

次の図は、継続的配信プロセスに関する手順をまとめたものです。このプロセスは複数の異なるアクティビティで構成されており、各アクティビティは統合されています。プロセス内のアクティビティをすべて採用すると、効率、有効性、および品質の面で大きなメリットを得られますが、必ずしもすべて採用する必要はありません。代わりに、このプロセスのアクティビティを一度に 1 つだけ採用し、各アクティビティを追加して他のアクティビティと統合していくことにより、各アクティビティから得られる利点を活用することもできます。

継続的配信は事実上、継続的インテグレーション プロセスの拡張であるため、この図の最初の 5 つの手順は、「継続的インテグレーションのワークフロー」で示した図の手順と同じです。

上図内の数字の箇条書き箇所の詳細は次のとおりです。

1. 開発者はコードをチェックアウトしてプライベート ワークスペースにチェックインします。その後、変更を加えてローカルでテストします。
2. 完了後、開発者はソース管理リポジトリへの変更をチェックインします。
3. CI サーバーはソース管理リポジトリを監視し、変更を検出すると、関連するソースのビルドをトリガーします。
4. ビルドが成功すると、CI サーバーは以下のアクティビティを一部またはすべて実行します。
   • ディプロイ可能な成果物をテストで利用できるようにする
   • 作成されたばかりのコードのバージョンにビルド ラベルを割り当てる
   • 関連するチーム メンバーに、ビルドが正常に生成されたことを通知する
   • 単体テストおよび統合テストをトリガーする

   この時点で、手順 2 でチェックインされた変更が正常にビルドされ、ビルドに使用されたソース コードにビルド ラベルが適用されています。そのため、必要に応じてビルドを再作成できます。

   ビルドに失敗した場合、CI サーバーは手順 1 からのプロセスを再開する関連開発者に通知を送ります。開発者はビルド エラーを解決するために必要な変更を行います。

5. 単体テストおよび統合テストが行われた後、関連するチーム メンバーにテスト結果が通知されます。

   この時点で、手順 2 でチェックインされた変更は正常にビルドされテストが完了しています。手動の作業はほとんどあるいはまったく不要です。

6. 単体テストおよび統合テストが正常に完了すると、CI サーバーはより包括的で自動化された受け入れテストの実行をトリガーします。
7. 受け入れテストにすべてパスした場合、リリースするかどうかが決定されます。

   受け入れテストに失敗した場合、CI サーバーは手順 1 からのプロセスを再開する関連開発者に通知を送ります。開発者は、テストの失敗を解決するために必要な変更を行います。

8. 検証の決定がリリースされる場合、リリース管理がトリガーされます。これにより、ビルドされたパッケージが適切な環境にリリースまたはディプロイされます。

   検証の決定をリリースしない場合は、関連するチーム メンバーに通知され、開発作業は通常どおり継続されます。

Jenkins を使用して上記リストの CI サーバー タスクを実行する方法については、「Enterprise Developer および Jenkins の連携」を参照してください。