🎃

CircleCIのMakerを活用してもらいたい

に公開
CircleCI
CI/CD
DevOps
monitoring
metrics
tech

はじめに

少し前になりますが、2025年度のDevOpsDays Tokyoに参加し、「CI/CDの成功の指標になる4つのKeyメトリクス」について発表しました。CI/CDの指標になるメトリクスやそのモニタリングについてお話しできる場であり、個人的には嬉しいテーマでもあります。

その中で「CircleCIの場合はInsight機能でもデフォルトで充実したダッシュボードを持っているので楽ですよー」と話しておりましたが、、、こちらはあくまでパイプライン全般のデータを表示することに特化しており、デプロイの可視性を確保するにはもう一つ工夫が必要だと感じておりました。

そこで今回紹介するのが、デプロイの可視性を確保するためのDeploy Markersという機能です。

そもそも「4つのKeyメトリクス」とは？

DevOps全体のキーメトリクスとしてGoogle CloudのDORAチームが提唱している「Four Keys」は、以下のDevOpsの主要指標として広く受け入れられています。

  • 変更リードタイム（Lead Time for Changes）
  • デプロイメント頻度（Deployment Frequency）
  • 変更失敗率（Change Failure Rate）
  • 復旧時間（Time to Restore Service）

しかし、これらはDevOps全般の指標であるため、CI/CDのように個別要素として影響度が大きいツールの指標としては設定しづらい問題があります。例えば、デプロイメント頻度を向上させるとしても、そのためにCI/CDパイプラインのどの部分がボトルネックで改善すべきかが、総合的な指標だけでは判断しにくいという課題があります。

そこで注目したのが、CI/CDに特化した「4つのKeyメトリクス」です。これはCircleCIが毎年発表している「State of Software Delivery」を基に作成されており、1,400万件のデータポイントに基づいたCI/CDのベンチマークを提供しているようです。嬉しいことに、最新の2025年版は、メールアドレスなどの情報を求められることなく、そのままダウンロードできるようになっています！

こちらの指標ではFour Keysに関わりを持ちながら、パイプラインが十分に最適化されたと判断するためにCI/CDの主要指標を以下のように紹介しています。

  • 実行時間　ワークフローの実行にかかる時間の長さ
  • スループット　1日あたりの平均ワークフロー実行回数
  • 成功率　一定期間における成功した実行回数を合計実行回数で割った値
  • 復旧時間　障害発生から次の成功までの平均時間

こちらの項目をモニタリングし、パイプラインを継続的に改善することは非常に重要で、それぞれのCI/CDプラットフォームでは何かしらの組み込み分析基盤を提供していることが多いです。

CircleCIでは以前よりInsight機能によりプロジェクト・ブランチレベルまで各種メトリクスの取得が可能になっており、ユーザーのモニタリングをサポートしておりました。しかし、デプロイに関わるパイプラインを確認するのは難しく、復旧時間のモニタリングはInsight機能だけではやや足りていないこともあります。そこで必要になるのが今回ご紹介するMarkerの話です。

CircleCIのデプロイ機能のおさらい

CircleCIを既にお使いの方は気づいているかもしれませんが、Web UIトップページの左にはDeploysという専用タブが存在しています。こちらは、以前はKubernetesクラスター専用の機能で、UIのみでリリース管理をするために利用されていた機能でした。リストアやカナリアリリースなどにも対応した優れものです。(本ブログではKubernetesに対応する機能の詳しい説明は割愛しますので、気になる方は公式Docsをどうぞ！)

一方で、デプロイ環境がKubernetes以外の場合は絵に描いた餅の状態で、デプロイを行っているパイプラインがどこにあるのかを集約できるページがありませんでした。そこで最近リリースされたのが、デプロイ環境に依存せずに情報を集約できる「Deploy Markers」です。

Markerの世界

CircleCI Deploy Markersは、CI/CDパイプラインにおけるデプロイ活動を自動的に追跡・記録する機能で、すべてのデプロイを一箇所で管理し、各デプロイがどのパイプラインによってトリガーされたかを明確に把握できます。

これによりいくつかのメリットが生まれますが、箇条書きで表現すると以下の通りです：

  • 一元的な可視性　全体的なデプロイ状況を一箇所で統合管理できる
  • 迅速な障害対応　最新の履歴と関連パイプラインを即座に確認でき、障害時に迅速な対応ができる
  • データ分析基盤　プロセス改善のためにデプロイパターンの分析基盤として利用できる
  • 導入の簡便性　自動的にマーカーが生成され、複雑な設定なしですぐに使用できる（自動検出時）

つまり、Deploy Markersは従来の分散したデプロイ情報を一元化する実用的なソリューションです。継続的なモニタリングを通じて、チームは運用効率を向上させることができます。デプロイの透明性とモニタリング体制を向上させることで、チームのDevOps文化の成熟に役立つものだと考えております。

