1日に2回のリリースで4年間生き延びてきた方法

こんにちは、Habr！ 今日、私は（ エラーと経験の調査から始まる）テスト組織に関する一連の記事を完成させ、Badooが毎日2つの高品質サーバーリリースをどのようにリリースするかについて説明します。 金曜日を除き、午前中にのみ解放されます。 金曜日の夜にリリースする必要はありません 。

4年ほど前にBadooに来ました。 これまで、プロセスとテストツールは継続的に開発および改善されてきました。 何のために？ 開発者とテスターの数が倍になりました。つまり、リリースごとにさらに多くのタスクが準備されています。 アクティブユーザーと登録ユーザーの数も2倍になりました。つまり、エラーの価格が高くなっています。 最高品質の製品をユーザーに提供するためには、より強力な品質管理手段が必要であり、この競争は終わりません。 この記事の目的は、実例を示すことだけでなく、品質管理プロセスがいかにクールであっても、確かにそれをさらに改善できることを示すことです 。 他の記事へのリンクからいくつかのツールの技術的な実装を見つけることができますが、それらのいくつかについてはまだ書いていません。

Badooにはいくつかの異なるQAフローがあり、その違いは異なる開発ツールとターゲットプラットフォームによって正当化されます（ ただし、JIRA、TeamCity、Gitなどの共通システムを使用します ） 。テストプロセスとサーバーの展開について説明します。タスク（同時にWebサイト）。 条件付きで5つの大きな段階に分けることができます（ もちろん、ここでは私の同僚の多くは異なる考えを持っていますが）。各段階には、手動コンポーネントと自動コンポーネントの両方が含まれています。 私は、それらのそれぞれについて順番にあなたに話をしようと試み、近年変化し発展したものを個別に強調します。

1.コードレビュー

はい、驚かないでください。これは実際には品質管理の段階でもあります。 これは、アーキテクチャ上のエラーと論理的なエラーが戦闘コードに入らないように考案されたものであり、タスクが私たちの基準やルールに決して違反しないようにするためです。

開発者がコードを一般リポジトリに「プッシュ」する前でも、レビューコードは自動的に開始されます。 受信側でgit pushを実行しようとすると、大量のさまざまな処理を行う事前受信フックが起動します。

• ブランチの名前を確認します。リポジトリ内の各ブランチはJIRAのチケットにアタッチする必要があり、チケットキーはブランチの名前に含まれている必要があります（例： HABR-1_make_everything_better） 。
• コミットに関するコメントを確認します 。各コミットには、説明に同じチケットキーが含まれている必要があります。 これはクライアントフックを使用して自動的に行われ、コメントは常に次のようになります。 [HABR-1]：Initial commit ;
• コード形式への準拠を確認します 。リポジトリ内のすべてのコードは、Badooで採用されている標準に準拠する必要があるため、変更されたPHPコードの各行はphpcfユーティリティによって確認されます。
• JIRAでステータスを確認します。コミットを行うには、特定のステータスになっている必要があります。たとえば、リリースブランチでタスクが既に「フリーズ」されている場合、タスクコードを変更できません。
• そして、はるかに...

これらのチェックのいずれかに失敗すると、プッシュが禁止され、開発者は発生したコメントを修正する必要があります。 このようなフックはますます増えています。
また、受信前フックに加えて、プロセスを自動化する多くの操作を実行する受信後フックのプールが増えています：JIRAでタスクのフィールドとステータスを変更し、テストを実行し、展開システムにシグナルを送信します...一般的に、彼らは非常に良い仲間です。

コードが自動検証のすべての段階を突破できた場合、手動でコードをレビューします。これは、私たちが高度に修正したGitPHPのバージョンに基づいています。 開発チームは、採用されたアーキテクチャに対するソリューションの最適性とコンプライアンス、ビジネスロジックの一般的な正確性をチェックします。 同じ段階で、新規または変更されたコードのカバレッジを単体テストでチェックします（テストで適切にカバーされていないタスクはレビューに合格しません）。 問題の解決中に他の部門のコードが影響を受けた場合、その代表者は間違いなくレビューに参加します。



GitPHPで、レビュー担当者はコードにコメントを付けることができます-そして、それらはすべてJIRAの対応するタスクのコメントとして表示され、QAエンジニアはテスト中にすべてのコメントの修正を確認できます（ 開発者はこれらのコメントにホリバーを配置することもあります、読書は喜びです ）。

