🤾🏽 🆓 〰️ Yandexでの継続的な統合 🔌 🧛🏿 🔩

多数の開発者に高い生産性を確保しながら、巨大なコードベースを維持することは重大な課題です。過去5年間、Yandexは継続的な統合のための特別なシステムを開発してきました。この記事では、Yandexコードベースの規模、トランクベースの開発アプローチを使用した単一リポジトリへの開発の移行、そのような状況で効果的に機能するために継続的統合システムが解決しなければならないタスクについて説明します。

何年も前、Yandexにはサービスの開発に特別なルールがありませんでした。各部門は、あらゆる言語、テクノロジー、展開システムを使用できました。そして、実践が示しているように、そのような自由は常により速く前進するのに役立つとは限らなかった。当時、同じ問題を解決するために、多くの場合、独自の開発またはオープンソースの開発がいくつかありました。会社が成長するにつれて、そのようなエコシステムは悪化しました。同時に、多くの利点を提供するため、多くの独立企業に分割せずに、1つの大きなYandexのままにしたかったのです。多くの人が同じタスクを実行し、作業の結果を再利用できます。分散ハッシュテーブルやロックフリーキューなどのさまざまなデータ構造から始まり、20年以上かけて作成したさまざまな特殊コードで終わります。

私たちが解決するタスクの多くは、オープンソースの世界では解決しません。ボリューム（5000以上のサーバー）とタスクで適切に動作するMapReduceはありません。数千万のチケットをすべて処理できるタスクトラッカーはありません。これはYandexでは魅力的です-あなたは本当に素晴らしいことをすることができます。

しかし、同じ問題を新たに解決し、既製のソリューションをやり直すと、効率が大幅に低下し、コンポーネント間の統合が困難になります。自分のためだけにすべてを自分のコーナーで行うのは便利であり、当面は他人について考えることはできません。しかし、サービスが十分に目立つようになるとすぐに、依存関係が生じます。実際、さまざまなサービスは相互に弱く依存しているように見えます。実際、会社のさまざまな部分の間には多くのつながりがあります。多くのサービスは、Yandexアプリケーション/ブラウザ/などから利用できるか、相互に埋め込まれています。たとえば、ブラウザにアリスが表示され、アリスを使用してタクシーを注文できます。私たちは皆、共通コンポーネントYT 、 YQL 、 Nirvanaを使用します。

古い開発モデルには重大な問題がありました。多くのリポジトリが存在するため、通常の開発者、特に初心者にとって次のことを見つけることは困難です。

コンポーネントはどこにありますか？
それがどのように機能するか：「取得して読む」方法はありません
現在誰が開発およびサポートしていますか？
それを使い始める方法は？

その結果、コンポーネントの相互使用の問題がありました。コンポーネントは互いに「ブラックボックス」を表しているため、他のコンポーネントをほとんど使用できませんでした。コンポーネントは再利用されなかっただけでなく、多くの場合改善されなかったため、これは会社に悪影響を及ぼしました。多くのコンポーネントが複製されたため、サポートする必要があるコードの量が大幅に増加しました。私たちは通常、私たちができるよりもゆっくりと動きました。

単一のリポジトリとインフラストラクチャ

5年前、開発を単一のリポジトリに移行するプロジェクトを開始し、アセンブリ、テスト、展開、および監視のための共通システムを使用しました。

私たちが達成したかった主な目標は、他人のコードの統合を妨げる障害を取り除くことでした。システムは、完成した作業コードへの簡単なアクセス、その接続と使用のわかりやすい図、収集性を提供する必要があります。プロジェクトは常に収集されます（そしてテストに合格します）。

このプロジェクトは、企業のインフラストラクチャテクノロジーの単一スタックであるソースコードストレージ、コードレビューシステム、ビルドシステム、継続的インテグレーションシステム、展開、監視をもたらしました。

現在、Yandexプロジェクトのソースコードのほとんどは、単一のリポジトリに格納されているか、移行中です。

2000人以上の開発者がプロジェクトに取り組んでいます。
50,000以上のプロジェクトとライブラリ。
リポジトリサイズが25 GBを超えています。
すでに3,000,000を超えるコミットがリポジトリにコミットされています。

会社のプラス：

