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

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

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

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

  1. Developers check out code into their private workspaces. They then make their changes and test them locally.
  2. When done, developers check in their changes into the source control repository.
  3. The CI server monitors the source control repository and when it detects a change it triggers a build of the relevant sources.
  4. After a successful build, the CI server performs some or all of the following activities:
    • makes deployable artefacts available for testing
    • assigns a build label to the version of the code that was just built
    • notifies the relevant team members that a successful build occurred
    • triggers unit and integration testing

    At this point, the changes that were checked in at step 2 have been successfully built and a build label has been applied to the source code that was used for the build, meaning that the build could be recreated if necessary.

    In the event of a build failure, the CI server sends notifications to the relevant developers who restart the process from step 1 to make the changes necessary to resolve the build errors.

  5. After the unit and integration testing has taken place, the relevant team members are notified of the test results.

    At this point, the changes that were checked in at step 2 have been successfully built and tested, all with little or no manual intervention.

  6. After the unit and integration testing has completed successfully, the CI server triggers the running of more comprehensive, automated acceptance tests.
  7. If the acceptance tests all pass, a decision is made whether or not to release.

    If the acceptance tests result in failures, the CI server sends notifications to the relevant developers who restart the process from step 1 to make the changes necessary to resolve the test failures.

  8. If the validation decision is to release, release management is triggered. This results in the built package being released or deployed to the appropriate environment.

    If the validation decision is not to release, the relevant team members are notified and development work continues as normal.

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