Le migliori pratiche per gestire progetti che dipendono l'uno dall'altro in Git?

Question

Le migliori pratiche per gestire progetti che dipendono l'uno dall'altro in Git?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (0 voti)

6

Abbiamo un prodotto per il quale utilizziamo attualmente TFS come controllo del codice sorgente. Le funzionalità di ramificazione / fusione di TFS sembrano incredibilmente carenti e stiamo migrando il progetto a Git, e voglio considerare questa come un'opportunità per ripulire il più possibile le nostre pratiche di controllo del codice sorgente.

Attualmente abbiamo un singolo repository in TFS, chiamiamolo "root". sotto la radice, abbiamo tutti i nostri progetti separati. Abbiamo 2 versioni del prodotto in questo repository e un'applicazione front-end separata per la versione 2 del prodotto; attualmente il repository ha un aspetto simile al seguente:

<root repository>
|
|___Product_V1
|   |_[master branch]
|   |_[dev branch]
|   |_[any release candidate branches]
|
|___Product_V2
|   |_[master branch]
|   |_[dev branch]
|   |_[any release candidate branches]
|
|___Web-based_front-end_for_Product_V2
    |_[master branch]
    |_[dev branch]

Ora, durante la migrazione a Git non sono sicuro di quale sarebbe la migliore pratica per archiviarli, le mie idee attuali sono le seguenti:

Disponi di un repository separato per tutti i progetti, un repository per Product_V1 , un repository per Product_V2 e un repository per Web-based_front-end_for_Product_V2 - questo sembra un problema perché il front-end basato sul Web e il back-end saranno Seperated
Dispongono di repository separati per Product_V1 e Product_V2 , hanno una cartella "backend" e una "frontend" sotto il repository Product_V2 e archiviano i progetti in essi rispettivamente. Questa sembra l'opzione migliore tra queste, ma vorrei sapere di eventuali problemi che potrebbero sorgere da persone che hanno forse fatto questo in pratica?
continua come eravamo, abbiamo un singolo repository con 3 directory sotto di esso, uno per Product_V1 , uno per Product_V2 e uno per il front-end. Sembra una non-opzione, Product_V1 e Product_V2 sono totalmente non correlate e qualsiasi modifica a Product_V1 non ha alcun effetto su Product_V2 e viceversa. Sono progetti totalmente indipendenti.

Quali sono le migliori pratiche per Git che la maggior parte delle persone seguirebbe in questa situazione? Il mio istinto è di andare con l'opzione numero 2, ma non voglio implementare qualcosa ora solo per colpire un evidente insuccesso a 6 mesi di distanza a cui non pensavo al momento dell'attuazione.

git patterns-and-practices

posta James Trotter 15.11.2016 - 12:16

fonte

4 risposte

Leggi altre domande sui tag git patterns-and-practices

Scegliere tra aggiungere una dipendenza da maven e copiare l'unica classe di cui ho bisogno cache HTTP o cache in memoria

score 1 · Answer 1

Dato che hai risposto con più informazioni, personalmente l'avrei configurato come 2 repository separati: uno per V1 e uno per V2 e per il web front-end, assumendo che il front-end Web fosse strongmente integrato e dipendente (e deve essere distribuito insieme a V2). Se si dispone di una certa quantità di astrazione tra il prodotto stesso e l'applicazione Web (una API con versione, forse?), Si potrebbe pensare a separare le due basi di codice.

Tutto ciò è meno importante di quello che il tuo team pensa della strategia di controllo / ramificazione / fusione del codice sorgente ... se hai una squadra oltre a te, intendo: D. Parlane con loro per avere una buona direzione.

score 0 · Answer 2

Personalmente, non mi piace l'opzione 3. Sto cercando di farlo in un progetto ed è un mal di testa. Quando crei repository separati, puoi utilizzare la funzione di sottomodulo di git per raccoglierli in un unico repository. Questo ti dà anche la flessibilità di lavorare su qualsiasi singolo repository da solo.

Per quanto riguarda la scelta tra le opzioni 1 e 2, non ho abbastanza informazioni per formare un'opinione strong in un modo o nell'altro.

score 0 · Answer 3

