タグ付けされた質問 「testing」

中程度の複雑さを持つTerraform構成がある場合、継続的インテグレーション/継続的デリバリーパイプラインの一部として実行できる構成に関するテストをどのように作成しますか？ 例として、次の望ましい状態を指定するマルチクラウド構成がある場合があります。 AzureでDockerをホストするAzure Container Services Azure Blob Storage SQL Azure AWSでDockerをホストするEC2 Container Service Amazon S3ストレージサービス Amazon RDS SQL Serverデータベース terraform apply上記をゼロから作成したり、部分的に展開された状態から上記の望ましい状態に移行したりする可能性があります。 Terraformは、作業を実行計画段階と実際にターゲットアーキテクチャに変更を加えるアプリケーション段階に分割することを認識しています。これを使用して、実行計画に対するテストを作成できますか？もしそうであれば、これらを作成するのに役立つフレームワークはありますか？

37 testing  terraform 

プロビジョニングと構成を扱うAnsibleセットアップに回復力を組み込むことを検討しています。 私は物事の構成側でいくつかのテスト方法を理解していますが、物事のプロビジョニング側でテストを実装する最善の方法と、このタイプの実装に役立つツールがあるかどうか疑問に思っています。 現在、私たちのテストの多くは、プレイブック中に連続して行われます。これは、「サービスが出てきました。VIPが利用可能です。この非同期タスクが終了しました」などです。アプリケーション層とプロビジョニング層の両方での構成（VM構成など）。Ansibleは構成のドリフトを処理するための最良のツールではないことは承知していますが、あなた自身の意見を知りたいと思います。 プロセスをさらに完全に自動化するものがあれば。（毎日スラックで報告するいくつかのいスクリプトがあります）。 注：現在、再プロビジョニングが発生する可能性があるいくつかの条件（バックアップからの再構築、重要なシステムの問題など）がありますが、通常はいくつかのansible構成タスクをループし、それ以上は考えません。

33 testing  ansible  configuration  provisioning 

ターゲット環境を頻繁に更新する継続的統合プロセスを使用しているため、「変更」があるたびに「すぐに」変更をテストできます。それはCIの目標の一部ですよね？ ただし、管理者や顧客など、テストサイクルに関係する他の人もいると仮定します。他の人にあなたの今後の変更をレビュー（破壊？）させようとするのは理にかなっていますよね？ しかし、他の人々が真剣にテストしようとしている環境で継続的に変更を提供し続けると、次のような複数の問題が発生する可能性があります。 they 問題を報告するのに時間を浪費する可能性があり、（詳細な）レポートを保存するまでに、問題を自分で再現することさえできなくなります（たとえば、誤って同じ問題に遭遇し、環境で既に修正しているため）。 you 何らかの問題に遭遇した環境はもはや同一ではないため、彼らが報告した問題を再現できない可能性があります（あなた（!!!）が環境をオーバーレイした可能性があります）。 それで、あなたはそのような（イライラする）状況を避けるために何をすることができますか（物事を構成する方法？）

19 continuous-integration  testing 

私はAnsibleが初めてです。これが私の仕事です... 400以上のホストがあり、5つの異なるポートがエンドからWebサーバーに開いているかどうかを確認する必要があります。 個別に、ログインして実行できました。 telnet mywebserver.com 443 telnet mywebserver.com 80 telnet mywebserver.com 8443 ..等々.. どのモジュールまたはプラグインをAnsibleで使用できるので、これを自動化し、結果（開いているポートまたは閉じているポート）をAnsibleサーバーに報告させることができますか？

15 ansible  testing  ports 

統合テスト中に、実際にRESTful API（または一般的なHTTPインターフェイス）を使用して繰り返し使用するケースに取り組んでいることに気付きました。bash+ cURLで確認します。 それはかなり乱雑に見え始め、維持するのが難しくなります。なぜ混乱をもたらすのですか？ 典型的な使用例は次のとおりです。 URLがhttp応答コードを返すことを確認してください（例：200） その場合、コンテンツタイプが必要なMIMEと一致することを確認します 返されたコンテンツが何らかのパターンに一致することを確認するか、抽象的な検証手順に合格する 私がこれまでに見つけたのは、車輪を再発明することなく実行可能なオプションを検討することです。 PyCurlを試してください-すべてのcURLオプションを完全に実装することを期待してください。プロキシだけでなく、私が必要とするかもしれない他のスイッチ Pythonの組み込みユニットテストを使用する 次に、たとえば、チェックするサービスごとに1つのユニットテストを実行できます。 import unittest, pycurl class TestService (unittest.TestCase): def test_1(self): self.assertEqual(pycurl.returncode("some_url"), 200) def test_2(self): self.assertTrue(pycurl.response("some_url").matches ("xxx") ) def test_3(self): self.assertTrue (pycurl.ContentType("some_url").equal("xxx")) if __name__ == '__main__': unittest.main() これは理にかなっていますか、またはより高度な（しかし、複雑すぎずに取り上げて統合できない）ツールがありますか？