2.「開発」でのテスト

私たちの理解における「開発環境」とは何ですか？ これは、開発およびテスト用に設計された小規模の生産アーキテクチャを最大化する本格的なプラットフォームです。 開発者には、独自のデータベース、独自のデーモンのコピー、サービス、およびCLIスクリプトが含まれています。 相互作用をテストするために2つの完全に別個のサイトに分割されます。1つはモスクワのオフィスにあり、プラハのデータセンターの作業をエミュレートします。2つ目はロンドンのマイアミのデータセンターの作業をエミュレートします。



開発のフレームワーク内で、各開発者とテスターは独自の「サンドボックス」を持ち、そこで必要なサーバーコードの任意のバージョンをアップロードでき、対応するURLの内部ネットワークから利用できます。 残念ながら、各開発者独自のサンドボックスをローカルマシンに展開するのは費用がかかりすぎます。Badooは非常に多くの異なるサービスで構成され、特定のソフトウェアバージョンに依存しています。

2.1。 自動ブランチテスト

開発者がタスクの作業を終了した直後に、少なくとも統合テストと単体テストが開始されたら素晴らしいと思いませんか？ 今、私はあなたに必死の闘争の小さな話を一つお話しします。

• 2012年。 15,000テスト。 単一のスレッドで実行するか、いくつかの等しいスレッドに不細工に切り刻みます。 約40分が経過します（サーバーの負荷が高い場合は絶対に無限になります）。自動起動の話はできません。 悲しいです。
  
  
• 2013年。 25,000テスト。 1つのスレッドでどれだけ処理されるかを計算しようとする人はいません。 悲しいです。 しかし、ここでは独自のマルチスレッド「ランチャー」を開発しています！ これで、すべてのテストが約5分で合格します。タスクを完了したらすぐに実行できます。 これで、テスターはタスクを手に取り、そのパフォーマンスをすぐに評価できます。便利な形式でのテスト実行のすべての結果がJIRAに投稿されます。
  
  
• 2014年。 40,000回のテスト。 すべてが順調で、マルチスレッドランチャーが対処しました...しかし、その後、すばらしいPHP 5.5が登場し、使用したRunkitフレームワークが動作し始めました... 悲しいです。 テストを非常に小さなセットに分割する必要があると結論付けています。 ただし、1台のマシンで（以前に使用した10個のプロセスではなく）100個のプロセスを実行しようとすると、非常に速く停止します。 問題の解決策は？ クラウドにテストを実施します ！ その結果、すべてのテストで2〜3分で、すぐに問題が解決します 。
  
  
• 2015年。 55,000テスト。 ますます多くのタスクが解決され、テストは増え続け、クラウドでさえそれらに対処するのをやめています。 悲しいです。 これについて何ができますか？ そして、タスクの最後に、その影響を受ける機能をカバーするテストのみを実行し、後続の段階ですべてのテストを実行してみましょうか？ すぐに言ってやった！ 1日に2回、コードをテストでカバーすることに関する情報を収集し、タスクの影響を受けるすべてのコードをカバーするテストの完全なセットを収集できる場合は、それらを実行します（疑わしい場合、新しいファイルまたは基本クラスの大規模な変更-とにかくすべてを実行しましょう）。 これで、ブランチのすべてのテストに合格するのに平均で1〜2分、すべてのテストを実行するのに4〜5分かかります。
  
  
• 2016年。 75,000テスト 。 テストが遅くなり始める前に（そして再び悲しみを感じる時間がなかった）、数人の救助者がすぐに私たちのところに来ました。 PHP7に切り替えて、 問題の原因となったランキット （ PHP7をまだサポートしていない ）を独自の開発SoftMocksに置き換えました 。 すべてのテストは現在3〜4分で合格しますが、来年どのような問題に直面するかを誰が知っていますか？

リリースエンジニアが開発したかけがえのないアシスタントAIDA （ 自動化されたインタラクティブな展開アシスタント ）は、適切なタイミングで適切なブランチでテストを実行しています。 実際、開発中のすべての自動化プロセスのほとんどは、その優しい（とはいえ骨の折れる ）手なしには行えません。

2.2。 「開発」での手動テスト

したがって、テスターは最終的にタスクを手に入れます。 その中のすべての単体テストに合格し、テストを開始できます。 何をする必要がありますか？ そうです、必要なすべてのケースをプレイする必要があります。 そして4年前は非常に退屈な職業でした。

