テスト環境の準備、または必要なテストインスタンスの数

プロジェクト内のテストベンチの数は5、10、または10を超えていますか？ 手っ取り早く、各開発チームのスタンド、各プロジェクトのQAのスタンド、プロジェクトマネージャーもスタンド、およびCIが必要です。これをすべて正確に区別することは難しく、競合状況を引き起こしません。 つまり、必要なときに正確にテストベンチを作成してみませんか？ テストベンチが必要になりました-作成しましたが、不要です-削除しました。



Alexander Dubrovin （ adbrvn ）が彼のレポートでHighload ++ 2017で提案したのはこのアプローチでした 。







スピーカーについて： Alexander DubrovinはSuperjobで働いています。 この会社のプロジェクトは非常に負荷が高いことが知られています。 しかし、今日はポータルにアクセスするユーザーの数やサーバーに保存されるデータの量については説明しませんが、他のインジケーターについては触れます。



将来を見据えて、実際には、Superjobはテストスタンドの数を知りません。 しかし、まず最初に。 ちょっとした話から始めましょう。

ちょっとした歴史

小さなプロジェクトSを想像してください。どこかにコードをテストする必要がある開発者チームがいます。 テストを整理するために、テストマシンを配置し、実稼働のように見せ、そこでコードをロールし、実行します。開発者はそこでテストを行うことができます。



ある時点で、チームは成長し始め、テスターのスタッフが必要になります。 QAスペシャリストが登場し、どこかでテストする必要もあります。



簡単なアプローチを使用できます-テスターに​​いくつかの領域を割り当て、そこで同じコピーを転がすと、彼らはすでにテストできます。 すべてが素晴らしいと良いです！





プロジェクトは成長を続け、追加の開発チームが現れます。 また、どこかでテストする必要があります。 このアプローチはすでによく知られています-テストサーバーの別の部分を分離します。



しかし実際には、チームも成長しています-1つのテストベンチでは十分ではありません。 また、より多くのタスクを実行するため、テスターは多くのテストを行う必要があります。







この段階で、面白い話に気づき始めることができます。 何らかの問題をテストしたいテスターVasyaがいるとします。 彼はテストベンチを選択し、そこでコードを転がしてテストを開始します。 彼はクリックし、クリックし、何かが正しくないこと、何かが機能していないこと、そして一般的にタスクが完了していないことを認識します。



チケットはJIRAに落ち始め、開発者は次の言葉でVasyaの近くに集まり始めます。 「そして、最終的に誰かが尋ねます：」そして、あなたはテストのためにどのブランチを展開しましたか？ ブランチはすぐに修正され、JIRAのチケットはクローズされます。すべて問題ありません。 Vasyaはテストを続け、すべてが彼のために機能しています。



しかし、この時点で、部屋の反対側で、Vovaの開発者は「奇妙なことですが、なぜ私にはうまくいかないのですか？」と考えます。しかし、彼はすぐにブランチが同じではないことに気付きます。 必要なものを展開すると、Vasyaは再び問題を抱えています。



数回の反復で、彼らは同じテストベンチでテストしているだけで、互いに干渉し合っていることに気付きます。 その結果、 時間の浪費 、VasyaとVovaは不幸です。



別の話。 開発者のKolyaはVasinaの問題を知っており、事前に彼に来て、どのテストベンチが現在無料かを尋ねます。 Vasyaは無料を示し、すべてが順調です。 数日後、彼らは再び会い、VasyaはKolyaに尋ねます。「テストベンチを私たちに返しますか？ 1時間かけて、2日が経過しました。」



そして再び問題-開発者が別のスタンドを探すか、テストが完了するまで誰もが元気に待つでしょう。



実際、上の図にすべてが表示されているわけではありません。 マネージャーが不足しています。 マネージャーは、まだテストされていない生のコードを見たい場合があります。 アプローチは標準です-テストサーバーのコーナーを再び強調表示し、テストスタンドを作成します。



このシステムの最後の部分はもちろんCIです。彼はどこかで撮影し、どこかでテストしたいと考えています。



このようなスキームをスムーズに開発することで、テストベンチの制御不能な変更を取得できます 。 このようなスタンドを実際に制御しないという点で、このスキームは良くありません-わかりません：

• 現在このスタンドでテストしているのは誰ですか。
  
  
• そこに展開されているもの;
  
  
• 彼が忙しいのか空いているかはまったくわかりません。
  
  

さらに、どのテストベンチが現在無料であるかはわかりません。その時点でいくつかのキューが存在する可能性があります。

アイデア

この瞬間、私たちは考えました-何をすべきか？ なぜこれほど多くのテストスタンドが必要なのですか？ 必要なときに正確にテストベンチを作成してみませんか？ テストベンチが必要になりました-作成しましたが、不要です-削除しました。