14 testing  continuous-deployment  python  curl 

コードとしてのインフラストラクチャは、ビルドを自動化するツールを使用するように指示します。すごい。ansible、chef、puppet、salt stackなどのツールは、違いを解決しながら、インフラストラクチャがどのように見えるかを書くように私たちを促しています。 ソルトスタックでは、これらのビットは状態と呼ばれます。状態が現実と一致しない場合、ツールはそれを解決します。つまり、インフラストラクチャのテストを作成しており、テストが失敗した場合は、ツールが独自に修正します。少なくともそれは考えです。 XPはTDDの使用を教えてくれますが、問題はそれがインフラストラクチャに適用可能かどうかです。ツールはそれを示唆しています。 非常に役立つテストの種類はほとんど想像できません。 デプロイされたサービスにバンドルされているスモークテストを記述して、デプロイされたサービスが期待どおりに機能し、実行されることを確認します。これは、API呼び出しまたは/およびsystemctlチェックで、デプロイしたばかりのものが機能することを確認します。ansibleのようなツールには、サービスが実行されていることを確認するための状態があるため、この機能の多くは同じ状態でカバーできます。 dockerまたは別の一時的な仮想化エンジンに対して（ansibleがその状態を呼び出すときに）個々のロールを実行できるプロジェクトMoleculeがあります。これにより、役割の分離が強制され、作業中にプレイブックから分離して実行することができます。テストでは、ほとんどの場合、ロールが機能するはずの変数をモックできます。他の例は、ansibleエンジンの複製のように見えます（ファイルがユーザーに属していることをアサートします...）。 ThoughtWorksのハイテクレーダーは、今のようなツール賞賛INSPEC、serverspecやゴスをサーバーが仕様を満たしていることを検証するため。しかし、私たちはスペックを書いていますね？ インフラストラクチャを州/役割で説明している場合、インフラストラクチャをさらにテストすることに意味がありますか？これは、1つのチームが仕様を提供し、他のチームが従う大規模な組織でより必要になるか、または役割の大きなセットがある場合、それらのサブセットを実行してテストから速度のメリットを得たいと思うかもしれません。同じ質問に対する役割/状態が考えられるのに、なぜテストを書くのかを理解するのに苦労しています。

11 deployment  testing  infrastructure-as-code  serverspec  tdd 

現在、私はテストにお金と多くの時間がかかるという状態にあります... 背景：SoftlayerでVMを展開し、VMの準備ができた後に必要なすべてのソフトウェアをインストールする展開後スクリプト（bash）を使用しています。問題は、このスクリプトをテストできるのは、1つのVMをデプロイすることだけです。現在、スクリプトが完了するまでに約4時間かかります...そのため、変更を加えるたびに、新しいVMを作成し（費用がかかる）、待機する必要があります。スクリプトが壊れているかどうかを確認するための4時間...これは混乱しており、このままでは、先に進むことができなくなります。 このような状況にアプローチし、毎回新しいVMを展開する必要なく、より迅速にプロビジョニングスクリプトをテストできる新しい方法が必要です。 このシナリオで私を助けるためのツールを知っていますか？

10 testing  provisioning  virtualization 

現在、ビルド、テスト、デプロイ、その他の自動化されたアクティビティのためのJenkinsジョブとパイプラインがかなりあります。 新しいジョブを変更または追加するたびに、手動でのみテストします。たとえば、「ハッピーパス」を通過し（ジョブがエラーなしで完了した場合）、ジョブまたはパイプラインが失敗したときにいくつかの否定的なテストケースをテストします。エラーコードと通知。 このアプローチは明らかに信頼性が低く、適切に拡張できません。このプロセスをどのように改善できますか？Jenkinsのジョブとパイプラインがどのように機能するかを確認する場合、テストを自動化する場所はありますか？

10 jenkins  testing  automation 

