可視化コンポーネントとは別のリポジトリにあるスクレイパー？
私が取り組んでいるプロジェクトのアーキテクチャについての私の考えを説明させてください。プロジェクトコードリポジトリは、次のもので構成されています。
- Scrapyコンポーネント-もちろん、データをスクレイピングし、処理して、データ間の関係を計算します。 MySQLデータベースにデータを入力します。
- Django視覚化コンポーネント-多くのフィルターを使用してデータベースに保存されたデータを表示するだけです。
現在、これらは2つの別個のDockerコンテナーとしてデプロイされており、正常に機能します。以前の同僚のアイデアは、スプリットとスプリットコードリポジトリをさらに進めることでした。
リポジトリごとにCI/CDを作成する潜在的な能力があるので、テスト/ lintes /チェックのみを実行し、最終的には実際に変更されたコンテナーのみをデプロイします。 ok（論理的分離）である他のコンテナのすべてを実行するわけではありません。
しかし、彼らは実際に同じデータベーステーブルで作業しているため（Scrapyがデータを入力し、Djangoがそれらを読み取る）、私にはやり過ぎのように見えます。両方のリポジトリで2つの別個のDBモデル仕様を同期して維持する必要があります現在、ScrapyはDBとの対話にDjango ORMを使用しています。
どう思いますか？コードリポジトリを2つの別々のリポジトリに分割して、両方で同期モデルを維持する価値があると思いますか？またはそうでないかもしれません？単一のリポジトリー内の影響を受けるコンテナーのみに対してGitlab CI/CDプロセスをトリガー/実行する方法はありますか？
ありがとうございました
データベースモデルを複製してリポジトリを2つに分割すると、問題が発生するだけです。時間の経過とともに、いずれかのリポジトリでいくつかの変更を行うか、別の方法で変更を加えることを忘れます。最後に、データベース内の同じテーブル構造にマップされる場合とされない場合のある2つの完全に異なるモデルがあります。
リポジトリを分割する場合は、共通コード（少なくともデータベースモデルを含む）用の1つのリポジトリを使用して、少なくとも3つのリポジトリにします。
リポジトリーを分割すると、スクレーパーとダッシュボードのパーツ用に別々のCI/CDパイプラインを実行するのが容易になる場合がありますが、独自の複雑な問題も発生します。
現在、スクレーパーのバージョン10とダッシュボードのバージョン14がデプロイされている場合、データベースの更新のため、両方をバージョン15に更新する必要があることを知っています。スクレーパーとダッシュボードに別々のリポジトリーがある場合、それらのバージョン番号もばらばらになり、どのバージョンのコンポーネントが同じデータベース・バージョンを使用するかを文書化するために管理が少し増えるため、一緒に作業できます。
最後に、別々のCI/CDパイプラインの利点と、より複雑なリポジトリセットアップの欠点と、どのバージョンが相互に互換性があるかという管理の欠点を比較検討する必要があります。その大きな要因は、おそらくデータベースが変更される頻度でしょう。