このアイデアの次のステップは、各コードブランチのテストベンチを作成することです。



良いアイデアのように思えますが、技術的なニュアンスがあります。 スタンドが必要です。

• 独立した ;
  
  
• 本番と非常によく似ています -本番環境により近いテストを行います。
  
  
• すぐにスタンドを作成できるため、ブランチが表示されるとすぐに、テストスタンドがすぐ下に表示されます。
  
  

理想的には、「 テストベンチを作成する 」ボタンが1つ必要です。

厳しい現実

私たちが持っている厳しい現実がまだあります：

• 大きな複雑なプロジェクト-かなり長い歴史を持つ巨大なPHPモノリス。
  
  
• 4つのドメインゾーンでのサービス。 ロシア、ウクライナ、ウズベク、ベラルーシの各ゾーンを同時にサポートしています。
  
  
• API、students.superjob.ruなどのサブドメインの集まり—ジオドメインとサービスサブドメイン。
  
  

そして、ある時点で、テスターはこれをすべてテストしたいと思うでしょう。 現在ウクライナでテストしていなくても、明日はウクライナ側の特別なページを作成するタスクがあります。これも考慮する必要があります。

すぐに言ってやった！

Docker / docker-compose



まず、テストスタンドを分離し、可能な限り同様にする必要があるという事実について説明しました。 最近では、これによりdockerを実装できます。 コンテナを実行する機会が与えられます。 明らかに、 1つのコンテナで管理することはありません 。さらに、同様のスタックをたくさん起動する必要があります。 したがって、 docker-composeが必要です。



素晴らしい-私たちは港湾労働者を使用します-それはスタイリッシュでファッショナブルな若者です。



モノリスを見た、サービスを選択



Dockerはマイクロサービスアプローチを推進していますが、ここではモノリスがあるために問題に直面しています。

マイクロサービスでモノリスを削減するのにかかる費用を見積もろうとしたことはありますか？ 明らかに、この数字は人年で測定されます。

ある時点で、システムのコンポーネント図を見て、ここにロードバランシングがあることを確認しました。ここはphpアプリケーション、ここはnode.jsアプリケーションです。 サービスとしてそれだけを始めてみませんか。 Dockerコンテナで実行できるものを見つけましょう。



ネットワークを設定しました



さらに、テストベンチに何らかの方法で到達する必要があります。 当然、ブラウザがテストスタンドを開くことができるように80番目のポートを引き出す必要がありますが、同じマシン内でそのようなスタンドを起動する場合は、IPを発行する必要があります。



ドキュメントには、ネットワークのセットアップに関する大きなセクションがあります。



Dockerはさまざまなタイプのネットワークを使用できます。 私たちの場合、macvlanのようなネットワークが本当に役立ちました。 これは、1つの物理ネットワークインターフェースに仮想ネットワークインターフェースのバンドルを実装できるテクノロジーです。 同時に、docker自体がこれらのインターフェイスを管理します：作成、マシンへの追加、ホストマシンに関連する外部IPアドレスの受信。



したがって、コンテナーのパックを開始し、フロントコンテナー（バランサー）に外部IPアドレスを取得し、その80番目のポートを開く機会を与えることができます。 ブラウザを使用して、すでにそこをノックすることができます。



DNSとAPIを上げる



ドメインゾーンと多数のサブドメインがあることを覚えています。 したがって、2番目のレベルのドメインでのみテストベンチにアクセスできます。 巨大なプラスと巨大なマイナスの両方があります：

• マイナス -ゾーンごとにru、ua、uzの実際のドメインをどういうわけか重複させる必要があります。
  
  
• さらに 、第2レベルのドメインとして、ブランチの特定の名前を直接縫うことができます-各コードブランチのテストスタンドを行います。
  
  

したがって、 明確で簡潔で明確なアドレスを取得します 。このアドレスには 、すでにコード分岐の指示が含まれています。



欠点は本当に簡単です。 ドメインをオーバーラップする必要がある場合は、プレフィックスを追加するだけで、オーバーラップするドメインのセットを制限します。これは既に我慢できます。



この例では、sjプレフィックスを選択しました。 ドメインをsjプレフィックスのみでオーバーラップする必要があることがわかります。明らかにこれらの多くはありません。



DNSのもう1つの部分はAPIです。 すでに述べたように、テストスタンドをすばやく上げる必要があります。 したがって、自動モードのAPIでエントリをすばやく追加および削除できるDNSサーバーが必要です。



ソリューションはPowerDNSです。 このサーバーを使用すると、APIをすばやく簡単に固定し、スクリプトを使用してテストスタンドを追加および削除できます。



いいね！ DNSを作成および構成し、コンテナにIPを登録するように教えましたが、何かが欠落しています。



SSL-CAの作成