Badooは出会い系サービスです。つまり、すべての機能はユーザーに大きく依存しています。 ほぼすべてのテスト（および良い方法-それぞれの場合）で、新しいユーザーを登録する必要があります。 ほとんどの機能は写真のないユーザーには利用できないため、複数の写真をアップロード（およびモデレート）する必要もあります。 合計で、すでに約5分のルーチン作業が必要です。
次に、テストデータを準備する必要があります。 1日に数百人の他のユーザーにメッセージを書き込んだユーザーに表示されるプロモーションウィンドウを見たいですか？ さて、指を伸ばして洪水を始めます。 そして泣く。

ああ、この場合、1年以上前に登録したユーザーが必要ですか？ 私はこれを持っていません:(みんな、誰かいますか？いいえ？：（（（データベースの値を修正するために開発者を引っ張って行かなければなりません...

とても悲しい話ですね しかし、救いが私たちのところに来ました— QaApi ！ これは何ですか これは、HTTPリクエストを使用してサーバー側でさまざまなアクションを実行できる素晴らしいシステムです（ もちろん、これはすべて許可によってカバーされ、テストとしてマークされたユーザーにのみ影響します。このインターフェイスを自宅で見つけようとしないでください ）。
QAエンジニアはQaApi（qaapi.example.com/userRegister 形式 ）の簡単なリクエストを行い、必要な設定（ユーザーの性別、登録都市、年齢など）をGETパラメーターで転送し、すぐに認証データを受信できます！ さらに、この方法では、開発環境と本番の両方でユーザーを獲得できます。 同時に、ボットで本番環境を詰まらせたり、テストユーザーが生きているようには見えず、ユーザーを定期的に登録する代わりに、適切な（以前のテスト後にすでに完全にクリアされた）ユーザーをプールから取得します（既に存在する場合）。

同じ簡単なリクエストで、インターフェイスから変更できないさまざまなデータを変更して入力できます。前述の登録日、1日あたりの新しい連絡先またはいいねの数（大丈夫！）、そして好きなものすべて。 また、必要なパラメーターを変更するQaApiメソッドがない場合はどうなりますか？ ほとんどの場合、PHPの基本的な知識で十分であり、どのエンジニアでも実行できます。 ただし、コードにさらに深い変更が必要な場合があり、その場合はコンポーネントの責任を負う開発者に連絡する必要があります。
当然のことながら、このすべての美しさは手動テストだけでなく発明されました。 私たちのテストはまた、QaApiを強力かつメインで使用し始めました：テストはより速く、よりアトミックになり、実際にテストする必要があるもののみをテストします（もちろん、この方法で単純化された操作のための個別のテストもあります）。

そして、これだけでは不十分だと判断した場合、QaApiスクリプトを実装しました。これにより、簡単なスクリプトをLuaで記述できます（ 尋ねないでください ）。ワンクリックでさまざまなメソッドを呼び出すことで、複雑なケースをテストするための複雑なデータを準備することもできます。

2.3。 環境とツールの改善

開発者のテストを最適化および自動化する方法に加えて、もちろん、テストを完全かつできるだけ本番に近づける方法が非常に重要です。
たとえば、CLIスクリプト。 以前は、クラウンを使用して起動されていました。 したがって、テスターがスクリプトの新しいバージョンを確認する場合、次のことを行う必要がありました。

• crontabでスクリプトを起動するための行をコメントアウトします。
• このスクリプトのすべてのアクティブなインスタンスを強制終了します。
• スクリプトのバージョンを実行してテストします。
• このスクリプトのすべてのインスタンスを強制終了します。
• crontabの行のコメントを解除します。

これらの手順のいずれかをスキップすると、テスター自身（彼が期待するスクリプトの間違ったバージョンが動作する可能性があります）または彼の周りのすべての人（スクリプトが動作せず、誰も理由を知りません）のいずれかの問題につながります。

現在、このような問題はありません。すべてのスクリプトは共通のスクリプトフレームワークで実行されます。開発バージョンでは、スクリプトに「一般的なディレクトリからではなく、作業ディレクトリから実行する」という機会があります。 この場合、エラーまたはタイムアウトの期限が切れると、スクリプトが一般ストリームに戻され、システムはすべてのワーカーが正しいバージョンであることを確認します。

もう1つの問題は、複数のA / Bテストです。 文字通り何十ものそれらがいつでもあります。 以前は、すべてのテストオプションをキャプチャするために多数のユーザーを作成するか、コードをハッキングして、現在関心のあるオプションにユーザーを意図的に押し込む必要がありました。 そして今、一般的なUserSplitシステムを使用しています。これにより、特定のテストごとに「このユーザーは常にこのオプションを取得します」などのQA設定を追加し、現在必要なものを正確にチェックしていることを常に確認できます。

3.「ショット」でのテスト

私たちの理解における「ショット」とは何ですか？ 実際、これは実稼働環境のタスクブランチ（および現在のマスター）です。 技術的な観点からは、ステージングクラスターのマシンの1つに必要なバージョンのコードを含むディレクトリと、NGINX configの行であり、 habr-1.shotの形式のhttp-requestsをこのフォルダーに送信します。 したがって、ショットは、Webとモバイルの両方の任意のクライアントのサーバーとして指定できます。 すべてのエンジニアは、JIRAのリンクを使用して特定のタスクのショットを作成できます。

これは主に、実際の環境でタスクの操作性をテストすることを目的としています（非常によく似ていますが、依然として「合成」的なものではありません）。また、翻訳の生成やチェックなどの追加のタスクを解決することも目的としていますタスクがステージングに到達し、残りのタスクのリリースを遅らせない前に）。 ショットを外部としてマークすることもできます-そして、それは私たちの仕事用ネットワークからだけでなく（またはVPN経由でも）インターネットからも利用可能になります。 これにより、たとえば新しい支払い方法を接続する際に、パートナーにタスクをテストする機会を提供できます。

近年発生した主な変更は、生成直後のシ​​ョットでのテストの自動起動です（ショットは開発者よりもはるかに安定しているため、ここでのテスト結果は常にはるかに関連性が高く、誤った結果を与える可能性が低くなります）。 AIDAはここで2つのタイプのテストを実行します：SeleniumテストとcUrlテスト 。 実行結果はタスクに固定され、タスクを担当するテスターに​​送信されます。

しかし、変更または追加された機能がSeleniumテストでカバーされない場合はどうなりますか？！ まず第一に、てないでください。 私たちのテストは、確立された機能または重要な機能のみを対象としています（プロジェクトは非常に迅速に開発されており、テストで各実験機能をテストすると、このプロセスが大幅に遅くなります）。新しいテストを作成するタスクは、本番タスクのリリース後に設定されます。
そして、テストが失敗した場合はどうなりますか？ これには2つの理由が考えられます。 最初のケースでは、タスクにエラーがあります。プログラマーはよくできておらず、タスクを修正する必要があり、テストは仕事をしました。 2番目のケースでは、機能は正常に機能しますが、そのロジック（ または単にレイアウト ）が変更され、テストはシステムの現在の状態と一致しなくなりました。 テストを修復する必要があります。

以前は、自動化を担当するQAエンジニアの別のグループがありました。 彼らはそれをうまくかつ迅速に行う方法を知っていましたが、それでも各リリースは一定数のテスト（ 時には巨大な ）を破りました。 その結果、この問題へのアプローチを変更することにしました。すべてのQAエンジニアが少なくともSeleniumテストを書くための基本的なスキルを持つように、一連のセミナーと講義を開催しました（同時に、テストを書くのがより便利で簡単になるようにライブラリを変更しました）。 これで、テスターのタスクでテストが失敗し始めた場合、テスターはタスクブランチで自分でテストを修復します。 ケースが非常に複雑で大きな変更が必要な場合でも、知識のある人々にタスクを提供します。

4.ステージングのテスト

そのため、タスクは、テストフェーズの地獄の3つの円を通過し、リリースの準備ができています！ AIDAが復活しました。 すべての既製のタスクを収集し（タスクはすべての段階でチェックされ、必要な転送は完了し、JIRAのチケットは正しいステータスにあります）、それらを一般的なブランチに「マージ」し（単純な競合を解決し、困難な場合は開発者に助けを求めます）、現在のビルドとしてマークしますステージングサーバーに新しいバージョンのコードを配置し、自動テストの起動を開始します。
ここで、すべてのテストはすでに合格しています。 ステージングブランチ、スモークテスト、およびシステムの完全なセットを変更すると、統合テストと単体テストが開始されます。 それらの各エラーは、リリースの責任者に送信されます。

次に、テスターはステージングでタスクをチェックします。 ほとんどの場合、ステージングのために残した他のユーザーとタスクの互換性を確認する必要があります（各ビルドには約20があります）。
いや、まだ壊れた！ どのチケットが原因かをできるだけ早く把握する必要があります！ シンプルだが強力なSeleniumマネージャーシステムが役立ちます。 ステージングにある各タスクのショットでテスト実行の結果を表示し、実行されていないテストを実行できます（デフォルトでは、完全なスイートではなくショットが作成されたとき）。 したがって、あなたはしばしばチケットの犯人を見つけることができます...しかし、常にではありません。 次に、ログを調べて自分で有罪コードを探す必要があります。結局のところ、すべてを最適化できるわけではありません。

そして、この問題のあるチケットを見つけました。 すべてが完全に悪く、問題の解決に時間がかかる場合、ステージングからチケットをロールバックし、ビルドを再構築し、不運な開発者がインシデントを修正している間静かに作業を続けます。 しかし、エラーを修正するには、1行の1文字を変更するだけで十分ですか？

以前は、開発者はビルドブランチへの直接コミットによってこのような問題を修正しました。 それは十分に速くて便利ですが、QAの観点からは本当の悪夢です。 そのような「傷に付着したオオバコの葉」を確認することは、そのようなすべての修正を見つけ、別の場所で新しいエラーを引き起こした場合に犯人を見つけることは非常に難しく、さらに困難です。 そのように長く生きることは不可能であり、リリースエンジニアが独自のパッチインターフェイスを作成しました。



Gitパッチを現在のビルドに添付して、解決する問題の説明、作成者の名前、および別の開発者による予備レビューまたはQAによるテストの可能性を添付できます。 各パッチは特定のタスクに添付され、タスクがビルドからロールバックされると、それに添付されたすべてのパッチも自動的にポンプアウトされます。

誰もがすべてをチェックしたようです。 生産に行くことができるようです。 正確ですか？ 以前は、リリースを担当するエンジニアは、すべてが正常であるかどうかを自分で確認する必要がありました：テスト実行の結果を確認し、落ちたすべてのSeleniumテストが本当に修復されているか、すべてのタスクがチェックされているか、すべてのパッチがテストされ適用されているかを確認する...膨大な作業と多くの責任 したがって、特定のコンポーネント（またはテストブロック）の責任者全員が「私は元気です」をチェックできるようにするシンプルなインターフェイスをまとめ、プレート全体が緑色になったらすぐに行くことができます。



だから、やった！ あなたは祝福し、シャンパンを注ぎ、テーブルの上で踊ることができます...実際はそうではありません。 おそらく、まだ数時間の労働時間があります。 そして、おそらく-別のリリース。 しかし、これでさえ重要なことではありません。タスクの品質管理は、ユーザーへの送信時に終了しません！

5.生産検証

実稼働環境と数十万（ または数百万！ ）のユーザーのプレッシャーの下で、タスクが期待どおりに動作することを確認してください。 最初に、戦闘条件におけるシステムの作業能力とストレス耐性を評価するために、大規模で複雑なプロジェクトを聴衆の一部（たとえば特定の国の枠組み内のみ）にのみ配置しました。 プロセスのすべての参加者は、開発者、テスター、マネージャーなど、さまざまな角度からそのような実験の結果を評価することに関与しています。 そして、このような「実験」が成功したと認識され、新しい機能がすべてのユーザーに適用された後でも、本格的な監視部門の作業にもかかわらず、リリース後のシステムの状態を注意深く見ることは常に役立ちます。最も洗練されたテスターの脳が思い付くよりも。

なんで？

常に努力と開発の余地があります。 4年前、私はBadooに来て、ここですべてがかっこよく配置されていることに喜んでいた。 私はプロセスの開発に積極的に参加し、1年後にカンファレンスで講演し、より良くなったと話しました。 3年が経過しました。QaApiなしで、このようなクールな自動テストやその他の素晴らしく便利なものなしで、私たちがどのように生きてきたか想像できません。 自由時間に何とか座って、自分のプロセスで何を変更または改善したいかを想像してください。 あなたの想像力を解き放ち、最も素晴らしい機能を考え出し、仲間と共有してください。 これのいくつかは周りのすべての人にとってひどく必要であり、実装はあなたが思うほど素晴らしいものではないでしょう。 そして、あなた（ そして最終的にはユーザー ）は少し幸せになります。

クディノフイリヤシニア QAエンジニア