モダンなCI/CDでは欠かせないワークフローを使った高度なビルド管理

エンジニアのためのCI/CD再入門　第3回

ワークスペースとキャッシュ

　ワークスペースとよく混同しがちなのがキャッシュです。実際、ワークスペースでも依存関係を保存して後のジョブで使い回せばキャッシュと同じようなことができます。

　ではワークスペースとキャッシュはどう違うのでしょうか？ 一言で言うと、ワークスペースは実行中のワークフロー内だけで有効なのに対し、キャッシュはワークフローをまたいで使うことができます。つまり、ワースペースとキャッシュではライフサイクルが異なります。

　英語になってしまいますが、以下の図はワークスペースとキャッシュのライフサイクルの違いを表しています。

workspace_diagram

　ワークスペースが縦（1つのワークフローの上流から下流ジョブ）へ移動するのに対し、キャッシュは横（ワークフローをまたぐ）に移動していることが分かります。

　ワークスペースをキャッシュとして使うと、最低でも1回は依存関係のフルインストールが走ってしまいます。なぜなら、ワークスペースはワークフローが終了されると削除されてしまうからです。対して、キャッシュはワークフローをまたぐので、前のワークフローで一度依存関係をキャッシュしてしまえば依存関係が変わらない限り同じキャッシュを使い回すことができるのでパフォーマンスの面で優れています。

　もしこの2つの違いが分かりにくい時はシンプルに、依存関係のキャッシュにはsave_cacheとrestore_cacheを使い、上流から下流のジョブへファイルを渡したい時はattach_workspaceとpersist_workspaceを使うと覚えておけばよいでしょう。

その他のワークフロー

　ここまで紹介したのとは別の種類のワークフローもあります。スケジュールされたワークフローと承認ワークフローです。

　通常CircleCIのワークフローはVCSへのコードのプッシュをトリガーとして開始されます。スケジュールされたワークフローを使うと、コード変更がなくても決まった時間にワークフローを開始することができます。

workflows:
  version: 2
  nightly-build:
    triggers:
      - schedule:
          cron: "0 0 * * *"
    jobs:
      - build

　上記はスケジュールされたワークフローの例です。実行する時間はPOSIXのcrontabの書式で指定します。上記の例だとnightly-buildというワークフローを毎日0時に実行します。

　他にも手動で承認が必要なワークフローも設定することができます。主な使い所としては、デプロイジョブを承認が必要なようにして、ある権限を持ったユーザーしかデプロイを行えないようにする方法です。

workflows:
  version: 2
  test-and-lint:
    jobs:
    ...
    - deploy:
        type: approval
        requires:
        - run_test
        - run_lint
        - precompile

　この例だとdeployジョブがtype: approvalになっているので、依存するジョブがすべて完了しても承認されるまで開始されません。実際にワークフローの画面を見ると”ON HOLD"というステータスで止まっていることが分かります。

on_hold