デプロイジョブとは？pipelineからコードを出荷する

デプロイジョブとは、buildされたartifactを受け取り、stagingや本番などのターゲットenvironmentへリリースするpipelineのjobです。

buildとtestのjobはコードを準備します。デプロイジョブは実際にそれを出荷します。これはpipelineの一部で、コンテナイメージをpushしたり、ファイルをサーバーにコピーしたり、クラウドサービスを更新したり、インフラの変更を適用したりします。稼働中のシステムを変更するため、デプロイジョブはより大きなリスクを伴い、通常はその周囲に追加のガードレールが設けられます。

デプロイジョブが行うこと

pipelineの前段で生成されたartifactを受け取り、environmentへ適用します。イメージをregistryへpushしてロールアウトする、データベースのmigrationを実行する、deployツールを呼び出す、などです。ターゲットは通常名前付き（staging、本番）で、pipelineが何がどこにあるかを追跡できるようになっています。

deploy jobがbuild jobとどう違うか

単なるworkspaceではなく、名前付きのenvironmentを対象とする。
承認や保護されたenvironmentのルールをしばしば必要とする。
特定のbranchやtagに制限されることが多い。
同時deployを避けるため、1つずつ実行されることがある。

簡単な例

deploy jobは、新しいコンテナをロールアウトするためにkubectl set image deployment/app app=registry/app:${SHA}を実行したり、最新のbuildをリリースするためにプラットフォームのCLIを呼び出したりします。${SHA}は、deployをbuildおよびtestされた正確なcommitに結びつけます。

deployのガードレール

deployは本番を変更するため、チームは承認、environmentの保護、並行性の制限を追加します。rollback経路は不可欠です。deploy jobが不良なbuildを出荷した場合、rollback jobが以前のバージョンを素早く戻せるべきです。

deploy jobと信頼性

途中で失敗するdeployは、まったく始まらなかったものより悪いです。信頼できるdeploy jobは冪等で検証可能であり、デプロイ後チェックで新バージョンが健全であることを確認します。安定したrunnerはdeploy途中の中断を減らします。マネージドrunner（Latchkey）は一時的なインフラの不調をリトライするため、deployがあなたのコードとは無関係な理由で失敗する可能性が下がります。

重要なポイント

デプロイジョブは、buildされたartifactを名前付きのenvironmentへリリースします。
build jobより大きなリスクを伴うため、承認と保護が設けられます。
rollback経路とデプロイ後のヘルスチェックと組み合わせましょう。