running(テスト実行中)」でした。エンジニアは高価なリソースであり、テストを実行するために長時間待機しなければならない場合は、コードをコンパイルするために長時間待たなければならないのと同じように、リソースの無駄遣いになります。使用し、テストスイートをより迅速かつ簡単に、そして便利にするために努力しています。統合テストパイプラインで必要となる時間を短縮、コンフィグの複雑さを軽減した方法とその過程で得た教訓についてお伝えします。つのテストワークフローを使用しています。目は、各プルリクとマスターへの各コミットで実行される単体テストです。目は、デプロイ毎に各環境で実行される統合テストです。単体テストが不安定になることはほぼなく、失敗した場合には調査が必要です。統合テストは、ブラウザオートメーションテストであり、その性質上、信頼性が低くなる傾向があルため、試行錯誤の連続です。既存のテストを安定させることができても、新しいテストによってさらに状況が混迷することになります。つのタイプのテストのそれぞれに対して個別の最適化戦略を追求することで、両方のテストを有用なものにすることができました。テストはすべてのプルリクに対して実行されるため、どのテストが失敗したかをできるだけ早く開発者に知らせることが大切だと考えています。分間を要していました。パッケージのテストを論理的に分割していたことです。分近くかかっていました。並列処理と時間ベースの分割機能により、バラバラだったテストを、バランスよく大体同じ時間で完了できるようになりました。パッケージを分割する方法を示しています。"/go/pkg/mod"何を行っているかを見ていきましょう。モジュールキャッシュを復元しました。キャッシュがないと、何も行われません。モジュールをダウンロードする必要がなくなります。ファイルハッシュによって、キャッシュキーが設定されます。使用してテストを実行します。レポートを生成でき、どのテストが失敗したかを簡単に確認できます。ファイルが変更された場合、キャッシュを保存します。このキャッシュキーがすでに保存されている場合、この手順では何も実行されません。この処理の大きな利点は、テスト数の増加に合わせて、単に並列処理の数を増やすことができることです。我々はこの成果で満足して終わりとはせず、さらに何かできないか試してみることにしました。非常にすばやくプルされることに注意してください。独自のイメージを構築する前に、節約できる時間を測定するとよいでしょう。統合テストは別の意味で厄介です。つのブラウザオートメーションテストを当社は実行しています。プランの制限の影響のみを受けますが、リモートブラウザテストは、並列処理のボリュームに対して費用が発生するため、高価になる可能性があります。リモートブラウザをホストします。つの環境に対して統合テストを実行しています。サンドボックスでほぼすべてのテストを実行し、ステージングではサンドボックスよりも小数のテストを実行し、本番環境ではわずかなサブセットのみを実行します。統合テストをトリガーできる必要があります。トリガーができなかったため、非常に複雑なシステムを構築してこの処理を実行していました。APIが新たにリリースされ、理解しやすく、迅速かつ簡便で理にかなった方法でワークフローを再編成することができました。つのタイプのブラウザについて数百のリモートテストを実行していたのです。時間以上がかかっていました。つのジョブに分割し、失敗したジョブのみを再実行できるようになりました。新しいワークフローは非常にシンプルになりました。このワークフローは、以下に示します。つのタイプは、統合テストリポジトリへのすべてのプルリクで実行されます。これにより、追加または変更するテストが有効であることが確認されます。これらは、ローカルヘッドレスブラウザテストのみを実行し、このワークフローはできるだけ軽量な状態を維持します。ビルドを促進するワークフローこれらの統合テストは、ステージング、サンドボックス、または本番環境のいずれかの環境に対してマスターで実行されます。複数のブラウザを使用します。フェイクキューを作成します。テストはブロックしません。swissknife/queue_up_workflowステージング環境とサンドボックス環境で同じジョブがあることに注意してください。これらのテストは同じであり、変更があるのはテストする環境だけですので、テストコンフィグをコンテキストへと移動し、テストする環境に応じてコンテキストを添付します。使用して(コンプライアンス上の理由により)デプロイを管理し、統合テストをトリガーします。テストを待機できるようになりました。使用してこの操作を実行する方法を示します。+xstart_integration_testget_workflow_from_pipelinewait_for_workflow単一のジョブからこのワークフロー制御のアプローチに移行することには、次の利点があります。要約すると、テストの実行時間を短縮し、テスト操作を容易にする取り組みを始めたところ、テストタイプごとに異なるアプローチを使用する必要があることに気付きました。単体テストを、実行時間を基準にして分割し、繰り返し発生する可能性のある作業を事前にビルドされたコンテナに移動しました。統合テストについては、並列処理が制限されるリモートブラウザで作業するために最適化しました。コンフィグを簡単に変更するだけで、いくつもの環境で同じテストを実行する仕組みを構築しました。その結果、パイプラインの複雑さも軽減され、新しいエンジニアが、テストインフラストラクチャを理解しやすくなりました。noopener”社でシステム構築を担当しています。複雑な問題を解決する業務の他にも、開発インフラとツールについても情熱を傾けています。オフの時間には、こだわりのコーヒーを楽しんだり、ハイキングをしたり、さまざまなトピックについてツイートしたりします。最新のブログ記事をメールでお知らせします。ポリシーに同意したものと見なされます。