--- title: "Datadog Synthetic テストを CI/CD パイプラインに組み込む" description: "Datadog Synthetic テストを CI/CD パイプラインに追加し、ユーザーに影響が及ぶ前に問題を把握します。" author: "Betsy Sallee, Margot Lepizzera" date: 2020-08-11 tags: ["synthetic monitoring", "synthetics", "digital experience monitoring", "ci/cd"] blog_type_id: the-monitor locale: ja --- [シフトレフトテスト](https://en.wikipedia.org/wiki/Shift-left_testing)とも呼ばれる CI/CD パイプライン内のテストは、開発プロセスの各段階でアジャイルチームが新機能の実行可能性を継続的に評価できるようにする DevOps のベストプラクティスです。早期かつ頻繁にテストを実行することで、ユーザーに影響を及ぼす前に問題を特定しやすくなり、技術的な負債を減らし、効率的なチーム間の連携を促進できます。 [Datadog Synthetic CI/CD テスト]()は、シフトレフトテストに柔軟なアプローチを提供し、任意の時点で既存の Datadog Synthetic テストを CI/CD パイプラインに組み込むことができるため、肯定的なユーザー体験を保つことやダウンタイムを最小限に抑えることができます。カナリアテストや CI 環境でのテストなど、さまざまなテストシナリオに単一の Synthetic テストスイートを使用できるため、環境固有のテストをする必要がありません。スケジュールされたテストは実環境に対しても予定どおりに実行されますが、この同じテストを、開発プロセスの各段階で適切な調整を加えつつ、オンデマンドで実行することもできます。 ## CI パイプラインで Synthetic テストを実行し、問題を早期検出 [アジャイル開発手法]() の人気が高まるにつれ、継続的なインテグレーションテストは健全な実環境を維持するのに欠かせないものとなりました。アジャイルチームは新機能やアプリケーションの改善を頻繁にデプロイするため、企業はこの急速な展開でレグレッションが起こらないようにすることが重要です。そのため CI パイプラインで実行されるテストは、コード変更によりユーザー体験が低下しないことを、迅速に変更を送り出すチームの能力を妨げることなく検証する必要があります。 従来、エンドツーエンドテストは、コードを日常的に出荷するチームの CI パイプラインで実行するには、あまりにも脆くて時間がかかるものでした。その点、Datadog Synthetic テストは、[信頼性](https://www.datadoghq.com/blog/test-maintenance-best-practices.md#reduce-test-flakiness-with-reliable-locators-and-alerts) と効率性を念頭に設計されています。Synthetic テストは UI の変更に応じて自動的に更新され、待機および再試行メカニズムを採用して失敗が正当なものであることを確認します。また、Synthetic CI/CD テストは順次ではなく同時に実行されるため、開発プロセスをスローダウンさせることはありません。 Datadog は、[GitLab](https://docs.datadoghq.com/integrations/gitlab.md)、[Jenkins](https://docs.datadoghq.com/integrations/jenkins.md)、[Azure DevOps](https://docs.datadoghq.com/integrations/azure_devops.md) といった一般的な CI ツールと統合されているため、Datadog プラットフォーム内のパイプラインからイベントを収集できます。Synthetic CI/CD テストは、さらに一歩踏み込み Synthetic テストを CI パイプラインに組み込むことで、問題の早期発見を可能にします。以下のスクリーンショットのように、CI 内で実行される Synthetic CI のテスト結果を表示することもできます。 ![CI/CD プラットフォームでテスト結果を視覚化。](https://web-assets.dd-static.net/42588/1776294324-datadog-synthetic-ci-cd-testing-synthetic-tests-in-gitlab.png) *CI/CD プラットフォームでテスト結果を視覚化します。* Synthetic テストは既存のワークフローにシームレスに追加することができます。CI ビルドプロセスの一部として、[トリガーエンドポイントとポーリングエンドポイントへリクエストを送信する](https://docs.datadoghq.com/synthetics/ci.md?tab=npm#api-usage)方法か、[npm パッケージをインストールして関連する CLI を使用する](https://docs.datadoghq.com/synthetics/ci.md?tab=npm#cli-usage)方法があります。CLI は、レポジトリで実行するテストを自動検出し、テストを実行し、結果を取得し、CI 環境で主要な Synthetic テストが失敗した場合は開発パイプラインをブロックします。これにより、ブレーキングチェンジがステージング環境や実環境に影響するのを防ぎ、実行可能なコードのみがパイプラインを通過するセーフティーネットを作成することで、アプリケーションのコア機能を保護します。 ![実行規則を構成し、ブレーキングチェンジによる実環境への影響を阻止。](https://web-assets.dd-static.net/42588/1776296644-datadog-synthetic-ci-cd-testing-execution-rules.png) *ブレーキングチェンジが実環境へ影響を及ぼさないように、実行規則を構成します。* この同じ CLI ツールを使用して、フロントエンドの JavaScript ソースマップをアップロードでき、Datadog RUM で収集するフロントエンドエラーをより意味のあるものにできます。たとえば、[エラー追跡](https://www.datadoghq.com/blog/error-tracking.md)を使用して、最初にエラーが発生した時間、原因となったコード行、最新のリリースで修正されたかを調査できます。 ## デプロイ時に Synthetic テストを実行し万全を期す 開発サイクルをとおして Synthetic テストを実行するだけでなく、Datadog Synthetic CI/CD テストを使用して CD プロセスの一部としてテストを実行することもできます。デプロイが完了した直後に運用アプリケーションの状態を評価することで、ユーザーに影響を及ぼす可能性のあるレグレッションを検出し、重要なテストが失敗した際にロールバックを自動的にトリガーできます。この機能は特に、開発から運用までの機能を所有し、ダウンタイムのリスクを負うことなく頻繁にデプロイしたい高度にアジャイルな開発チームに有用です。 Synthetic CI/CD テストは、[カナリアデプロイ](https://dev.to/mostlyjason/intro-to-deployment-strategies-blue-green-canary-and-more-3a3)の自動安全対策として利用できます。たとえば、特定の場所のユーザーグループに新機能をデプロイする場合、変更が反映された直後にその場所の実環境に対して Synthetic テストを実行できます。それから API ポーリングエンドポイントを使用して、カスタム Webhook へテスト結果を送り、失敗した場合に自動ロールバックをトリガーし直近の安定した状態に戻すことができます。 ## すべての環境にカスタマイズ可能な単一のテストスイートを使用 Datadog Synthetic CI/CD テストはパラメーターからテストを抽象化し、CI/CD パイプライ内だけでなく、認証やネットワークへの直接アクセスを必要とするあらゆる環境で、既存の運用レベルのテストスイートを活用できるようにします。このような Synthetic テストの柔軟性により、開発の各段階で個別のテストシナリオを維持する必要がなくなるため、開発、運用、QA、製品チーム間のサイロ化が解消されます。一度のテストスイートの作成で、すべてのユースケースに対応できます。 Synthetic CI/CD テストでトリガーされる Synthetic テストは、デフォルトで実環境と同じ構成に従い実行されます。ただし、それぞれの環境の特別なニーズに応じてオーバーライドを指定することができます。これは、グローバルコンフィギュレーションファイル（以下のコードスニペットの `global` セクション参照）内のテストスイート全体に対しても、個々のテストレベルに対しても、行うことができます。 ```json { "apiKey": "", "appKey": "", "global": { "basicAuth": { "username": "bits", "password": "labrador" }, "startUrl": "{{URL}}?static_hash={{STATIC_HASH}}", }, "proxy": { "host": "127.0.0.1", "port": 3128, "protocol": "http" } } ``` たとえば、テスト環境がプロキシや基本認証システムの背後にある場合、運用レベルのテストを複雑にしすぎることなく、オーバーライドを使用して CI テストに特異性を加えることができます。また環境変数を使用して、テストの `startUrl` のオーバーライド値をダイナミックに設定することもできます。たとえばエンジニアが PR を開くたびに、パイプラインがステージングのために静的ハッシュを生成する場合、上記のように、その静的ハッシュをダイナミックに `startUrl` パラメーターに取り込むことができます。カスタマイズ可能なパラメーターの一覧は、[ドキュメント](https://docs.datadoghq.com/synthetics/ci.md?tab=npm#configure-tests)を参照してください。 ## システム全体のトラブルシューティングを左にシフト Synthetic テストで問題が浮上した場合、テストを実行した環境やスタック内の問題の発生場所にかかわらず、ユーザーが簡単にトラブルシュートできることが重要です。[Datadog Synthetic モニタリング](https://www.datadoghq.com/blog/introducing-synthetic-monitoring.md) を使用すると、あらゆる環境のテスト結果とともに豊富なコンテクストデータを Datadog UIで表示できます。 ![Datadog UI ですべての環境のテスト結果を表示。](https://web-assets.dd-static.net/42588/1776296656-datadog-synthetic-ci-cd-testing-side-by-side-tests-in-ui.png) *Datadog UI ですべての環境のテスト結果を表示します。* CI/CD パイプラインで実行されるテストは、運用レベルのテスト実行と同じレベルのコンテキストを持つため、関連するエラーメッセージ、リソース、スクリーンショットを使用して、開発サイクルのどの段階でも不具合を起こした場所を正確に把握することができます。また、 Synthetic モニタリングは [APM](https://www.datadoghq.com/product/apm/) と緊密に連動しているため、それぞれのテスト実行はアプリケーションとインフラストラクチャーからのメトリクス、トレース、ログと自動的に相関し、コンテキストを切り替えることなく効率的な調査を行うことができます。 ![それぞれのテストに関連するメトリクス、トレース、ログを表示。](https://web-assets.dd-static.net/42588/1776296660-datadog-synthetic-ci-cd-testing-test-results-ui.png) *View metrics, traces, and logs that are relevant to each test.* ## Synthetic CI/CD テストの概要 Datadog Synthetic CI/CD テストは、CI/CD パイプラインの任意の場所で既存の Synthetic テストスイートを活用できるため、問題を早期に発見し、安全なデプロイを実行し、ユーザーに最高のエクスペリエンスを届けることができます。すでに Datadog をご利用のお客様で、Datadog Synthetic テストをご利用中の CI/CD パイプラインに拡張する方法については、[ドキュメント]()を参照してください。Datadog を初めてご利用になる場合は、をご利用ください。