リポジトリのプロジェクトは、既製のインフラストラクチャを受け取ります。
- ソースコードを表示およびナビゲートするためのシステム、およびコードレビューシステム。
- アセンブリシステムと分散アセンブリ。これは別の大きなトピックであり、次の記事で確実に取り上げます。
- 継続的な統合システム。
- 展開、監視システムとの統合。
コード共有、アクティブなチームインタラクション。
すべてのコードは共通であるため、別のプロジェクトにアクセスして、そこで必要な変更を加えることができます。これは大企業では特に重要です。何かを必要とする別のチームにはリソースがない場合があるためです。共通のコードを使用すると、自分で作業の一部を行い、必要な変更を「発生させる」機会を得ることができます。
グローバルなリファクタリングを実行する機会があります。 APIまたはライブラリの古いバージョンをサポートする必要はありません。それらを変更し、他のプロジェクトで使用される場所を変更できます。
コードは「多様性」が少なくなります。問題を解決するための一連の方法があり、ほぼ同じですが、わずかな違いがある別の方法を追加する必要はありません。
あなたの隣のプロジェクトでは、ほとんどの場合、絶対にエキゾチックな言語とライブラリはありません。

また、このような開発モデルには、考慮する必要がある欠点があることを理解する必要があります。

共有リポジトリーには、別個の特別なインフラストラクチャーが必要です。
必要なライブラリはリポジトリにないかもしれませんが、オープンソースにあります。追加と更新にはコストがかかります。言語とライブラリに大きく依存し、どこかでほとんど無料で、どこかで非常に高価です。
コードの「健康」に常に取り組む必要があります。これには、少なくとも不要な依存関係やデッドコードとの戦いが含まれます。

共通のリポジトリに対する私たちのアプローチは、誰もが従う必要がある一般的な規則を課しています。単一のリポジトリを使用する場合、使用する言語、ライブラリ、および展開方法に制限が課されます。しかし、近隣のプロジェクトでは、すべてがあなたのものと同じか非常によく似ており、そこで何かを修正することさえできます。

共通リポジトリのモデルは、すべての大企業に引き付けられます。モノリシックリポジトリは大規模でよく研究され、議論されているトピックなので、ここではあまり説明しません。詳細を知りたい場合は、記事の最後に、このトピックをより詳細に明らかにするいくつかの便利なリンクがあります。

継続的インテグレーションシステムが動作する条件

開発は、トランクベースの開発モデルに従って実行されます。ほとんどのユーザーは、head、またはtrunkと呼ばれるメインブランチから取得したリポジトリの最新のコピーを使用して作業を行っており、開発が進行中です。リポジトリへの変更のコミットは順番に行われます。コミットの直後に、新しいコードが表示され、すべての開発者が使用できます。ブランチはリリースに使用できますが、別個のブランチでの開発は推奨されません。

プロジェクトはソースコードに依存しています。プロジェクトとライブラリは、複雑な依存関係グラフを形成します。これは、1つのプロジェクトで行われた変更がリポジトリの残りの部分に影響を及ぼす可能性があることを意味します。

コミットの大きなストリームはリポジトリに送られます：

1日あたり2000件を超えるコミット。
ラッシュアワーの間に1分あたり最大10回の変更。

コードベースには、500,000を超えるビルドターゲットとテストが含まれています。

このような状況での継続的な統合の特別なシステムがなければ、迅速に前進することは非常に困難です。

継続的統合システム

継続的インテグレーションシステムは、変更ごとにアセンブリとテストを実行します。

予備チェック。コミットする前にコードをチェックし、トランクでのテストの中断を回避できます。アセンブリとテストは、HEADの上で実行されます。現時点では、事前監査チェックは自発的に開始されます。重要なプロジェクトの場合、事前監査チェックが必要です。
リポジトリへのコミット後のコミット後チェック。

ビルドとテストは、数百台のサーバーの大規模なクラスターで並行して実行されます。ビルドとテストは異なるプラットフォームで実行されます。メインプラットフォーム（Linux）では、すべてのプロジェクトがアセンブルされ、すべてのテストが他のプラットフォーム（ユーザー設定可能なプラットフォームのサブセット）で実行されます。

アセンブリの結果を受け取って分析し、テストを実行した後、ユーザーは、たとえば変更によりテストが中断された場合など、フィードバックを受け取ります。