Dipende molto da come i tuoi progetti sono usati a valle da git - come sono costruiti, distribuiti, ecc. Fondamentalmente, i tuoi processi automatizzati determineranno il metodo migliore per la struttura del repository.

Ad esempio, se si stesse utilizzando, ad esempio, Jenkins per costruire i propri progetti, la struttura git ideale sarebbe quella di utilizzare un repository, con più rami (master, dev, release candidate). Avresti comunque ogni progetto separato nella sua cartella. Questa configurazione ti consente di avere un singolo lavoro Jenkins in grado di costruire tutto nel tuo repository. Tutti e tre i progetti, realizzati con un clic. Ciò non sarebbe possibile con tre repository. Solo tre volte più lavoro quando si va a costruire.

Se non hai build automatizzate, usa la struttura che sarà più familiare ai tuoi sviluppatori e rendi la transizione a git il più semplice possibile. Git è abbastanza bravo a fare il lavoro indipendentemente da come lo hai impostato. Basta configurarlo per soddisfare al meglio le tue esigenze. Probabilmente non ci saranno problemi con il repository git o il modo in cui lo hai strutturato.

Le dipendenze tra i tuoi progetti saranno risolte dal tuo sistema di build, non da git. Git si occupa solo del codice sorgente e del controllo della versione, non della creazione dell'ordine o della gestione delle dipendenze. Quindi la struttura del repository è irrilevante quando si tratta di dipendenze.

Inoltre, concordo con il guineveretoo: la strategia di ramificazione è molto importante. Avere una strana struttura git equivale a un comando più lungo o a un paio di passaggi aggiuntivi per gli sviluppatori, ma è un'azione che non viene spesso ripetuta comunque. I commit, e soprattutto i push, dovrebbero accadere solo quando un cambio di codice è costruito e testato e pronto per essere eseguito. Dall'altra parte della medaglia, avere una struttura che non corrisponde alla tua strategia di ramificazione lo rende un incubo per quasi tutti.

Per un esempio di best practice, strategia di branching provata e vera, vedi questa guida .

score 0 · Answer 4

Innanzitutto, dobbiamo tener conto che la gestione del progetto potrebbe (e lo farà) condizionare la strategia.

Detto questo, sceglierei la prima opzione .

Ecco le mie ragioni:

Sono progetti completamente indipendenti. Come hai già detto.
Ogni progetto potrebbe avere un ALM diverso (versioning, CI, CD, ecc.). Questo vale anche per il frontend.

Il back-end e il controllo delle versioni frontend possono essere gestiti in modo indipendente.

Ad esempio, utilizziamo Gitlab e finora so che non ci consente di creare tag / rami di contenuti specifici (cartelle) che si bloccano dallo stesso repository. In altre parole, ti costringe a taggare / ramificare l'intero repository.
Ogni progetto può essere sviluppato e gestito da diversi team * (questo è il mio caso, team specializzati: backend, frontend, UX, iOS, Android, CMS, ecc.)

I repository indipendenti semplificano, i processi pull, commit, merge, push .

Questo potrebbe sembrare irrilevante, ma non è specialmente se è la prima volta che lavori con git.

Assemblaggio del progetto _v2 - frontend

Entrambi i progetti possono essere assemblati ultimamente. Ad esempio, durante l'IC o tramite la gestione delle dipendenze.

Non ho familiarità con NugetServer ma sembra che possa fare il lavoro (come suggerito da @RubberDuck)

Disassemblaggio di Project_v2 - frontend

Potresti decidere (per una buona ragione) di estrarre il contenuto statico (frontend) dal back-end e servirlo attraverso un server web (IIS). Ad esempio, diciamo che hai trasformato l'app MVC in un middleware API REST simile.

Avresti già rimosso entrambi i progetti. Disporre di progetti indipendenti consente consegne / implementazioni indipendenti. Questo è importante se vai nel cloud. Potrebbe salvarti alcune distribuzioni inutili.

La chiave sta trattando il frontend come se fosse un'app mobile (solo un'altra app client con una propria pianificazione).

Riassumendo, questo approccio rende l'ALM un po 'più complicato (lavoro extra per tutti) ma guadagni in flessibilità. È meno monolitico.

Nota: ho omesso riferimenti a project_v1. IMO è evidente che non ha niente a che fare con gli altri due progetti. Ragione sufficiente per tenerlo separato.