はじめに
ソフトウェア開発におけるテストは、従来、本番環境へのデプロイとは別の開発環境およびステージング環境に限定されています。この距離を置く理由は、本番トラフィックと並行してテストを実行することによるパフォーマンスへの影響を最小限に抑え、破壊的な変更が本番環境に影響を与える可能性を減らすためです。
これらの懸念にもかかわらず、本番環境内で部分的なテストを完了するという動きが広がっています。本番環境でのテストまたはTIPとして知られるこの戦略は、チームが新しいコードが互換性を持つ必要のある実際のシステムおよびデータとどのように相互作用するかをより深く理解するのに役立ちます。
このガイドでは、本番環境でのソフトウェア変更のテストというアイデアを探ります。本番環境でのテストへの抵抗の歴史的理由、採用をより魅力的にした変更、およびそれが開発速度とエラー削減にもたらす可能性のある利点について説明します。
Prismaデータプラットフォームは、本番環境でのデータベースへのアクセスを簡素化するのに役立ちます。データベース接続の管理にPrisma Clientを使用している場合、Prismaデータプラットフォームは、本番環境のワークロードをより簡単に管理するのに役立つ場合があります。
本番環境でのテストとは？
本番環境でのテストは、開発者がソフトウェアテストの一部または全部を、コードが本番環境にデプロイされるまで延期することを推奨する考え方です。しかし、なぜチームは本番環境でのテストに移行したいのでしょうか？
一見すると、このアイデアは直感的ではなく、危険でさえあるように思えるかもしれません。当然のことながら、リスクがないわけではありません。ただし、ソフトウェアをより徹底的にテストするだけでなく、より回復力のある本番環境を構築できるようにするデプロイおよびテスト戦略を導入することで、多くの危険を排除できます。
本番環境でのテストが価値があるのは、本番環境とテスト環境間の環境ドリフトが原因で発生する問題のカテゴリを排除するためです。専用環境でテストしてから、合格したコードを本番環境にデプロイして、その動作が一貫していることを期待するのではなく、コードが実行される必要のある場所でテストします。
本番環境でのテストの考え方を採用する人の焦点は、次のように要約できます。
- できるだけ早くコードを本番環境にデプロイする：これにより、チームはコードを実行する必要のある環境内で早期にテストできます。
- コードのデプロイとコードのリリースを分離する：デプロイプロセスを変更のリリース行為から分離することで、新しい機能をテストおよびアクティブ化する際の柔軟性が向上します。
- 実際のデータでテストする：データベースのモックまたはスタブ、およびダミーレコードで埋められたデータベースは、コードが対応する必要のあるデータを正確に複製することはできません。
- 変更の影響範囲を最小限に抑える：テストおよびリリース中にスコープを制限および調整できる場合、変更をより安全かつ効果的にテストできます。
本番環境でのテストに関連するリスクは何ですか？
多くの人は、本番環境でのテストの利点がコストを上回る可能性があるかどうか懐疑的です。先に進む前に、この戦略のリスクと、それらを軽減する方法について説明しましょう。
欠陥のリスク
本番環境でコードをテストする際の主な懸念事項は、ユーザーやサービスに影響を与える可能性のあるソフトウェアの欠陥を導入する可能性です。従来のソフトウェアテストパイプラインの背後にある考え方は、コードを本番環境の責任に昇格させる前に、コードを徹底的に検証し、既知の脆弱性をチェックすることです。
この視点にはメリットがありますが、実際には状況がそれほど明確ではないことがよくあります。組織がステージング環境で実行するテストは、コードが本番環境で処理するものと必ずしも一致しません。インフラストラクチャやワークロードを含む環境の複製は簡単な作業ではなく、実際の運用システムと同期しなくなることがよくあります。
この結果、ステージング環境でテストしたものが、リリース後のコードのパフォーマンスに実際には適用できない可能性があります。さらに、成功するかどうかにかかわらず、試行には多大な労力、時間、およびインフラストラクチャが必要です。
ライブシステムへの影響
密接に関連する懸念は、新しい変更とテストプロセス自体が本番環境に与える可能性のある影響です。システムの安定性は、サービスのユーザビリティと可用性に影響を与え、ユーザーの信頼を損なう可能性があるため、ほとんどの組織にとって優先事項です。
本番環境にデプロイされたコードは運用に影響を与える可能性がありますが、潜在的な影響を最小限に抑える方法があります。新しいコードが受信するトラフィック量を制限する制御の実装、アクティブスタンバイインフラストラクチャのセットアップ、および監視ベースのスケーリングの実装は、このプロセスをより安全にする方法のいくつかです。これらの種類の軽減策の素晴らしい点は、これらの投資が、あらゆる種類のシステム障害に対する本番システムの回復力を直接的に向上させることです。
本番環境でテストする方法
本番環境でのテストは実際にどのように機能するのでしょうか？このセクションでは、組織が本番環境でコードを確実にテストするために実装する最も一般的な手法と戦略のいくつかについて説明します。これらのアイデアをすべて採用する必要はありませんが、これらのアプローチの多くは互いに補完し合い、より包括的なシステムの一部として統合できます。
機能フラグシステムを実装する
機能フラグは、機能を外部から簡単にアクティブ化または非アクティブ化できるようにするプログラミングおよびリリース手法です。基本的な考え方は、新しい機能を、実行前に構成変数の値をチェックする条件付きロジックでラップすることです。「フラグ」または「トグル」変数は、多くの場合、Redisなどの外部ストアで構成され、組織は必要に応じて値を簡単に変更できます。
機能フラグは、本番システムの現在のロジックに影響を与えることなく、コードを安全にデプロイできるため、本番環境でのテストにおいて貴重なツールです。新しいコードパスは、最初は非アクティブ化でき、新しいコードをテストする準備ができた後でアクティブ化できます。機能フラグの概念の多くの実装には、「有効」または「無効」よりもきめ細かい制御が含まれており、トラフィックの割合に対して有効にしたり、異なるロジックのA/Bテストを実行したり、特定の場合にのみパスを選択したりするオプションがあります。
機能フラグを使用することで、非アクティブ化された状態でコードを本番環境にデプロイできます。本番トラフィックが古いロジックを使用し続ける間、テストスイートで新しいコードパスをテストできます。次に、影響を監視しながら、カナリアリリースとして新しいコードパスが受信する本番トラフィックの量を徐々に増やすことで、コードをゆっくりとリリースできます。
CI/CDを使用して本番環境インフラストラクチャにデプロイおよびテストする
本番環境でのテストに関する誤解の1つは、テストは本番環境で完了する必要があるという仮定です。支持者は、コードが最終的に実行される環境でのテストの価値を認識していますが、すべてのテストがこの程度の忠実度を必要とするわけではなく、多くの高速で集中的なテストは自動化して、コードのデプロイに向けた準備の一部として実行できます。
これを実装する最もシンプルで効果的な方法は、適切に調整されたCI/CDパイプラインを使用することです。CI/CD（継続的インテグレーションと継続的デリバリーまたはデプロイメント）は、新しいコードがリポジトリに追加されると自動的にテストするシステムです。テストスイートが正常に合格すると、パイプライン、継続的デリバリーにより、開発者はボタンをクリックするだけで変更をデプロイでき、継続的デプロイメントは、正常にテストされたすべてのコードを自動的にデプロイします。
CI/CDには、本番環境でのテストのコンテキスト以外にも多くの利点があります。説明しているシステムの場合、パイプラインはデプロイプロセスの自動化された部分として機能し、目標は本番環境にデプロイしてテストすることです。ユニットテストのような簡単なテストは分離して実行できますが、統合テストのようなより複雑な段階は、理想的にはコードを本番環境インフラストラクチャにデプロイしてそこでテストすることで行う必要があります。これにより、コードは、実行される最終的なインフラストラクチャ上で対話する実際のサービスに対して、同じ実行コンテキストでテストできます。
CI/CDパイプラインは、新しい変更に対する信頼を構築し、コードを本番環境に迅速にデプロイすることに対する不安を軽減するのに役立ちます。機能フラグと組み合わせることで、開発チームはコードの一部の側面が検証されていることを信頼し、より重いテストの実施方法を制御できます。
ダークローンチを許可するようにサービスを構成する
ダークローンチとは、ソフトウェアの変更をデプロイし、ユーザーに影響を与えることなく実際のトラフィックを使用してテストする方法です。アイデアは、本番トラフィックをミラーリングし、新しくデプロイされたコードに重複リクエストを送信して、コードが正しく実行され、実際のプロダクション負荷を処理できることを確認できるようにすることです。
ダークローンチは、テストの正当性に影響を与える可能性のある速度低下を引き起こすことなく、アプリケーションの複数のインスタンスで既存のトラフィックを再生する必要があるため、非常に複雑になる可能性があります。リアルタイムでリクエストを複製する代わりに、イベントログまたはその他のソースから以前のリクエストを再生する方法があります。この戦略では、最初のリクエストから関連するコンテキストをすべてキャプチャする必要があります。
ダークローンチの利点は、コードがすでにユーザーにリリースされているかのように、コードがどのように機能するかを確認できることです。新しいコードを介してトラフィックを実行した結果は、ユーザーには表示されませんが、コードがどのように動作し、どのような種類の条件を考慮する必要があるかについての洞察を提供できます。アプリケーションのダークローンチバージョンをテストしたら、すでにそれらのプレッシャーに直面していることを考えると、本番環境でどのように実行されるかについてかなり自信を持つことができます。
堅牢な監視とメトリクス収集を実装する
デプロイおよびリリース中に実行されるコアテストに加えて、本番環境に移行した後もその動作を継続的に監視できるシステムを導入することが重要です。さまざまな関連手法を実装して、サービスの長期的な健全性に関する洞察を得ることができます。これにより、新しいコードが動作の変化を引き起こした場合に、異常をより迅速に特定できます。
監視とメトリクストラッキングは、サービスが時間経過やさまざまな条件下でどのように実行されるかを理解するために使用できる基本的なツールです。新しい変更は、短いタイムラインでは見つけにくい副作用をもたらす可能性がありますが、時間の経過とともに明らかになる可能性があります。監視とメトリクスは、これらの動作の変化を特定のリリースに関連付けるのに役立ちます。
本番環境でのテストはデータベースにどのように影響しますか？
本番環境でのテストの最も複雑な側面の1つは、データベースと対話するテストを実行する効果的な方法を見つけることです。新しいコードを別のデータソースから読み書きできるようにすることは可能ですが、これは再び、適切に複製されていない環境に対してテストする可能性を導入します。
より良いが、達成がより難しい選択肢は、本番データベースでテストすることです。これは、特にデータベーススキーマとツールが最初からこの可能性に対して構成されていない場合、実装が難しい場合がありますが、コードがリリース時にどのように動作するかを理解するための最良の機会を提供します。
新しいコードが本番データベースからデータを読み取ることを許可することは非常に簡単です。テストが大量の読み取り競合を引き起こさない限り、データベースの本番環境での責任に大きな影響を与えることはなく、本番データに危険はありません。
ただし、コードが書き込み操作をどのように実行するかをテストするのは少し難しいです。最も簡単なテスト方法は、本番データベース内に専用のテストユーザーを作成して、新しいコードが実際のユーザーデータに触れることなくデータを操作できるようにすることです。テスト操作はアクティブなコードからの実際のデータと並行して実行されるため、これは依然として非常に恐ろしい提案になる可能性があります。
結論
本番環境でのテストは実装が難しく、既存のプロジェクトでは多くの変更が必要になる場合があります。ただし、重要な環境でコードの実際の動作をテストできるシステムを採用することの利点は、過小評価することはできません。テストは、バグを特定し、ソフトウェアに対する信頼を構築することを目的としていますが、これら2つの目標は、代表的でない環境では完全に達成することが困難です。
このアプローチに伴う課題を理解することで、それが組織のワークスタイルにどれだけ適合するかを評価できます。本番環境でのテストはトレードオフの練習であり、成功は、プロセスにどれだけの努力を費やす意思と能力があるかに大きく依存する可能性があります。必ずしも簡単な調整ではありませんが、その利点は長期的に役立つ可能性があります。
Prismaデータプラットフォームは、本番環境でのデータベースへのアクセスを簡素化するのに役立ちます。データベース接続の管理にPrisma Clientを使用している場合、Prismaデータプラットフォームは、本番環境のワークロードをより簡単に管理するのに役立つ場合があります。