新しいアセンブリの失敗またはテストが発生した場合、テストの所有者と変更の作成者に通知を送信します。また、システムはチェックの結果を特別なインターフェースに保存して表示します。統合システムのWebインターフェイスには、テストの進行状況とテスト結果がテストタイプごとに表示されます。スキャン結果の画面は次のようになります。

継続的インテグレーションシステムの機能と機能

開発者とテスターが直面するさまざまな問題を解決し、継続的インテグレーションのシステムを開発しました。このシステムはすでに多くの問題を解決していますが、改善すべき点はまだたくさんあります。

テストの種類とサイズ

継続的インテグレーションシステムがトリガーできる目標には、いくつかのタイプがあります。

構成します。ビルドシステムによって実行される構成フェーズ。構成には、ビルドシステムの構成ファイルの分析、プロジェクトとビルドパラメーター間の依存関係の決定、およびテストの実行が含まれます。
ビルドします。ライブラリとプロジェクトのアセンブリ。
スタイル。この段階で、コードスタイルが指定された要件に準拠しているかどうかがチェックされます。
テスト。テストは、作業時間のタイムアウトとコンピューティングリソースの要件に応じて段階に分けられます。
- 小さい。 <1分
- 中。 <10分
- 大きい。 > 10分さらに、コンピューティングリソースには特別な要件がある場合があります。
- 特大。これは特別なタイプのテストです。このようなテストは、以下の一連の特性によって特徴付けられます：長い稼働時間、大量のリソース消費、大量の入力データ、特別なアクセスが必要な場合があり、最も重要なのは、以下で説明する複雑なテストシナリオのサポートです。そのようなテストは他のタイプのテストよりも少ないですが、非常に重要です。

テストの実行頻度とバイナリトラブルシューティング

膨大なリソースがYandexのテスト用に割り当てられています-何百もの強力なサーバー。しかし、多数のリソースがあっても、それらに影響を与えるすべての変更に対してすべてのテストを実行することはできません。しかし同時に、開発者がテストが中断する場所、特にそのような大規模なリポジトリでのローカライズを常に支援することは非常に重要です。

私たちは何をしています。影響を受けるすべてのプロジェクトのすべての変更について、小規模、中規模のサイズのアセンブリ、スタイルチェック、およびテストが開始されます。残りのテストは、影響を与えるすべてのコミットに対してではなく、テストに影響するコミットがある場合、特定の周期で実行されます。ユーザーが起動の頻度を制御できる場合もあれば、システムによって起動の頻度が設定される場合もあります。テストの失敗が検出されると、テスト違反コミットの検索プロセスが開始されます。テストの実行頻度が低いほど、障害が検出された後の破壊的なコミットをより長く探します。

事前監査チェックを開始するときは、アセンブリとライトテストのみを実行します。さらに、システムが提供する変更の影響を受けるテストのリストから選択することにより、ユーザーは手動で重いテストの起動を開始できます。

点滅テスト検出

点滅テストは、同じコードでの実行（合格/失敗）結果がさまざまな要因に依存する可能性があるテストです。フラッシュテストの原因は異なる可能性があります。テストコードでのスリープ、マルチスレッドでの作業時のエラー、インフラストラクチャの問題（すべてのシステムの可用性）などです。点滅テストには重大な問題があります。

それらは、継続的インテグレーションのシステムがテストの失敗について誤った警告を送信するという事実につながります。
テスト結果を汚染します。検証結果の成功を決定することはより困難になっています。
製品リリースを遅らせます。
検出が難しい。テストが点滅することはほとんどありません。

開発者は、テスト結果を分析するときに点滅テストを無視できます。時々間違っています。

まばたきテストを完全に排除することは不可能です。これは、継続的インテグレーションシステムで考慮する必要があります。

現在、各テストについて、すべてのテストを2回実行して、点滅テストを検出しています。また、ユーザー（通知の受信者）からの苦情も考慮します。点滅を検出した場合、テストに特別なフラグ（ミュート）を付け、テストの所有者に通知します。この後、テストの所有者のみがテストの失敗の通知を受け取ります。次に、起動の履歴を分析しながら、通常モードでテストを実行し続けます。特定の時間枠内でテストが点滅しなかった場合、自動化はテストの点滅が停止したと判断する場合があり、フラグをクリアできます。

現在のアルゴリズムは非常に単純であり、多くの改善がこの場所で計画されています。まず最初に、はるかに有用な信号を使用したいと思います。

