パート 1: ウェブ/Android

注意: この記事は元の記事のロシア語への翻訳です 「DevOps ツールは DevOps のためだけのものではありません。 「テスト自動化インフラストラクチャをゼロから構築する。」 ただし、ロシア語に翻訳する際の意味の歪みを避けるために、すべてのイラスト、リンク、引用、用語は元の言語で保存されます。 楽しく勉強できることを祈っています！

現在、DevOps の専門分野は IT 業界で最も需要が高い分野の XNUMX つです。 人気の求人サイトを開いて給与でフィルターすると、DevOps 関連の仕事がリストの一番上にあることがわかります。 ただし、これは主に「上級」のポジションを指しており、候補者が高度なスキル、テクノロジー、ツールの知識を持っていることを意味していることを理解することが重要です。 これには、中断のない生産運営に伴う高度な責任も伴います。 しかし、私たちは DevOps が何なのかを忘れ始めていました。 当初は、特定の人物や部門を対象としたものではありませんでした。 この用語の定義を探すと、方法論、実践、文化哲学、概念群など、美しく正しい名詞がたくさん見つかります。

私の専門はテスト自動化エンジニア (QA 自動化エンジニア) ですが、自動テストの作成やテスト フレームワーク アーキテクチャの開発だけに関連付けるべきではないと考えています。 2020 年には、自動化インフラストラクチャに関する知識も不可欠です。 これにより、テストの実行からすべての関係者への結果の提供まで、目標に応じて自動化プロセスを自分で組織することができます。 そのため、仕事を遂行するには DevOps スキルが必須となります。 これはすべて良いことですが、残念ながら問題があります (スポイラー: この記事はこの問題を単純化しようとしています）。 重要なのは、DevOps は難しいということです。 これは明らかです。なぜなら、簡単に実行できるものに企業は大金を払わないからです。DevOps の世界には、習得する必要のあるツール、用語、実践方法が多数あります。 これはキャリアの初期には特に難しく、蓄積された技術経験に依存します。

出所： http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

ここで導入部分を終了し、この記事の目的に焦点を当てたいと思います。 

この記事は何についてですか?

この記事では、テスト自動化インフラストラクチャを構築した私の経験を共有します。 インターネット上には、さまざまなツールとその使用方法に関する情報源がたくさんありますが、ここでは純粋に自動化という観点からそれらを見ていきたいと思います。 多くの自動化エンジニアは、開発されたテストを自分以外の誰も実行したり、メンテナンスに関心を持ったりしない状況をよく知っていると思います。 その結果、テストが古くなり、更新に時間を費やす必要があります。 繰り返しになりますが、キャリアの初期段階では、これは非常に困難な作業になる可能性があります。特定の問題を解決するのにどのツールが役立つのか、またそれらをどのように選択、構成、保守するかを賢明に決定することです。 テスターの中には DevOps (人間) に助けを求める人もいますが、正直に言うと、このアプローチは機能します。 すべての依存関係を把握できないため、多くの場合、これが唯一の選択肢となります。 しかしご存知のとおり、DevOps は組織やチームに応じて会社全体のインフラストラクチャ、デプロイメント、モニタリング、マイクロサービス、その他同様のタスクについて考えなければならないため、非常に多忙です。 通常のことですが、自動化は優先事項ではありません。 このような場合、私たちは最初から最後まで私たち自身でできる限りのことを行わなければなりません。 これにより、依存関係が減り、ワークフローがスピードアップし、スキルが向上し、何が起こっているのか全体像を把握できるようになります。

この記事では、最も人気のあるツールを紹介し、それらを使用して自動化インフラストラクチャを構築する方法を段階的に示します。 各グループは、個人的な経験を通じてテストされたツールによって表されます。 しかし、同じものを使用しなければならないというわけではありません。 ツール自体は重要ではなく、出現しては廃れていきます。 私たちのエンジニアリングの課題は、なぜこのグループのツールが必要なのか、そしてそれらの助けを借りてどのような作業上の問題を解決できるのかという基本原則を理解することです。 そのため、各セクションの最後に、組織で使用できる同様のツールへのリンクを残しています。

この記事にないもの

もう一度繰り返しますが、この記事は特定のツールに関するものではないため、ドキュメントからのコードの挿入や特定のコマンドの説明はありません。 ただし、各セクションの最後に詳細な学習用のリンクを残しています。

これは次の理由で行われます。 

• この資料はさまざまなソース (ドキュメント、書籍、ビデオ コース) で簡単に見つけることができます。
• さらに深く掘り下げ始めると、この記事の 10、20、30 部分を書かなければなりません (計画は 2 ～ 3 個ですが)。
• 同じ目標を達成するために他のツールを使用することもあるかもしれないので、時間を無駄にしたくありません。

練習

この資料が、ただ読んで忘れられるのではなく、すべての読者にとって有益であることを心から望んでいます。 どのような勉強においても、実践は非常に重要な要素です。 このために私は準備しました すべてを最初から行う方法を段階的に説明した GitHub リポジトリ。 実行中のコマンド行をむやみにコピーしないようにするという宿題もあります。

計画

手順
テクノロジー
ツール

1
ローカル実行 (Web/Android デモ テストを準備し、ローカルで実行) 
Node.js、Selenium、Appium

2
バージョン管理システム 
Gitの

3
コンテナ化
Docker、Selenium グリッド、Selenoid (Web、Android)

4
CI/CD
Gitlab CI

5
クラウドプラットフォーム
Google Cloud Platform

6
編成
Kubernetes

7
コードとしてのインフラストラクチャ (IaC)
Terraform、Ansible

各部の構成

物語を明確にするために、各セクションは次の概要に従って説明されています。

• テクノロジーの簡単な説明、
• 自動化インフラストラクチャの価値、
• インフラストラクチャの現在の状態の図、
• 勉強へのリンク、
• 同様のツール。

1. ローカルでテストを実行する

テクノロジーの簡単な説明

これは、デモ テストをローカルで実行し、テストが成功することを確認するための単なる準備ステップです。 実践部分ではNode.jsを使用しますが、プログラミング言語やプラットフォームも重要ではなく、社内で使用されているものを使用できます。 

ただし、自動化ツールとして、Web プラットフォームには Selenium WebDriver を、Android プラットフォームには Appium をそれぞれ使用することをお勧めします。次のステップでは、これらのツールで特に動作するように調整された Docker イメージを使用するためです。 さらに、仕事の要件を考慮すると、これらのツールは市場で最も需要が高いです。

お気づきかもしれませんが、ここでは Web テストと Android テストのみを考慮します。 残念ながら、iOS はまったく別の話です (Apple に感謝)。 今後のパートでは、IOS 関連のソリューションと実践方法を紹介する予定です。

自動化インフラストラクチャの価値

インフラストラクチャの観点から見ると、ローカルで実行しても何の価値もありません。 テストがローカル ブラウザーとシミュレーターのローカル マシン上で実行されることを確認するだけです。 しかし、いずれにせよ、これは必要な出発点です。

インフラの現状イメージ

探索するためのリンク

• Selenium
• アピウム
• Androidエミュレータ
• Selenium JS GitHub の例
• Appium JS GitHub の例

同様のツール

• Selenium/Appium テストと組み合わせた任意のプログラミング言語。
• あらゆるテスト。
• あらゆるテストランナー。

2. バージョン管理システム (Git)

テクノロジーの簡単な説明

チームでも個人でも、バージョン管理は開発において非常に重要な部分であると言っても、誰にとっても大きな発見ではないでしょう。 さまざまな情報源に基づくと、Git が最も人気のある代表であると言っても過言ではありません。 バージョン管理システムには、コードの共有、バージョンの保存、以前のブランチへの復元、プロジェクト履歴の監視、バックアップなど、多くの利点があります。 皆さんもよくご存じで、日々の業務で使用されていると思いますので、各点について詳しくは説明しません。 しかし、突然そうでなくなった場合は、この記事を読むのを一時停止し、できるだけ早くこのギャップを埋めることをお勧めします。

自動化インフラストラクチャの価値

ここで、次のような当然の質問をすることができます。「なぜ彼は Git について私たちに話しているのですか?」 これは誰もが知っており、開発コードと自動テスト コードの両方に使用しています。」 確かにその通りですが、この記事ではインフラストラクチャについて説明しており、このセクションはセクション 7: 「Infra Structure as Code (IaC)」のプレビューとして機能します。 私たちにとって、これは、テストを含むインフラストラクチャ全体がコードの形式で記述されることを意味するため、バージョン管理システムをインフラストラクチャに適用することもでき、開発コードや自動化コードと同様の利点が得られます。

IaC についてはステップ 7 で詳しく説明しますが、ローカル リポジトリを作成することで、今でもローカルで Git の使用を開始できます。 リモート リポジトリをインフラストラクチャに追加すると、全体像が拡大します。

インフラの現状イメージ

探索するためのリンク

• バージョン管理とは何ですか
• Gitの
• はじめに - バージョン管理について

同様のツール

• SVN
• 活発 
• Microsoft TFS (現在は Azure DevOps Services の一部です)

3. コンテナ化（Docker）

テクノロジーの簡単な説明

コンテナ化がゲームのルールをどのように変えたかを示すために、数十年前に戻ってみましょう。 当時、人々はアプリケーションを実行するためにサーバー マシンを購入して使用していました。 しかし、ほとんどの場合、必要な起動リソースは事前にはわかりませんでした。 その結果、企業は高価で強力なサーバーの購入に資金を投じましたが、この容量の一部は完全に活用されていませんでした。

進化の次の段階は仮想マシン (VM) で、未使用のリソースにお金を浪費する問題を解決しました。 このテクノロジーにより、完全に分離されたスペースを割り当て、同じサーバー内でアプリケーションを互いに独立して実行できるようになりました。 しかし、残念ながら、どんなテクノロジーにも欠点はあります。 VM を実行するには完全なオペレーティング システムが必要で、CPU、RAM、ストレージを消費し、OS によってはライセンス コストを考慮する必要があります。 これらの要因は読み込み速度に影響を与え、移植性を困難にします。

そしていよいよコンテナ化です。 繰り返しますが、このテクノロジーはコンテナが完全な OS を使用しないため、前の問題を解決します。これにより、大量のリソースが解放され、移植性のための高速かつ柔軟なソリューションが提供されます。

もちろん、コンテナ化テクノロジーは新しいものではなく、70 年代後半に初めて導入されました。 当時、多くの研究、開発、試みが行われました。 しかし、このテクノロジーを適応させ、一般の人が簡単にアクセスできるようにしたのは Docker でした。 現在、コンテナーについて話すとき、ほとんどの場合、Docker を指します。 Docker コンテナーについて話すときは、Linux コンテナーを意味します。 Windows および macOS システムを使用してコンテナーを実行できますが、この場合は追加のレイヤーが表示されることを理解することが重要です。 たとえば、Mac 上の Docker は、軽量の Linux VM 内でコンテナをサイレントに実行します。 コンテナ内での Android エミュレータの実行について説明するときにこのトピックに戻ります。そのため、ここではさらに詳しく説明する必要がある非常に重要なニュアンスがあります。

自動化インフラストラクチャの価値

コンテナ化と Docker が優れていることがわかりました。 すべてのツールやテクノロジーは問題を解決する必要があるため、これを自動化のコンテキストで見てみましょう。 UI テストのコンテキストにおけるテスト自動化の明らかな問題の概要を説明します。

• Selenium、特に Appium をインストールする際の膨大な数の依存関係。
• ブラウザ、シミュレータ、ドライバのバージョン間の互換性の問題。
• ブラウザ/シミュレータ用の独立したスペースが不足していること。これは並列実行の場合に特に重要です。
• 10、50、100、さらには 1000 のブラウザを同時に実行する必要がある場合、管理と保守が困難になります。

しかし、Selenium は最も人気のある自動化ツールであり、Docker は最も人気のあるコンテナ化ツールであるため、誰かがこれらを組み合わせて、上記の問題を解決する強力なツールを作成しようとしたことは驚くべきことではありません。 このような解決策をさらに詳しく検討してみましょう。 

Docker の Selenium グリッド

このツールは、複数のマシン上で複数のブラウザを実行し、それらを中央ハブから管理するための Selenium の世界で最も人気のあるツールです。 まず、ハブとノードの少なくとも 2 つの部分を登録する必要があります。 ハブは、テストからすべてのリクエストを受信し、それらを適切なノードに分散する中央ノードです。 ノードごとに、たとえば、目的のブラウザとそのバージョンを指定することによって、特定の構成を構成できます。 ただし、互換性のあるブラウザ ドライバーを自分で用意し、目的のノードにインストールする必要があります。 このため、Linux OS にインストールできないブラウザを操作する必要がある場合を除き、Selenium グリッドはそのままの形式では使用されません。 他のすべてのケースの場合、非常に柔軟で正しい解決策は、Docker イメージを使用して Selenium グリッド ハブとノードを実行することです。 このアプローチでは、互換性のあるバージョンのブラウザーと既にインストールされているドライバーで必要なイメージを選択できるため、ノード管理が大幅に簡素化されます。

特に多数のノードを並列実行する場合の安定性に関する否定的なレビューにもかかわらず、Selenium グリッドは依然として Selenium テストを並列実行するための最も人気のあるツールです。 このツールのさまざまな改良や変更がオープンソースで常に公開されており、さまざまなボトルネックと闘っていることに注意することが重要です。

Web用セレノイド

このツールは、箱から出してすぐに動作するため、Selenium の世界における画期的なツールであり、多くの自動化エンジニアの作業を大幅に楽にしました。 まず第一に、これは Selenium グリッドの別の変更ではありません。 代わりに、開発者は Golang で完全に新しいバージョンの Selenium Hub を作成し、さまざまなブラウザー用の軽量 Docker イメージと組み合わせて、テスト自動化の開発に弾みをつけました。 さらに、Selenium Grid の場合は、必要なすべてのブラウザとそのバージョンを事前に決定する必要がありますが、XNUMX つのブラウザだけで作業する場合には問題ありません。 しかし、サポートされている複数のブラウザに関して言えば、「ブラウザ オン デマンド」機能のおかげで、Selenoid がナンバーワンのソリューションとなります。 必要な作業は、事前にブラウザで必要なイメージをダウンロードし、Selenoid が連携する設定ファイルを更新するだけです。 Selenoid がテストからリクエストを受信すると、目的のブラウザーで目的のコンテナーが自動的に起動します。 テストが完了すると、Selenoid はコンテナをリタイアし、将来のリクエストのためにリソースを解放します。 このアプローチにより、Selenium グリッドでよく遭遇する「ノードの劣化」というよく知られた問題が完全に排除されます。

しかし、残念なことに、Selenoid はまだ特効薬ではありません。 「ブラウザ オン デマンド」機能は利用できましたが、「リソース オン デマンド」機能はまだ利用できません。 Selenoid を使用するには、それを物理ハードウェアまたは VM にデプロイする必要があります。つまり、割り当てる必要があるリソースの数を事前に把握しておく必要があります。 10、20、さらには 30 個のブラウザを並行して実行する小規模なプロジェクトでは、これは問題にならないと思います。 しかし、100、500、1000 などの数が必要な場合はどうなるでしょうか? 非常に多くのリソースを維持し、その費用を常に支払うのは意味がありません。 この記事のセクション 5 と 6 では、拡張を可能にして企業コストを大幅に削減するソリューションについて説明します。

Android用セレノイド

Web 自動化ツールとして Selenoid が成功した後、人々は Android にも同様のものを求めました。 そしてそれは起こりました - Selenoid は Android をサポートしてリリースされました。 高レベルのユーザーの観点から見ると、動作原理は Web オートメーションと似ています。 唯一の違いは、Selenoid はブラウザ コンテナの代わりに Android エミュレータ コンテナを実行することです。 私の意見では、これは Android テストを並行して実行するための現時点で最も強力な無料ツールです。

私はこのツールが本当に気に入っているので、このツールのマイナス面についてはあまり話したくないのです。 ただし、Web オートメーションにも同様のデメリットがあり、スケーリングに関連しています。 これに加えて、初めてツールをセットアップする場合に驚くかもしれないもう XNUMX つの制限についても説明する必要があります。 Android イメージを実行するには、ネストされた仮想化をサポートする物理マシンまたは VM が必要です。 ハウツー ガイドでは、Linux VM でこれを有効にする方法を示します。 ただし、macOS ユーザーで Selenoid をローカルにデプロイしたい場合は、Android テストを実行することはできません。 ただし、「ネストされた仮想化」が構成された Linux VM をローカルで実行し、内部に Selenoid をデプロイすることはいつでも可能です。

インフラの現状イメージ

この記事では、インフラストラクチャを説明するために 2 つのツールを追加します。 これらは、Web テスト用の Selenium グリッドと Android テスト用の Selenoid です。 GitHub チュートリアルでは、Selenoid を使用して Web テストを実行する方法も説明します。 

探索するためのリンク

• Docker: コンテナとは何ですか
• Docker: 始めましょう
• Docker に代わる 5 つのコンテナ
• セレングリッド
• Selenium ドッカー
• セレノイド
• セレノイド Github
• Android エミュレータ用の KVM セットアップ
• Docker のディープダイブブック

同様のツール

• 他にもコンテナ化ツールはありますが、Docker が最も人気があります。 別のことを試したい場合は、Selenium テストを並行して実行するためにここで取り上げたツールは、そのままでは機能しないことに注意してください。  
• すでに述べたように、Selenium グリッドには多くの変更が加えられています。たとえば、 ザレニウム.

4.CI/CD

テクノロジーの簡単な説明

継続的統合の実践は開発において非常に一般的であり、バージョン管理システムと同等です。 それにもかかわらず、用語に混乱があるように感じます。 この段落では、私の観点からこのテクノロジーの 3 つの変更点について説明したいと思います。 インターネット上にはさまざまな解釈の記事がたくさんありますが、自分の意見が異なるのはごく普通のことです。 最も重要なことは、同僚と同じ認識を持っていることです。

つまり、CI - 継続的インテグレーション、CD - 継続的デリバリー、そして再び CD - 継続的デプロイメントという 3 つの用語があります。 (以下ではこれらの用語を英語で使用します）。 変更を加えるたびに、開発パイプラインにいくつかの追加ステップが追加されます。 しかし、その言葉は 連続的な （継続）が一番大事です。 この文脈では、中断や手動介入なしに、最初から最後まで起こることを意味します。 この文脈で CI & CD と CD を見てみましょう。

• 継続的インテグレーション これは進化の最初のステップです。 新しいコードをサーバーに送信した後、変更が正常であるというフィードバックをすぐに受け取ることが期待されます。 通常、CI には静的コード分析ツールの実行とユニット/内部 API テストが含まれており、これによりコードに関する情報を数秒/数分以内に取得できます。
• 連続放出 これは、統合/UI テストを実行するより高度なステップです。 ただし、この段階では CI ほど早く結果は得られません。 まず、この種のテストは完了までに時間がかかります。 次に、起動する前に、変更をテスト/ステージング環境にデプロイする必要があります。 さらに、モバイル開発について話している場合、アプリケーションのビルドを作成するための追加のステップが表示されます。
• 継続的な展開 前の段階ですべての受け入れテストに合格した場合、変更が自動的に本番環境にリリースされることを前提としています。 これに加えて、リリース段階の後は、本番環境でのスモーク テストの実行や関心のあるメトリクスの収集など、さまざまな段階を構成できます。 継続的デプロイメントは、自動テストが適切にカバーされている場合にのみ可能です。 テストなどの手動介入が必要な場合、これは不要になります。 連続的な （継続）。 そうすれば、私たちのパイプラインは継続的デリバリーの実践にのみ準拠していると言えます。

自動化インフラストラクチャの価値

このセクションでは、エンドツーエンドの UI テストについて話すとき、変更と関連サービスをテスト環境にデプロイする必要があることを意味することを明確にする必要があります。 継続的インテグレーション - このプロセスはこのタスクには適用されないため、少なくとも継続的配信プラクティスの実装に注意する必要があります。 継続的デプロイメントは、実稼働環境で実行する場合の UI テストのコンテキストでも意味があります。

アーキテクチャの変更の図を見る前に、GitLab CI について少しお話したいと思います。 他の CI/CD ツールとは異なり、GitLab はリモート リポジトリやその他の多くの追加機能を提供します。 したがって、GitLab は単なる CI ではありません。 これには、ソース コード管理、アジャイル管理、CI/CD パイプライン、ロギング ツール、すぐに使えるメトリクス収集が含まれています。 GitLab アーキテクチャは、Gitlab CI/CD と GitLab Runner で構成されます。 公式ウェブサイトからの簡単な説明は次のとおりです。

Gitlab CI/CD は、状態をデータベースに保存し、プロジェクト/ビルドを管理し、ユーザー インターフェイスを提供する API を備えた Web アプリケーションです。 GitLab Runnerはビルドを処理するアプリケーションです。 個別にデプロイでき、API を通じて GitLab CI/CD と連携します。 テストを実行するには、Gitlab インスタンスと Runner の両方が必要です。

インフラの現状イメージ

探索するためのリンク

• Martin Fowler: 継続的インテグレーション
• GitLab CI / CD
• 継続的インテグレーションの本
• 継続的デリバリーの本

同様のツール

• ジェンキンズ
• TeamCity
• トラビス 
• そして他の多く

5. クラウドプラットフォーム

テクノロジーの簡単な説明

このセクションでは、「パブリック クラウド」と呼ばれる人気のトレンドについて説明します。 上記の仮想化およびコンテナ化テクノロジが提供する多大なメリットにもかかわらず、依然としてコンピューティング リソースが必要です。 企業は高価なサーバーを購入したり、データセンターを借りたりしますが、この場合、必要なリソースの数、それらを 24 時間年中無休で使用するかどうか、およびどのような目的に使用するかについて (非現実的な場合もありますが) 計算する必要があります。 たとえば、本番環境では 7 時間年中無休で稼働するサーバーが必要ですが、勤務時間外のテストにも同様のリソースが必要でしょうか? また、実行されるテストの種類によっても異なります。 例としては、翌日結果を得るために勤務時間外に実行する予定の負荷/ストレス テストが挙げられます。 しかし、エンドツーエンドの自動テスト、特に手動テスト環境では、サーバーの XNUMX 時間 XNUMX 日の可用性は明らかに必要ありません。 このような状況では、オンデマンドで必要なだけリソースを取得して使用し、不要になったら支払いを停止するのが良いでしょう。 さらに、マウスを数回クリックするか、いくつかのスクリプトを実行するだけで、それらを即座に受信できれば素晴らしいでしょう。 これがパブリック クラウドの用途です。 定義を見てみましょう。

「パブリック クラウドは、サードパーティ プロバイダーがパブリック インターネット上で提供するコンピューティング サービスとして定義され、使用または購入したい人なら誰でも利用できるようになります。 これらは無料またはオンデマンドで販売される場合があり、顧客は消費した CPU サイクル、ストレージ、または帯域幅の使用量に応じてのみ支払うことができます。」

パブリッククラウドは高価だという意見があります。 しかし、彼らの重要なアイデアは会社のコストを削減することです。 前述したように、パブリック クラウドを使用すると、オンデマンドでリソースを取得し、使用した時間に対してのみ料金を支払うことができます。 また、従業員は給料をもらっていること、スペシャリストも高価な人材であることを忘れてしまうことがあります。 パブリック クラウドによりインフラストラクチャのサポートがはるかに容易になり、エンジニアがより重要なタスクに集中できるようになることを考慮する必要があります。 

自動化インフラストラクチャの価値

エンドツーエンドの UI テストには具体的にどのようなリソースが必要ですか? 基本的に、これらはブラウザーとエミュレーターを実行するための仮想マシンまたはクラスターです (Kubernetes については次のセクションで説明します)。 同時に実行したいブラウザやエミュレータの数が増えるほど、より多くの CPU とメモリが必要になり、そのために支払わなければならない費用も増えます。 したがって、テスト自動化のコンテキストにおけるパブリック クラウドを使用すると、オンデマンドで多数 (100、200、1000...) のブラウザ/エミュレータを実行し、できるだけ早くテスト結果を取得し、そのような非常にリソースを大量に消費するコストの支払いを停止することができます。力。 

最も人気のあるクラウド プロバイダーは、アマゾン ウェブ サービス (AWS)、Microsoft Azure、Google Cloud Platform (GCP) です。 ハウツー ガイドには GCP の使用方法の例が記載されていますが、一般的には自動化タスクに何を使用するかは問題ではありません。 これらはすべてほぼ同じ機能を提供します。 通常、プロバイダーを選択する際、管理者は会社の全体的なインフラストラクチャとビジネス要件に焦点を当てますが、これについてはこの記事の範囲を超えています。 自動化エンジニアにとっては、クラウド プロバイダーの使用と、特にテスト目的のクラウド プラットフォーム (Sauce Labs、BrowserStack、BitBar など) の使用を比較する方が興味深いでしょう。 じゃあ、私もやってみよう！ 私の意見では、Sauce Labs が最も有名なクラウド テスト ファームであるため、比較に使用しました。 

自動化を目的とした GCP と Sauce Labs の比較:

8 つの Web テストと 8 つの Android テストを同時に実行する必要があると想像してみましょう。 このために、GCP を使用し、Selenoid で 2 つの仮想マシンを実行します。 最初のコンテナでは、ブラウザを使用して 8 つのコンテナを起動します。 8 番目には、エミュレータを備えた XNUMX つのコンテナがあります。 価格を見てみましょう:  

Chrome で XNUMX つのコンテナを実行するには、次のものが必要です。 n1-標準-1 車。 Androidの場合はこうなります n1-標準-4 XNUMXつのエミュレータの場合。 実際、より柔軟で安価な方法は、CPU/メモリに特定のユーザー値を設定することですが、現時点では、これは Sauce Labs との比較では重要ではありません。

Sauce Labs を使用する場合の料金は次のとおりです。

すでに違いに気づいていると思いますが、タスクの計算を表に示しておきます。

必要なリソース
毎月
労働時間(午前8時～午後8時)
労働時間+ プリエンプティブル

ウェブ向け GCP
n1-標準-1 x 8 = n1-標準-8
$194.18
23 日 * 12 時間 * 0.38 = 104.88 ドル 
23 日 * 12 時間 * 0.08 = 22.08 ドル

Web 用 Sauce Labs
Virtual Cloud8 の並列テスト
$1.559
-
-

Android 向け GCP
n1-standard-4 x 8: n1-standard-16
$776.72
23 日 * 12 時間 * 1.52 = 419.52 ドル 
23 日 * 12 時間 * 0.32 = 88.32 ドル

Android 用 Sauce Labs
Real Device Cloud 8 の並列テスト
$1.999
-
-

ご覧のとおり、特に XNUMX 時間の稼働時間内にのみテストを実行する場合、コストの差は非常に大きくなります。 ただし、プリエンプティブル マシンを使用すると、さらにコストを削減できます。 それは何ですか？

プリエンプティブル VM は、通常のインスタンスよりもはるかに安い価格で作成および実行できるインスタンスです。 ただし、他のタスクでこれらのリソースへのアクセスが必要な場合、Compute Engine はこれらのインスタンスを終了（プリエンプト）する場合があります。 プリエンプティブル インスタンスは Compute Engine の余剰容量であるため、その可用性は使用状況によって異なります。

アプリがフォールト トレラントであり、インスタンスのプリエンプションに耐えられる場合、プリエンプティブル インスタンスによって Compute Engine のコストを大幅に削減できます。 たとえば、バッチ処理ジョブはプリエンプティブル インスタンス上で実行できます。 これらのインスタンスの一部が処理中に終了すると、ジョブは遅くなりますが、完全には停止しません。 プリエンプティブル インスタンスは、既存のインスタンスに追加のワークロードを課すことなく、また追加の通常のインスタンスに対して全額を支払う必要もなく、バッチ処理タスクを完了します。

そしてまだ終わっていないのです！ 実際には、休憩なしで 12 時間テストを実行する人はいないと思います。 その場合は、仮想マシンが不要なときに自動的に起動および停止できます。 実際の使用時間は 6 日あたり 11 時間に短縮される場合があります。 そうすれば、私たちのタスクのコンテキストでの支払いは、8 つのブラウザで月額 XNUMX ドルに減ります。 これは素晴らしいと思いませんか？ しかし、プリエンプティブル マシンの場合は、中断や不安定性に注意し、備えておく必要があります。ただし、これらの状況はソフトウェアで提供および処理できます。 価値があります！

しかし、私は決して「クラウド テスト ファームを決して使用しない」と言っているのではありません。 これらには多くの利点があります。 まず第一に、これは単なる仮想マシンではなく、リモート アクセス、ログ、スクリーンショット、ビデオ録画、さまざまなブラウザー、物理モバイル デバイスなど、すぐに使用できる一連の機能を備えた本格的なテスト自動化ソリューションです。 多くの状況で、これは不可欠なシックな代替品になります。 テスト プラットフォームは、パブリック クラウドが Linux/Windows システムしか提供できない場合、IOS 自動化に特に役立ちます。 ただし、iOS については次の記事で説明します。 常に状況を見て、タスクから始めることをお勧めします。場合によっては、パブリック クラウドを使用した方が安価で効率的ですが、他の場合には、テスト プラットフォームにお金を費やす価値があることは明らかです。

インフラの現状イメージ

探索するためのリンク

• GCP
• GCP: プリエンプティブル
• GCP: VM の料金
• ソースラボ
• クラウドプロバイダーの比較

同様のツール:

• AWS 
• Azure

6. オーケストレーション

テクノロジーの簡単な説明

良いニュースがあります。記事ももうすぐ終わりに近づいています。 現時点では、当社の自動化インフラストラクチャは Web テストと Android テストで構成されており、Docker 対応ツールである Selenium グリッドと Selenoid を使用して、GitLab CI を通じて並行して実行します。 さらに、GCP 経由で作成された仮想マシンを使用して、ブラウザとエミュレータでコンテナをホストします。 コストを削減するために、これらの仮想マシンはオンデマンドでのみ起動され、テストが実行されていないときは停止されます。 他にインフラを改善できるものはありますか? 答えは「はい」です！ Kubernetes (K8s) をご紹介します!

まず、オーケストレーション、クラスター、Kubernetes という言葉が互いにどのように関連しているかを見てみましょう。 大まかに言うと、オーケストレーションはアプリケーションをデプロイおよび管理するシステムです。 テスト自動化の場合、コンテナ化されたアプリケーションとしては、Selenium Grid や Selenoid があります。 Docker と K8 は相互に補完します。 8 つ目はアプリケーションのデプロイメントに使用され、8 つ目はオーケストレーションに使用されます。 つまり、KXNUMXs はクラスターです。 クラスターのタスクは、VM をノードとして使用することです。これにより、XNUMX つのサーバー (クラスター) 内にさまざまな機能、プログラム、サービスをインストールできるようになります。 いずれかのノードに障害が発生しても、他のノードが回復するため、アプリケーションの中断のない動作が保証されます。 これに加えて、KXNUMXs にはスケーリングに関連する重要な機能があり、これにより、負荷に基づいて最適な量のリソースが自動的に取得され、制限が設定されます。

実際のところ、Kubernetes を最初から手動でデプロイするのは決して簡単な作業ではありません。 有名なハウツー ガイド「Kubernetes The Hard Way」へのリンクを残しておきますので、興味があれば実践してみてください。 しかし、幸いなことに、代替の方法やツールがあります。 最も簡単な方法は、GCP で Google Kubernetes Engine (GKE) を使用することです。これにより、数回のクリックで既製のクラスターを取得できます。 内部コンポーネントを相互に統合する方法を学ぶのではなく、タスクで K8 を使用する方法を学ぶことに集中できるため、このアプローチを使用して学習を始めることをお勧めします。 

自動化インフラストラクチャの価値

K8s が提供するいくつかの重要な機能を見てみましょう。

• アプリケーションの展開: VM の代わりにマルチノード クラスターを使用します。
• 動的スケーリング: オンデマンドのみで使用されるリソースのコストを削減します。
• 自己修復: ポッドの自動回復 (その結果、コンテナーも復元されます)。
• ダウンタイムなしの更新のロールアウトと変更のロールバック: ツール、ブラウザ、エミュレータを更新しても、現在のユーザーの作業は中断されません。

しかし、K8s はまだ特効薬ではありません。 私たちが検討しているツール (Selenium グリッド、Selenoid) のコンテキストにおけるすべての利点と制限を理解するために、K8 の構造について簡単に説明します。 クラスターには、マスター ノードとワーカー ノードの XNUMX 種類のノードが含まれます。 マスター ノードは、管理、展開、およびスケジュールの決定を担当します。 ワーカー ノードはアプリケーションが起動される場所です。 ノードにはコンテナー ランタイム環境も含まれます。 私たちの場合、これはコンテナー関連の操作を担当する Docker です。 ただし、代替の解決策もあります。たとえば、 コンテナ。 スケーリングや自己修復はコンテナには直接適用されないことを理解することが重要です。 これは、コンテナーを含むポッドの数を追加または減らすことによって実装されます (通常はポッドごとに XNUMX つのコンテナーですが、タスクによってはさらに多くのコンテナーがある場合があります)。 高レベルの階層はワーカー ノードで構成され、その中にポッドがあり、その中でコンテナが発生します。

スケーリング機能は重要であり、クラスター ノード プール内のノードとノード内のポッドの両方に適用できます。 ノードとポッドの両方に適用される 2 種類のスケーリングがあります。 最初のタイプは水平方向です。スケーリングはノード/ポッドの数を増やすことによって行われます。 このタイプの方が好ましい。 したがって、XNUMX 番目のタイプは垂直型です。 スケーリングは、ノード/ポッドの数ではなく、サイズを増やすことによって実行されます。

次に、上記の用語に照らしてツールを見てみましょう。

セレングリッド

前述したように、Selenium グリッドは非常に人気のあるツールであり、コンテナ化されていることは驚くべきことではありません。 したがって、Selenium グリッドを K8 に導入できることは驚くべきことではありません。 これを行う方法の例は、公式 K8s リポジトリにあります。 いつものように、セクションの最後にリンクを貼り付けます。 さらに、ハウツー ガイドには、Terraform でこれを行う方法が示されています。 ブラウザー コンテナーを含むポッドの数をスケールする方法についても説明します。 しかし、K8s のコンテキストにおける自動スケーリング機能は、まだ完全に明らかなタスクではありません。 私が勉強を始めたとき、実践的な指導や推奨事項は見つかりませんでした。 DevOps チームのサポートを受けていくつかの調査と実験を行った後、4 つのワーカー ノード内にある XNUMX つのポッド内で必要なブラウザーを備えたコンテナを構築するアプローチを選択しました。 この方法では、ノードの数を増やすことでノードの水平スケーリング戦略を適用できます。 これが将来的に変わり、特に内部アーキテクチャが変更された Selenium Grid XNUMX のリリース後は、より良いアプローチや既成のソリューションに関する記述がますます増えることを願っています。

セレノイド:

K8s での Selenoid の導入は、現時点で最大の失望です。 互換性がありません。 理論的には、ポッド内で Selenoid コンテナを起動できますが、Selenoid がブラウザでコンテナの起動を開始すると、コンテナは依然として同じポッド内にあります。 これによりスケーリングが不可能になり、その結果、クラスター内の Selenoid の作業は仮想マシン内の作業と変わらなくなります。 物語の終わり。

月:

Selenoid を使用する際のこのボトルネックを認識した開発者は、Moon と呼ばれるより強力なツールをリリースしました。 このツールはもともと Kubernetes で動作するように設計されていたため、自動スケーリング機能は使用可能であり、使用する必要があります。 さらに言えば、現時点では、 シングル Selenium の世界のツールで、すぐにネイティブ K8s クラスターをサポートします (もう利用できません。次のツールを参照してください ）。 このサポートを提供する Moon の主な機能は次のとおりです。 

完全に無国籍。 Selenoid は、現在実行中のブラウザ セッションに関する情報をメモリに保存します。 何らかの理由でプロセスがクラッシュすると、実行中のセッションはすべて失われます。 対照的に、Moon には内部状態がなく、データセンター間で複製できます。 XNUMX つ以上のレプリカがダウンしても、ブラウザ セッションは存続します。

つまり、Moon は優れたソリューションですが、無料ではないという問題が 0 つあります。 料金はセッション数によって異なります。 無料で実行できるのは 4 ～ 5 セッションのみですが、特に便利ではありません。 ただし、500 回目のセッションからは、500 回あたり 5 ドルを支払う必要があります。 企業によって状況は異なるかもしれませんが、弊社の場合はMoonを使う意味がありません。 上で説明したように、オンデマンドで Selenium Grid を使用して VM を実行したり、クラスター内のノードの数を増やしたりできます。 約 2500 つのパイプラインについて、XNUMX 個のブラウザを起動し、テストの完了後にすべてのリソースを停止します。 Moon を使用した場合、テストを実行する頻度に関係なく、毎月 XNUMX x XNUMX = XNUMX ドルを追加で支払う必要があります。 繰り返しますが、私はMoonを使うなと言っているわけではありません。 これは、組織内に多くのプロジェクト/チームがあり、全員に巨大な共通クラスターが必要な場合など、タスクにとって不可欠なソリューションとなる可能性があります。 いつものように、最後にリンクを残し、タスクのコンテキストで必要な計算をすべて実行することをお勧めします。

カリスト：（注意！ これは元の記事にはなく、ロシア語翻訳にのみ含まれています)

先ほども述べたように、Selenium は非常に人気のあるツールであり、IT 分野は非常に急速に発展しています。 私が翻訳に取り組んでいる間に、Callisto と呼ばれる新しい有望なツールが Web 上に登場しました (こんにちは、Cypress やその他の Selenium キラーです)。 K8 でネイティブに動作し、ノード全体に分散されたポッド内で Selenoid コンテナを実行できます。 自動スケーリングを含め、すべてが箱から出してすぐに機能します。 素晴らしいですが、テストする必要があります。 私はすでにこのツールをデプロイし、いくつかの実験を実行することができました。 しかし、結論を出すのは時期尚早です。長距離で結果が出たら、将来の記事でレビューするかもしれません。 今のところ、独立した研究のためのリンクのみを残しておきます。  

インフラの現状イメージ

探索するためのリンク

• Kubernetes:セットアップ
• Kubernetes: 困難な道
• Kubernetes: セレン
• GCP: Kubernetes エンジン
• 月
• Kubernetes の本
• Kubernetes を使用した分散オートメーション
• Seleniumグリッド4
• カリスト GitHub
• Wrike TechClub (カリスト)

同様のツール

• Docker の群れ 
• マラソン 

7. コードとしてのインフラストラクチャ (IaC)

テクノロジーの簡単な説明

そしていよいよ最後のセクションです。 通常、このテクノロジーと関連タスクは自動化エンジニアの責任ではありません。 これには理由があります。 まず、多くの組織では、インフラストラクチャの問題は DevOps 部門の管理下にあり、開発チームは、何がパイプラインを機能させるのか、パイプラインに接続されているすべてのものをどのようにサポートする必要があるのか​​についてあまり気にしていません。 第 XNUMX に、正直に言うと、Infrastructure as Code (IaC) の実践はまだ多くの企業で採用されていません。 しかし、これは間違いなく人気のトレンドになっており、それに関連するプロセス、アプローチ、ツールに参加しようとすることが重要です。 または少なくとも最新の状態を維持してください。

このアプローチを使用する動機から始めましょう。 GitlabCI でテストを実行するには、少なくとも Gitlab Runner を実行するためのリソースが必要であることについてはすでに説明しました。 また、ブラウザ/エミュレータでコンテナを実行するには、VM またはクラスタを予約する必要があります。 リソースのテストに加えて、開発、ステージング、運用環境をサポートするための大量の容量が必要です。これには、データベース、自動スケジュール、ネットワーク構成、ロード バランサー、ユーザー権限などが含まれます。 重要な問題は、それをすべてサポートするために必要な労力です。 変更を加えて更新をロールアウトするには、いくつかの方法があります。 たとえば、GCP のコンテキストでは、ブラウザで UI コンソールを使用し、ボタンをクリックすることですべてのアクションを実行できます。 代わりに、API 呼び出しを使用してクラウド エンティティと対話するか、gcloud コマンド ライン ユーティリティを使用して必要な操作を実行することもできます。 しかし、非常に多くの異なるエンティティやインフラストラクチャ要素がある場合、すべての操作を手動で実行することは困難、または不可能になります。 さらに、これらの手動操作はすべて制御できません。 実行前にレビューのために送信したり、バージョン管理システムを使用したり、インシデントの原因となった変更を迅速にロールバックしたりすることはできません。 このような問題を解決するために、エンジニアは自動 bash/シェル スクリプトを作成および作成しましたが、手続き型スタイルですぐに読み、理解し、保守し、変更するのはそれほど簡単ではないため、以前の方法よりもそれほど優れているわけではありません。

この記事とハウツー ガイドでは、IaC の実践に関連する 2 つのツールを使用します。 それがTerraformとAnsibleです。 これらの機能は似ており、互換性があるため、同時に使用するのは意味がないと考える人もいます。 しかし実際には、最初はまったく異なるタスクが与えられます。 そして、これらのツールが相互に補完し合うべきであるという事実は、HashiCorp と RedHat を代表する開発者による共同プレゼンテーションで確認されました。 概念的な違いは、Terraform がサーバー自体を管理するためのプロビジョニング ツールであることです。 Ansible は構成管理ツールであり、そのタスクはこれらのサーバーにソフトウェアをインストール、構成、管理することです。

これらのツールのもう 10 つの重要な特徴は、コーディング スタイルです。 bash や Ansible とは異なり、Terraform は、実行の結果として達成される望ましい最終状態の記述に基づく宣言型スタイルを使用します。 たとえば、10 個の VM を作成し、Terraform を通じて変更を適用する場合、10 個の VM が得られます。 スクリプトを再度実行しても、すでに 10 個の VM があるため何も起こりません。Terraform はインフラストラクチャの現在の状態を状態ファイルに保存しているため、これを認識します。 ただし、Ansible は手続き型アプローチを使用しており、10 個の VM を作成するように要求すると、Terraform と同様に、最初の起動時に 20 個の VM を取得します。 ただし、再起動後はすでに XNUMX 個の VM が存在します。 これが重要な違いです。 手続き型スタイルでは、現在の状態を保存せず、実行する必要がある一連のステップを単に記述するだけです。 もちろん、リソースの存在と現在の状態についていくつかのチェックを追加して、さまざまな状況に対処することはできますが、このロジックの制御に時間を無駄にして労力を費やすことは意味がありません。 さらに、間違いを犯すリスクも高まります。 

上記をすべて要約すると、Terraform と宣言的表記法がサーバーのプロビジョニングに適したツールであると結論付けることができます。 ただし、構成管理の作業を Ansible に委任する方が良いでしょう。 それはさておき、自動化のコンテキストでユースケースを見てみましょう。

自動化インフラストラクチャの価値

ここで理解すべき唯一の重要なことは、テスト自動化インフラストラクチャは企業インフラストラクチャ全体の一部として考慮されるべきであるということです。 これは、すべての IaC プラクティスを組織全体のリソースにグローバルに適用する必要があることを意味します。 誰がこれに責任を持つかはプロセスによって異なります。 DevOps チームはこれらの問題に関してより経験が豊富で、何が起こっているかの全体像を把握しています。 ただし、QA エンジニアは自動化の構築プロセスとパイプラインの構造により深く関与するため、必要なすべての変更と改善の機会をよりよく理解できるようになります。 最善の選択肢は、期待される結果を達成するために協力し、知識やアイデアを交換することです。 

ここでは、テスト自動化と以前に説明したツールのコンテキストでの Terraform と Ansible の使用例をいくつか示します。

1. Terraform を使用して、VM とクラスターに必要な特性とパラメーターを記述します。

2. Ansible を使用して、テストに必要なツール (docker、Selenoid、Selenium Grid) をインストールし、ブラウザ/エミュレータの必要なバージョンをダウンロードします。

3. Terraform を使用して、GitLab Runner が起動される VM の特性を記述します。

4. Ansible を使用して GitLab Runner と必要な付属ツールをインストールし、設定と構成を設定します。

インフラの現状イメージ

探索するリンク:

• テラフォーム
• Ansible
• Ansible と Terraform を併用するとより効果的です
• Terraform の包括的なガイド
• Chef、Puppet、Ansible、SaltStack、CloudFormation ではなく Terraform を使用する理由
• GCP: IaC

同様のツール

• シェフ
• 人形
• 塩漬け
• 浮浪者

まとめてみましょう！

手順
テクノロジー
ツール
自動化インフラストラクチャの価値

1
ローカル実行
Node.js、Selenium、Appium

• Web およびモバイル用の最も人気のあるツール
• 多くの言語とプラットフォームをサポート (Node.js を含む)

2
バージョン管理システム 
Gitの

• 開発コードでも同様の利点があります

3
コンテナ化
Docker、Selenium グリッド、Selenoid (Web、Android)

• テストを並行して実行する
• 隔離された環境
• シンプルかつ柔軟なバージョンアップグレード
• 未使用のリソースを動的に停止する
• セットアップが簡単

4
CI/CD
Gitlab CI

• パイプラインの一部をテストします
• クイックフィードバック
• 会社/チーム全体の可視性

5
クラウドプラットフォーム
Google Cloud Platform

• オンデマンドのリソース (必要な場合にのみ料金を支払います)
• 管理と更新が簡単
• すべてのリソースの可視化と制御

6
編成
Kubernetes
ポッド内のブラウザ/エミュレータを備えたコンテナのコンテキストでは、次のようになります。

• スケーリング/オートスケーリング
• 自己修復
• 中断のない更新とロールバック

7
コードとしてのインフラストラクチャ (IaC)
Terraform、Ansible

• 開発インフラストラクチャでも同様のメリットが得られます
• コードのバージョン管理のすべての利点
• 変更とメンテナンスが簡単
• 完全自動化

マインド マップ図: インフラストラクチャの進化

ステップ1: ローカル

ステップ2: VCS

step3: コンテナ化 

ステップ4: CI/CD 

step5: クラウドプラットフォーム

step6:オーケストレーション

ステップ7:IaC

次は何ですか？

これでこの記事は終わりです。 しかし結論として、私はあなたといくつかの協定を結びたいと思います。

あなたの側から
冒頭で述べたように、この記事が実践に役立ち、得られた知識を実際の仕事に適用するのに役立つことを願っています。 もう一度追加します 実用的なガイドへのリンク.

しかしその後も、立ち止まらずに練習し、関連するリンクや書籍を研究し、社内でどのように機能するかを調べ、改善できる箇所を見つけて参加してください。 幸運を！

私の側から

タイトルからして、これはまだ最初の部分にすぎないことがわかります。 かなり大規模なものになったにもかかわらず、重要なトピックはまだここでは取り上げられていません。 XNUMX 番目のパートでは、IOS のコンテキストで自動化インフラストラクチャを検討する予定です。 iOS シミュレータを macOS システム上でのみ実行するという Apple の制限により、当社のソリューションの範囲は狭くなっています。 たとえば、Docker を使用してシミュレーターを実行したり、パブリック クラウドを使用して仮想マシンを実行したりすることはできません。 しかし、これは他の選択肢がないという意味ではありません。 高度なソリューションと最新のツールについて最新情報を提供できるよう努めます。

また、監視に関するかなり大きな話題については触れておりません。 パート 3 では、最も一般的なインフラストラクチャ監視ツールと、考慮すべきデータと指標について見ていきます。

そして最後に。 将来的には、テスト インフラストラクチャと一般的なツールの構築に関するビデオ コースをリリースする予定です。 現在、インターネット上には DevOps に関するかなりの数のコースや講義がありますが、すべての資料はテスト自動化ではなく、開発のコンテキストで提示されています。 この問題に関しては、そのようなコースがテスターや自動化エンジニアのコミュニティにとって興味深く価値があるかどうかについてのフィードバックが本当に必要です。 よろしくお願いします！

出所： habr.com