私たちは、Rails APIに裏打ちされたAngularアプリを持っています。 AngularコードとRailsコードは別々のreposにあります。フィーチャブランチを使用して新しいフィーチャを作成すると、たとえば、統合テストのためにAPIとフロントエンドの間のブランチ依存関係を指定する方法は？
angular/foobar
rails/foobar
に応じて、どのように我々は、統合テストを実行するときangular/foobarがrails/foobarに依存することトラヴィスを伝えることができますか？
さらに広く、フロントエンドとAPIリポジトリ間で統合テストを実行する方が良いでしょうか？これは解決しなければならない問題ですが、そこには何も見つかりませんでしたが、それは非常に役立ちます。
複数のリポジトリにまたがるAPI/UIの開発は解決された問題ではなく、すべての知恵が歓迎されています。
私がお勧めするのは、API masterブランチ（またはあなたのベースブランチとみなすブランチ）に対して常にUI側で開発することです。
この背後にある考え方は、これらの変更に応じて新しいUI機能を実装する前に、APIの変更を最初に行う必要があることです。 APIの変更が実際のUIバージョン（UI masterまたはベースブランチ）を破らないようにしてください。
現時点では、実際のUIクライアントは新しいAPIの変更でも機能します。今、UIで作業を開始しましょう。
このワークフローは、デプロイメントプロセスにも役立ちます。最初にAPIをデプロイできるようになり、ユーザーにアプリのアップグレードを依頼できるようになります。
簡潔にするために私の答えを単純にしていましたが、これが役立つことを願っています。
あなたのアプローチはうまくいきますが、バックエンドとフロントエンド（通常はやりたいことです）で*並列に*動作する可能性を考慮していません。その場合、フロントエンド部分はバックエンドブランチでしかテストできません。 –
私の答えは、統合テストの問題に取り組んでいました。並列開発では、採用するワークフローは実装している実際の機能に大きく依存します。しかし、その日の終わりに、APIをマスタで最初にマージし、すべてのUIの変更をこのマスタブランチに対してテストする必要があります。しかし、やはり、柔軟性に優れ、静的なワークフローを持つよりも、求められる機能に合わせたワークフローを持つことが重要です。 –
ありがとう@ÉricCôté。 APIブランチがテストするようにdevに頼むUIリポジトリにgit push hookを追加しました。その後、テストを実行するためにTravisの仕事を開始します。これは短期的な解決策ですが、現在、私たちの利益のために最高の方法です。 – kareem
もう一方のサブモジュールを作成できますか？そうすることで、特定のコミットを選択することができます。 – jonrsharpe