In poche parole ciò di cui ho bisogno è una semplice buona pratica per repository multipli (liberamente accoppiati o strettamente accoppiati), git Mi piacerebbe sapere che esiste un framework buono per questo, ma ho letto una dozzina di altri thread sulle conversioni e, più semplicemente, ho fornito una soluzione di compromesso, e solo uno ha suggerito "avere una buona pratica". .. proprio come un'idea
Una spiegazione più lunga sarebbe:
Forniamo ambienti distribuiti, i.e- molte soluzioni SW integrate on-premises.
Supponiamo che queste siano le mie "parti di codice":
Services : Service A Service B Service c Shared libs: db-lib logger-lib communication-lib FrontEnd: FrontEnd A FrontEnd B Android ios
Su un repository SVN monolite probabilmente sarebbe simile a questo:
--libs
--db
--logger
--com
--service A
--assets
--tests
--
--service B
--assets
--tests
--
--service C
--assets
--tests
--
--FrontEnd A - html
--assets
--FrontEnd B - android app
--assets
--FrontEnd C - iphone app
--assets
--FrontEnd D - also html
--assets
la connessione tra i servizi può essere da μServices interattivi a una suite di soluzioni (tale portale di organizzazione interna, CMS e API di terze parti)
Ora, supponiamo di aver appena eseguito una serie completa di test e integrato questo ambiente in un sito A locale del cliente (il suo portale aziendale interno).
dopo un successo con questo client vogliamo integrare il client B. Questo client ha alcune richieste e stiamo ora sviluppando una nuova versione, testando e spingendo al sito B. Le correzioni e le funzionalità sono in molti dei componenti sopra inc. libs
Ora il client A ha un bug e una richiesta minore di modifica. E abbiamo bisogno di un set completo del codice sopra con le versioni esatte O Spingilo sulla versione più recente (non sempre possibile e / o economicamente conveniente)
Dopo aver letto molti thread su s.exchange - la gestione del dep come il sottomodulo Git, il sottoalbero git, il subrepo non sono intuitivi, non sono facilmente configurabili e non cambiano automaticamente, e quindi creano overhead extra e sono soggetti a errori.
Gli strumenti di compilazione / dipendenza dipendono solitamente da un linguaggio di codifica e una soluzione mista come quella sopra non userà una soluzione per domarli tutti,
So che ci sono strumenti esterni e ho anche studiato alcuni hack suggeriti, molti di questi "ammettono" di essere una soluzione parziale per una profonda sfida.
Quindi, indipendentemente dallo "strumento" (o nessuno strumento),
Quello che mi piacerebbe davvero imparare è una buona e semplice esperienza di gestione delle dipendenze che consentirà agli sviluppatori di tornare facilmente a "un punto nel tempo", estrarre la versione corretta del codice da ciascuno dei repository a uno specifico hotfix / feature branch (s) correggono il codice (2 linee di db lib, 3 linee di servizio B), spingono il codice, costruiscono, testano e distribuiscono,
e facilmente ripetere questo ciclo con poco dolore possibile.
ad es., qualcosa del genere:
link
ma per il flusso di repository multipli dipendenti.