Ist Git Submodules hier die richtige Passform? ⇐ Python

[Anonymous]

Ich bin ein ML -Ingenieur mit 5 Jahren Erfahrung. Der Haupt -ML -Code befindet sich im Kernpython -Paket. Jedes Land hat ein eigenes Paket, das derzeit mit dem Ländercode als Suffix wie ML_BR für Brasilien geschrieben wurde. Ich verwende DVC, um unsere Daten und Modellartefakte zu steuern. Die DVC -Pipelines (obwohl gleich) für jedes Land getrennt geschrieben. Insbesondere alle PRs im Zusammenhang mit DVC -Updates für jedes Land. Die Stakeholder sind jedoch kein Fan von damals, da sie mehr Kontrolle über jedes Land benötigen. Also, ein Monorepo ist es! Ich habe viel gelesen, aber es ist schwer zu entscheiden, was der richtige Ansatz ist. Ich lehne mich derzeit zu Git-Submodulen über Git-Subtrees.core-ml/                     ← main repo, owned & managed entirely by ML team
├── .github/workflows/            ← GitHub Actions workflows for CI/CD
├── .dvc/                         ← overall DVC configuration
├── cml/                          ← common training scripts
├── core/                         ← shared model code & interfaces
├── markets/      
│   ├── us/                       ← Git submodule → contains only code and data
|   |   ├── .github/workflows/    ← Workflows for the given country. deals with unit tests. Non editable.
│   │   ├── .dvc/                 ← country level dvc config with its own remote. config.local will point to parent .dvc/cache
│   │   ├── cml/                  ← country specific dvc model artifacts with their own remote.
|   |   |   ├── train/dvc.yaml    ← non editable. uses ../../../../../cml/model_train_handler.py
|   |   |   ├── wfo/dvc.yaml      ← non editable.uses ../../../../../cml/run_wfo.py
│   │   ├── data/  
|   |   |   ├── dvc.yaml          ← non editable.
│   │   ├── ml_us/*.py            ← country specific tests and ml/dataprocessing modules.
│   │   └── tests/                ← country specific e2e tests    
│   └── country2/...    
├── tests/                        ← all e2e tests scaled for other countries as well.
< /code>
Wie Sie von oben sehen können, ist jedes Land sein eigenes Git -Submodul. Die Tests, Haupt -ML -Code, GitHub -Workflows, werden alle im Hauptrepo sein! Jedes Submodul konzentriert sich hauptsächlich auf den Datenverarbeitungscode und die DVC -Artefakte für das jeweilige Land. Es gibt nie einen Fall, in dem ein Land eine Abhängigkeit von einem anderen hat. In diesem Ansatz gibt es eine Code -Duplikation, aber die Datenverarbeitung ist für jeden in der Regel der gleiche und es ist wenig Vorteil, sie zu verallgemeinern. Auf diese Weise müssen PRS nur mit DVC -Updates oder Änderungen der Datenverarbeitung in Bezug auf die Code -Besitzer von Core Repo überprüft werden. Viele dieser Prozesse müssen keine direkte Aufsicht von den ML -Köpfen haben. Wir möchten jedoch die Kontrolle über das Modell, das sie hauptsächlich für die Qualitätskontrolle verwenden. Die Lieferteams, die jedes Länder verarbeiten, sind nicht technisch versiert. Daher müssen wir sicherstellen, dass alle Länder eine sehr strenge Richtlinien für den Stil durchlaufen, die wir geschrieben haben. Ich habe also vor, Workflows zu schreiben, die überprüft, ob bestimmte Dateien geändert wurden, um sicherzustellen, dass sie nichts brechen. Wenn tatsächlich eine Änderung erforderlich ist, muss ein Kern -Repo -Code -Code -Code -Incorer vorübergehen und überprüft werden, bevor die PR zusammengeführt werden kann.
Ich hoffe, dies zeigt das Problem, das ich zu lösen versuche. Ich habe das Gefühl, dass es aber gerne ein breiteres Publikum haben würde. Der Grund, warum ich mich dem Git -Submodul anlehne, ist die Fähigkeit, PRS in separaten Repos für eine einfachere Wartung zu haben, aber auch ein Submodule -Versions -Update zurückzuversetzen, wenn sich Änderungen durch Brechen befinden. Der Plan hier ist, dass die Teams nicht in einem Git -Submodul, sondern direkt im Mono -Repo selbst arbeiten. Dies liegt daran, dass sie seit 2 Jahren so arbeiten und dies mehr Entwicklergeschwindigkeit bietet. Ich habe vor, Git -Hooks und -überprüfungen zu erstellen, um sicherzustellen, dass Git -Submodules -Zweige übereinstimmen, um baumelnde Zeiger zu vermeiden. Wenn ich etwas verpasst habe, lassen Sie es mich wissen und ich werde den Beitrag bearbeiten. Ich möchte auch wissen, wie ich in diesem Ansatz Tools wie NX oder Hosen verwenden kann und ob es überhaupt notwendig ist.