「統合によって引き起こされるテスト環境での不安定性を継続的に回避するにはどうすればよいですか？」に関する質問への回答の一部を以下に示します。 通常、この環境はテスト中にフリーズします。 私の質問：凍結環境のサンプル実装は何ですか？つまり、誰もが（リリースマネージャーのような承認されたユーザーによって許可されている場合を除いて）そのようなフリーズされた環境では何も変更できないように技術的に強制するために何ができますか。 明確化： 銀行での年末処理中（例）の「凍結期間」とは何ですか（私が思う）について話しているのではありません。それは、年末の処理に影響を与える可能性のある新しい変更/修正が導入されるリスクを軽減するために、実稼働環境に変更を適用することを許可しないことです。 変更の承認/適用を許可されているユーザー（私の例のリリースマネージャーなど）は、例外的な場合にのみ変更を行うと想定します。テスト中に重大度の高い問題が発生した場合など、修正を次のリリースに延期することはオプションではありません（そのような修正なしでリリースがアクティブ化されると、本番稼働が危険になるため）。 これは、テスト中に自動更新を一時停止することに関するだけの可能性があります。重要なのは、別のチームがまだアプリケーションAに依存するバージョンXでアプリケーションBをテストしている間に、誰かがアプリケーションAをバージョンYにアップグレードしないようにすることです。テスト。

8 configuration  testing 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、 DevOps Stack Exchangeのトピックとなるようにします。 3年前休業。 「ブラックボックス」テストとは何ですか？それは通常のテストとどのように異なりますか？たとえば、本番環境にデプロイする前のブラックボックステスト。 注：「ブラックボックス」テストは、devopsロールを申請する場合の一般的な要件です（テスターの必要はありません）。

8 testing  terminology 

開発とテストのための新しいステージングプロセスを作成する必要があります。 常に、活発に開発およびテストされているgitブランチは約4つだけです。各gitブランチ内には、実行する必要のあるデータベースエボリューションスクリプト（ストレートSQL）と、より重い処理のためのバックエンドからのエボリューションスクリプトがあります（これらは、データベースを実行する管理者資格情報を使用してアプリ内で呼び出す必要があるHTTPルートです）移行や、前述のプレーンなSQL進化スクリプトでスクリプトを作成することが困難または不可能であるその他の変更）。 私たちのライブDBは、適度なサイズの4.2 GBです。セットアップの準備ができて、使い捨ての真新しいDell PowerEdgeサーバーがあります。 次の質問についてのアドバイスと、経験豊富なDevOpsがこれにどのように取り組むかを知りたいです。 ステージングサーバーでいくつかの異なるブランチを実行するにはどうすればよいですか？これらのブランチは、QAに合格し、マスターにマージされて解放されると、頻繁にポップアップして消えます。 各ブランチに常に適切なDBがあることを確認するために、DB進化システムをどのようにセットアップしますか？各ブランチは、マージされるまで相互に互換性があるとは限らないさまざまな方法でDBに変更を加える場合があります。 これらのブランチを最新の状態に保つにはどうすればよいですか？各ブランチでコミットを自動プルする方法はありますか？ これをすべて設定する方法について少し迷っていますので、これ以上の入力は大好きです。現在のワークフローは関係者全員にとって困難です。開発者は完全に分離されたアプリのローカルコピーをローカルで実行しており、QAは3〜4台のラップトップをローテーションしてステージング「サーバー」として機能させます

8 git  testing  builds  branch  mysql 

dockerfileはアプリケーション環境を作成します（例：env変数、apt-getを使用したライブラリーのインストールなど）。また、そのgitリポジトリからPythonアプリケーションコードをプルしてコピーします。 ただし、ビルドされたコンテナーでテストを実行するために、アプリケーションテスト（一部のユニット、一部の統合）をdocker RUNコマンド（例RUN /bin/bash -c "source activate cool_env; pytest"：）内に配置するか、CIスタック（例：Jenkins、Openshift）を使用してビルド後に配置するかについては、議論しています。 それぞれの長所と短所は何ですか？

7 jenkins  docker  testing  python 

新しいパラダイムが「あなたが構築し、実行する」（Werner Voegels、Amazon CTO）である場合、明らかにソフトウェアエンジニアにはるかに大きな責任とプレッシャーを課します。この変更は、テストチームのタスクに何をもたらしますか？

7 culture  testing 

Server Specを調べたところ、次のようにはっきりとわかりました。 備考：serverspecテストスイートは、単一のマシン（またはDockerコンテナー）に対して実行するためのものです。言い換えると、複数のマシンまたはコンテナに対してテストをハーベストして実行する単一のrspecコマンドを発行しないでください。それらのそれぞれに対して1つのrspecコマンドを発行する必要があります。 したがって、サーバーごとにテストを行うことができます。しかし、問題は次のとおりです。私のマイクロサービスアーキテクチャには自動検出サービスがあるため、クエリを実行すると一部のサービスが認識されます。これを表現するプロジェクトはありますか？ruby（またはtestinfraなどを選択した場合はpython）でツールを使用できることを知っています Consulとserverspecまたは類似のものと統合する何かが素晴らしいでしょう、2014年に人々はこれを探していましたが、誰かがこの問題に取り組んだプロジェクトを知っていますか？

7 testing  microservices