テスト入力の自動更新

最も複雑なYandexシステムをテストする場合、他のテスト方法に加えて、ブラックボックス戦略テスト + データ駆動型テストがよく使用されます。適切なカバレッジを確保するために、このようなテストには大量の入力データが必要です。本番クラスターからデータを選択できます。ただし、データがすぐに古くなるという問題があります。世界は静止していません。私たちのシステムは常に進化しています。時間の経過した古いテストデータでは、良好なテストカバレッジが得られず、プログラムが古いテストデータでは利用できない新しいデータを使用し始めるため、テストが完全に中断されます。

データの有効期限が切れないようにするために、継続的インテグレーションシステムはデータを自動的に更新できます。どのように機能しますか？

テストデータは、リソースの特別なストレージに保存されます。
テストには、必要な入力を説明するメタデータが含まれています。
必要なテスト入力とリソース間の対応は、継続的インテグレーションシステムに保存されます。
開発者は、新しいデータがリソースストアに定期的に配信されるようにします。
継続的インテグレーションシステムは、リソースリポジトリでテストデータの新しいバージョンを検索し、入力データを切り替えます。

誤ったテストが発生しないように、データを更新することが重要です。特定のコミットから始めて、新しいデータの使用を開始することはできません。なぜなら、テストが故障した場合、誰が責任を負うのか-コミットまたは新しいデータ-は明確ではありません。また、diffテスト（以下で説明）を無効にします。

したがって、コミットの間隔が少し短くなるようにして、入力データの古いバージョンと新しいバージョンの両方でテストが開始されるようにします。

差分テスト

差分テストでは、特別な種類のデータ駆動型テストを呼び出します。これは、テストに参照結果がないという点で一般に受け入れられているアプローチとは異なりますが、同時に、テストのコミット内容で動作を変更したものを見つける必要があります。

データ駆動型テストの標準的なアプローチは次のとおりです。テストには、テストが最初に実行されたときに取得された参照結果があります。参照結果は、テストの隣のリポジトリに保存できます。その後のテストの開始でも同じ結果になります。

結果が参照と異なる場合、開発者はこれが予想される変更またはエラーであるかどうかを判断する必要があります。変更が予想される場合、開発者は変更をリポジトリにコミットすると同時に参照結果を更新する必要があります。

大規模なコミットフローを持つ大規模なリポジトリでこのアプローチを使用する場合には、困難があります。

多くのテストが存在する可能性があり、テストは非常に難しい場合があります。開発者は、影響を受けるすべてのテストを作業環境で実行することはできません。
変更を行った後、コードの変更と同時に参照結果が更新されなかった場合、テストが中断する場合があります。その後、別の開発者が同じコンポーネントに変更を加えると、テスト結果が再び変更されます。あるエラーが別のエラーに課せられます。そのような問題に対処することは非常に難しく、開発者からの時間がかかります。

私たちは何をしています。 Diffテストは2つの部分で構成されます。

コンポーネントを確認してください。
- テストを実行し、結果をリソースのストレージに保存します。
- 結果を参照と比較しないでください。
- たとえば、プログラムが起動しない/終了しない、クラッシュする、プログラムが応答しないなど、いくつかのエラーをキャッチできます。結果の検証も実行できます。回答内のフィールドの存在など。
差分コンポーネント。
- 異なる起動で得られた結果を比較し、差分をビルドします。最も単純な場合、これは2つのパラメーターを受け取り、diffを返す関数です。
- diffの外観はテストによって異なりますが、diffを見る人にとって理解できるものでなければなりません。通常、diffはhtmlファイルです。

checkおよびdiffコンポーネントの起動は、継続的な統合システムによって制御されます。

継続的インテグレーションシステムがdiffを検出した場合、変更の原因となったコミットに対してバイナリ検索が最初に実行されます。通知を受け取った後、開発者はdiffを調査し、次に何をするかを決定することができます。期待どおりにdiffを認識する（これには特別なアクションを実行する必要があります）か、変更を修復/ロールバックします。

続く

次の記事では、継続的インテグレーションのシステムがどのように機能するかについて説明します。

参照資料

モノリシックリポジトリ、トランクベースの開発

データ駆動テスト

データ駆動型テスト-ウィキペディア

Yandexでの継続的な統合