私たちは21世紀に住んでいます。 明らかに、すべてのインターネットSSLおよびテストスイートはSSLをサポートする必要があります 。 十分なバグはSSL固有のものであり、混合コンテンツは氷山の一角にすぎません。



合計で、証明書を迅速に取得し、それを上昇中のテストベンチに迅速に適用する方法が必要です。 当社にはすでにOpenSSLに基づく認証局がありました。 ここでは、自転車を書く簡単な方法を使用しました。



自転車は1日で作成され、GET要求を使用して、特定のドメイン名に対して既に生成された証明書を受信できます。



最小のままです。 このすべてを1つのボタンで行いたいため、これを自動化する必要があります。



自動化



私たち自身の初期段階では、テストベンチを単純に上げるか削除することができるコンソールスクリプトを作成しました。



明らかに、これはテスターに​​とってあまり便利ではありません。 したがって、たとえば、テストベンチを組み立てて実行する特別なアセンブリを作成できます。



しかし、実際には、この点で最もクールなステップは、JIRAチケットにそのようなボタンを直接追加することです。 テスターがJIRAチケットを開き、リクエストを読み取り、ボタンを押して、数分でテストベンチを受け取ると想像してください。

長所

• 当初、テスターが自分のコードの任意のバージョンを実行してクリックできるように、これを手動テスト専用に計画しました。
  
  
• 次の追加ボーナス- デモホストがあります 。 これは同じです。テスターのみがJIRAチケットを入力せず、プロジェクトマネージャーを入力します。 また、生のコードを見てクリックすることもできます。
  
  
• CIに大きなプラスを獲得しました。 CIをまったく同じ方法で教え、テストベンチを特定のバージョンのコードに上げてから削除すると、どのブランチでも絶対にすべてのテストを実行する機会がありました。 最も複雑なインターフェイスのセレンテストでさえ、プロジェクトの任意のブランチに対してワンクリックで実行できます。
  
  

短所

しかし、スタンドの管理には微妙な欠点もあります 。 それらを正しく管理する方法を学ぶ必要があります。



システムの最初のバージョンを古い脆弱なサーバーに展開し、新しいブランチごとにテストスタンドの作成をセットアップしました。 もちろん、1日か半分でサーバーが対処できませんでした -単に多くのブランチがあるからです。



次に、それらの自動作成を停止し、JIRAにボタンが表示され、CIはテストスタンドの開始と停止、ログの収集を学びました。



このシステムでは解決できないタスクのクラスが間違いなくあります。 たとえば、頻繁に発生するポップアップの問題は、すべてのコンテナの合計時間です。 サーバーの時間をずらして、いくつかのタスクをテストすると便利です。 残念ながら、このシステムではこのような問題を解決することはできません。 ただし、テストのためにコードに特別なブランチを追加することにより、このような問題を解決できるため、たとえば、2週間後のフォームの動作を確認できます。

まとめ

入り口にはテストベンチのシステムがあり、テストベンチを探すことを余儀なくされ、これらのテストベンチで誰も干渉しないという保証はありませんでした。

「Vasya、そしてどんな種類のテストが無料です-私は自分のタスクをテストするのです。」

出力は1つのボタンで 、クリックして数分で特定のバージョンのコードの完成したテストベンチを取得できます。 複数の人がこのスタンドを使用している場合でも、これらの人がこの特定のバージョンのコードを見たいと思うことが保証されています。

「ボタンを押すと、1分半で特定のタスク用の新しいテストスタンドが手に入ります。」

ボーナスとして、すべてのテストをワンクリックで取得できました。 先ほど言ったように、CIから直接分岐するすべてのテストは、1つのボタンで選択されます。 その後、マシンはすべてを実行します。テストベンチを上げ、発射し、ログを収集して削除します。



最初の質問に戻りますが、テストスタンドはいくつ必要ですか。 必要なテストスタンドの数はわかりません。今日必要なテストスタンドは20、明日-15、明後日の25です。



しかし、 ここで必要な数のテストベンチがあることは確かです。

時間が経ち、 RIT ++カンファレンスフェスティバルの前にはほとんど残っていませんが、5月28日と29日にスコルコボで開催されることを思い出します。 この機会を利用して、幅広いリスナー向けのRootConfアプリケーションの小さなセレクションを紹介します。

• ダニエル・ミガリン （マイクロソフト）。 シンプルなツールを使用した、自動で信頼性の高い管理可能な展開。
  
  
• アレクセイ・パラジチェンコ （ペルコナ）。 プロメテウス指標の長期保存。
  
  
• ミハイル・クズミン （JetBrains）。 仮想マシン配信パイプライン。
  
  
• ニコライ・シヴコ （okmeter.io）。 負荷分散を微調整します。
  
  

あなたはまだチケットを予約することができますが、忘れないでください、価格は着実に増加しています。