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

現在の製品で増加している統合テストの規模を拡大するための技術と戦略を調査しており、開発およびCIプロセスの一部として（人間的に）残ることができます。 約200以上の統合テストで、（デスクトップ開発マシン上で）完全なテスト実行を完了するために1時間のマークをすでに打っています。これは、定期的なプッシュプロセスの一部としてスイート全体を実行することを許容する開発者の能力に悪影響を及ぼしています。それは、それらをうまく作成することについて規律付けられる動機に影響しています。主要なシナリオのみを前面から背面まで統合テストし、テストを実行するたびにゼロから構築される本番環境をミラーリングする環境を使用します。 実行に時間がかかるため、テスト実行の集中度に関係なく、ひどいフィードバックループが発生し、テスト実行の終了をマシンで待機する多くの無駄なサイクルが発生します。フローと進捗、健全性、持続可能性に対するより高価な悪影響を決して気にしないでください。 この製品の速度が低下し始める前に、10倍以上の統合テストが行​​われると予想されます（実際にはわかりませんが、機能に関してはまだ始まったばかりではありません）。私たちは、数百または数千の統合テストに合理的に期待する必要があります。 明確に言うと、これがユニットテストと統合テストの議論にならないようにしようとすることです。この製品では、TDDを使用した単体テストと統合テストの両方を行っています。実際、アーキテクチャのパターンを他の領域に変更する際に重大な変更を導入する場所を検証する必要があるため、私たちが理にかなっているサービスアーキテクチャのさまざまな層で統合テストを行いますシステム。 技術スタックについて少し。現在、テストをエンドツーエンドで実行するために、（CPUとメモリを集中的に使用する）エミュレーション環境でテストしています。これは、noSqlバックエンド（ATS）の前にあるAzure REST Webサービスで構成されています。Azureデスクトップエミュレーター+ IISExpressで実行することにより、運用環境をシミュレートしています。開発マシンごとに1つのエミュレータと1つのローカルバックエンドリポジトリに制限されています。 また、同じエミュレート環境で同じテストを実行するクラウドベースのCIもあり、現在のCIプロバイダーではクラウドでのテスト実行に2倍の時間がかかります（2時間以上）。ハードウェアパフォーマンスの観点からクラウドCIプロバイダーSLAの制限に達し、テスト実行時の許容値を超えました。公平を期すために、仕様は悪くはありませんが、社内の汚いデスクトップマシンの半分の品質であることは明らかです。 テストの論理グループごとにデータストアを再構築し、テストデータをプリロードするテスト戦略を使用しています。データの整合性を包括的に保証しながら、これにより各テストに5〜15％の影響が追加されます。したがって、製品開発のこの時点では、そのテスト戦略を最適化することはほとんど得られないと考えています。 長いことと短いことです。各テストのスループットを最適化できましたが（それぞれ30％〜50％であっても）、数百のテストで近い将来に効果的にスケーリングすることはありません。1時間は今でも人間の許容範囲をはるかに超えています。それを維持するには、全体のプロセスを1桁改善する必要があります。 そのため、テスト時間を大幅に短縮するために使用できる手法と戦略を調査しています。 より少ないテストを書くことはオプションではありません。このスレッドで議論しないでください。 非常に高価ですが、より高速なハードウェアを使用することは間違いなくオプションです。 並列の別個のハードウェアでテスト/シナリオのグループを実行することも、間違いなく推奨されるオプションです。 開発中の機能とシナリオに関するテストのグループ化を作成することはもっともらしいですが、最終的には、システムが変更の影響を受けないという完全なカバレッジまたは信頼性を証明することはできません。 デスクトップエミュレーターで実行する代わりに、クラウドスケールのステージング環境で実行することは技術的に可能ですが、テスト実行に展開時間を追加し始めます（テスト実行の開始時に、〜20分ごとに展開します）。 システムのコンポーネントを独立した対数部分に分割することはある程度妥当ですが、コンポーネント間の相互作用は時間とともに増加することが予想されるため、その上で限られた燃費が期待されます。（つまり、変更は他の人に予期しない形で影響を与える可能性が高い-システムがインクリメンタルに開発されるときによく起こるように） この分野で他の人がどの戦略（およびツール）を使用しているかを知りたかった。 （他の人が特定の技術セットを使用してこの種の困難に直面している可能性があると信じる必要があります。） [更新：2016年12月16日：結果の議論のため、CI並列テストにより多くの投資をすることになりました：http : //www.mindkin.co.nz/blog/2015/12/16/16-jobs]

21 testing  continuous-integration  integration 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 5年前に閉鎖されました。 私が働いている会社は、Webサービスのガバナンス、計測、およびセキュリティのためのミドルウェアソリューションを評価しています。現在、この目的のためにEnterprise Service Bus（ESB）を使用していますが、経営陣の中には、API管理ミドルウェアをデプロイすることに決めた人もいます。 これらのAPI Management（別名API Gateway）ソリューションについて少し調査しましたが、それらと実際のESBの違いを見つけることができませんでした。Mule、WSO2、Oracleなどのホワイトペーパーを評価しましたが、両方の製品で提供される機能はほとんど同じようです。問題は、ESBができないAPI管理ができること、およびその逆です。API GatewayのESBを置き換えることにより、ITインフラストラクチャにどのような価値を追加できますか？

20 integration  middleware 

私はSOまたはここでいくつかの答えを探していましたが、結果なしで、あなたに尋ねる理由です。 アプリのサーバー部分とクライアント部分など、2つの異なるプロジェクトがあると仮定しましょう。私は自分のパートを開発していますが、友人は2番目のパートを作成しています。しかし、私たちの両方のようないくつかの共通のインターフェイスを使用する必要があるUserか、AccountInfoまたはChangableAccount順番に互換性を確保するために何でも...。たとえば、クライアントがユーザーデータをサーバーに送信する場合、サーバーは同じクラスで動作する必要があります。インターフェイスなどでも同じです。さらに、共通のインターフェイスに変更がある場合は、両方のプロジェクトでコードを新しい状況に合わせて調整する必要があります。 私が今見ることができる唯一の解決策は、すべての一般的なものが定義されている1つの余分なプロジェクトを作成することです。私たちと私の友人は、このプロジェクトをメインプロジェクト（クライアントまたはサーバー）への依存関係として追加する必要があります。共有プロジェクトは何らかのバージョン管理システムで管理できるため、常に最新の状態になります。 他にどのような解決策を提案しますか？このような問題はプロのアプリでどのように解決されますか？

17 java  dependencies  integration  dependency-management 

最近、私はHohpeとWoolfのEnterprise Integration Patterns、Thomas ErlのSOAに関する本を読んでおり、Udi Dahanらによるさまざまなビデオやポッドキャストを見てきました。CQRSおよびイベント駆動型システム。 私の職場のシステムは、高い結合に悩まされています。各システムには理論的に独自のデータベースがありますが、それらの間には多くの結合があります。実際には、これは、すべてのシステムが使用する1つの巨大なデータベースがあることを意味します。たとえば、顧客データのテーブルが1つあります。 私が読んだことの多くは、各システムがデータベースのみを使用し、メッセージングを使用して他のすべてのシステムに更新が伝播されるように、データの非正規化を示唆しているようです。 これはSOAの境界を強化する方法の1つだと思いました-各サービスには独自のデータベースが必要ですが、それを読んでみました： /programming/4019902/soa-joining-data-across-multiple-services そして、これは行うのが間違っていることを示唆しています。 データベースを分離することは、システムを分離する良い方法のように見えますが、今は少し混乱しています。これは良いルートですか？SOAサービス、DDDバウンドコンテキスト、アプリケーションなどでデータベースを分離することをお勧めしますか？

17 soa  integration  cqrs  eai  domain-driven-design 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 ソフトウェアチームに1-2人の新しいエンジニアを雇おうとしています（3人の開発者、1人のテスターで構成されています）。 それらをチームに統合する手順は何ですか？ 私のアイデアは次のとおりです。 ドキュメントを読む（コーディング標準、使用する開発方法論のドキュメント） 既存のコードを読ませる それらにいくつかの簡単なタスクを割り当てます 最後に、コード部分の責任を負わせる 他に何ができますか？ このプロジェクトは医療分野（超音波システム）であり、すでに5年が経過しています。1年に1回のリリースがあり、1〜2人のエンジニアを追加するときに1つのリリースを終了します。 プロジェクトはメンテナンス段階にあります（レガシーコードのリファクタリング、および新しい機能の追加）。物事はほぼスケジュールどおりです（多少なりとも）。

12 team  integration 

新しい機能とバグ修正のテストを担当する人（Tedと呼ぶことにします）がいます。 GitとGitHubを使用しています。master常に展開可能である必要developmentがあり、新しい機能やバグ修正をコミット/マージする場所ですが、Tedによってテストされた後でなければなりません。 プロジェクトはPHPにあります。 テストプロセスは次のようにします。 開発者は新機能（課題追跡に記載されているTedとしての機能/バグ＃123としましょう）に取り組みたいので、ローカルリポジトリにプルorigin/developmentし、そこからdevelopment新しいブランチ（としましょうissue-123）を作成します。 作業に満足したら、新しいブランチをコミットしてにプッシュしoriginます。 Tedは接続しtest.ourproject.com/choose-branchてブランチのリストを確認し、originスイッチをオンにしますissue-123（Webページから実行できます）。その後、彼はに進みtest.ourproject.com、Webアプリケーションの地獄をテストし（彼は本当に無慈悲です）、開発者と何度かやり取りした後、彼は機能に満足しています。 テッドは、彼がマージすることができ、開発者告げるissue-123上にdevelopment上をorigin。 すすぎ、繰り返します。 3番目のステップでは、その仕事（特定のページからの分岐の表示と切り替え）をハッキングすることができますが、ここで説明したことは非常に一般的なパターンだと感じています。 だから私の質問は： これは分岐のための良い/持続可能な/保守可能なワークフローですか？このワークフローに従う他のプロジェクトの例をいくつか挙げて、回答を裏付けることができますか？

11 testing  git  integration 

膨大な数の警告を生成するC ++プロジェクトに取り組んでいます。ほとんどの警告は、コードの作成後に表示されました。 当初、プロジェクトはVisual C ++ 8を使用し、間もなく9に切り替えましたが、生成された警告にほとんど違いがありません。警告は修正されるか沈黙されたので、そのとき警告はありませんでした。 次に、64ビットターゲットが追加されました。これは、主に型の不適切な使用（unsignedvsなどsize_t）のために、大量の警告を生成しました。コードが目的に沿って機能した後は、誰もそれらを修正するために悩んだり時間をかけたりすることはありませんでした。 次に、GCCを使用する他のプラットフォームのサポート（4.5および4.6、最初は4.4）が追加されました。GCCはよりうるさいので、より多くの警告を生成しました。再び、誰もそれらを修正するために悩んだり、時間をかけたりしませんでした。これは、GCCが4.5まで特定のコードの警告を沈黙させるプラグマを持っていなかったという事実によってさらに複雑になり、ドキュメントによると、それはまだ必要なものではありません。 その間、いくつかの非推奨の警告がポップアップしました。 これで、何千もの警告を生成するプロジェクトができました。また.cpp、さまざまなコンパイラーによってファイルが数回コンパイルされ、ヘッダーの警告が何度も出力されるため、どのくらいの数の場所であるかさえわかりません。 そのようなものをクリーンアップするためのベストプラクティスはありますか？それともそれを扱った少なくともいくつかの肯定的な経験ですか？

9 legacy  integration  warnings