Markerの実装方法

Deploy Markersには大きく自動検出と手動設定の2つの実装方式があります。いずれもCircleCIの挙動を定義するconfig.ymlの中で定義することができ、ジョブ名または、専用のコマンドによって制御できます。

1つ目は自動検出方式で、基本的にはジョブ名に'deploy'という単語が含まれている場合、CircleCIが自動的にDeploy Markerを生成します。この方式は追加設定が不要で、既存のパイプラインに最小限の変更で導入できるため、手軽にデプロイ追跡を開始したい場合に最適です。自動検出方式でMarkerを生成する基準の詳細は公式Docsにて確認できます。

サンプル1: 自動検出方式のconfig.ymlファイル
version: 2.1

jobs:
  # This job will automatically create a deploy marker because its name contains 'deploy'
  deploy-auto-marker:
    docker:
      - image: cimg/base:2023.03
    steps:
      - checkout
      - run:
          name: "Preparation stage"
          command: echo "Starting deployment preparation."
      - run:
          name: "Deployment simulation"
          command: |
            echo "Simulating deployment process..."
            sleep 3  # Simulating deployment time
      - run:
          name: "Deployment complete"
          command: echo "Deployment completed successfully."

workflows:
  auto-deploy-marker:
    jobs:
      - deploy-auto-marker

2つ目は手動設定方式で、各ステップの中で関連コマンドを使用して明示的にマーカーを作成し、デプロイの各段階で詳細な状態更新を行うことができます。この方式では環境名、コンポーネント名、バージョン情報などを詳細に指定でき、より細かい制御が可能です。以下の例では成功・失敗・キャンセル時の分岐を作成して、色んな状況を想定して作成しています。

サンプル2: 手動設定方式のconfig.ymlファイル
version: 2.1

jobs:
  manual-marker-deployment:
    docker:
      - image: cimg/base:2023.03
    steps:
      - checkout
      
      # Record deployment plan
      - run:
          name: "Create deployment plan"
          command: |
            circleci run release plan \
              --environment-name=poc-environment \
              --component-name=poc-component \
              --target-version=${CIRCLE_SHA1::10}

      # Deployment stage
      - run:
          name: "Execute deployment"
          command: |
            echo "Executing actual deployment..."
            sleep 5

      # Record deployment start
      - run:
          name: "Update deployment to running"
          command: |
            circleci run release update --status=running

      # Validation stage
      - run:
          name: "Validate deployment"
          command: |
            echo "Validating deployment result..."
            sleep 3

      # Record deployment completion
      - run:
          name: "Update deployment to complete"
          command: |
            circleci run release update --status=SUCCESS
          when: on_success
      
      # Record deployment completion
      - run:
          name: "Update deployment to failed"
          command: |
            circleci run release update --status=FAILED
          when: on_fail

  cancel-deployment:
    docker:
      - image: cimg/base:2023.03
    steps:
      - run:
          name: Update planned release to CANCELED
          command: |
            circleci run release update --status=CANCELED

workflows:
  manual-deploy-marker:
    jobs:
      - manual-marker-deployment
      - cancel-deployment:
          requires:
            - manual-marker-deployment:
              - canceled

実行結果を確認すると、、

まずは、CircleCIのWebページからDeploysのタブをクリックします。Markerが設定されたパイプラインはこちらのページに表示され、最近のデプロイ履歴とそれに紐づくパイプラインもリンクされていることが分かります。

手動設定方式を利用する場合、どの環境であるかを明示的に指定することができます。これを活用することで、特定の環境に関するデプロイ情報のみを閲覧することも可能です。

表示されているデプロイに関連付けられているパイプラインをクリックすると、デプロイが実行されたジョブページに直接移動できるので、デプロイ履歴と実行したジョブの関連性を簡単に追跡できます。

まとめ

さて、今回はCI/CDパイプラインのメトリクスに関する考察から、CircleCI Deploy Markersについて、実装方法から実際の使用感まで紹介してきました。

Deploy Markersの良いところは、自動検出なら既存のパイプラインにほぼ変更なしで導入できる手軽さと、手動設定なら細かい制御ができる柔軟性の両方を備えていることです。チームの運用スタイルに合わせて選択できるのは嬉しいポイントですね。

複数のプロジェクトやマイクロサービスを抱えている組織では、「あれ、このサービスっていつデプロイしたっけ？」みたいな状況が結構あると思います。Deploy Markersを使えば、そんな悩みから解放されて、もっと本質的な改善活動に時間を使えるようになるはずです。

みなさんもぜひ一度試してみてください！きっとデプロイの見通しが良くなって、チーム全体の安心感も向上すると思いますよ。

Discussion