複数のGitリポジトリーの共有CD（継続的デプロイメント）
短い話
複数のGitリポジトリ（フロントエンドとバックエンド）の共有CDを設計する最良の方法は何ですか？
私のCDに最適なデザインを見つけるのに苦労しています。
全体像（詳細は変更可能です）
- フロントエンド-Angular 2（Javascript）、アーティファクトなし。
- プロジェクトに含まれるフロントエンドは1つだけです。
- バックエンド-ASP.NET（C＃）、アーティファクトなし。
- プロジェクトにはバックエンドが1つだけ存在します。
- それぞれのGit TFS上のGitリポジトリ。
- Jenkinsのサーバー。
- 両方のリポジトリからブランチ
Dgroupの最新バージョンをデプロイするための複数のマシンdevelopment-各開発者の遊び場。
私の目標：
developmentブランチはプルリクエストで保護する必要があり、ビルドに合格する必要があります。詳細：Jenkinsは、プルリクエストをアクティブ化したブランチの最後のバージョンがコンパイルされ、リポジトリのテストに合格したことを確認する必要があります。また、他のリポジトリとの統合テストは失敗しません（フロントエンドのテスト）。 Jenkinsは、すべてのリポジトリのプルリクエストごとに、両方のリポジトリのビルドを「統合」する必要があります。各リポジトリのすべてのテストに合格すると、プルリクエストを承認する準備が整います。それ以外の場合、プルリクエストは拒否されます。承認されたプルリクエストごとに、
Dgroupmachinesを更新して、製品の最新バージョン（サービス+フロントエンドファイル）を含める必要があります。
欠陥：
複数の理由から最初の目標を達成する方法が見つかりません。
フロントエンドは、バックエンドが同じ機能を彼の側から完了するまで、最初から新しい機能をプッシュできません。そうしないと、一部のフロントエンドのテストに合格しません。フロントエンドのワークフローにどのように影響するか、そしてそれがベストプラクティスかどうかはわかりません。
両方のリポジトリの
developmentブランチが壊れているが、バグを見つける正しいテストをno1がまだ書いていない状況を想像してください（今のところ、ビルドパス）。フロントエンドは、バックエンドのバグを見つけるテストを含むプルリクエストを作成します。そのため、ビルドはパスせず、自動的にプルリクエストが拒否されます。
バックエンドで問題を修正し、プルリクエストを試行します。現在、彼の変更もフロントエンドのテストに失敗しています。そのため、彼のプルリクエストも拒否されました。その結果、誰もプルリクエストを実行できなくなりました。
欠陥のために説明しなかった私のCDデザインは、私が先に進むのを妨げます。複数のGitリポジトリ用のCDを設計するためのベストプラクティスは何ですか？
私の問題の根本的な原因は、システム全体（フロントエンド+バックエンド）を管理しようとする一方で、適切なツールサポートなしに、各部分を個別に移動できるようにすることです。
より良い（IMHO）アプローチは、システムを考慮してCI/CDアプローチを設計することです。システムのいずれかの部分（またはそれらの組み合わせ）を変更した場合は、常にシステム全体をテストする必要があります。このようにして、システム全体の整合性に常に焦点を当てることを確実にします。私は知っています、これはマイクロサービスの傾向に逆行します（私はあまり好きではありません。理由の1つは、まさにこの種の問題の余地があるためです）が、基本的に私が必要とするIMHOです。
Jenkinsが含まれている従来のCIツールは、このようなアプローチのために実際に設計されていないことが複雑です。あなたはそれを微調整しようとすることができますが、それは簡単な仕事ではないと思います。
もう1つの問題は、絶対検証vs回帰（または、必要に応じてデルタ）検証と呼ばれるものです。たとえば、バックエンド部分が行われていないために検証がテストに失敗した場合、フロントエンドへの変更を拒否すべきではありません。前に通過しないので、それは回帰ではありません。フロントエンドとバックエンドの両方の機能が完了し、テストが少なくとも1回は成功した場合にのみ、テストが失敗し、コミットがブロックされます。 Jenkinsがそのような機能をサポートしている場合、Donno。
あなたmightを見てみたい ApartCI は、そのようなシステム指向の開発を念頭に置いて設計されました。免責事項：私はそれを設計し、私はそれを提供する会社の創設者です。