Come posso presentare una richiesta per la "gestione delle dipendenze"?

Attualmente sto cercando di fare un caso per l'adozione della gestione delle dipendenze per build (ala Maven, Ivy, NuGet) e la creazione di un repository interno per moduli condivisi, di cui abbiamo oltre una dozzina a livello aziendale. Quali sono i principali punti di forza di questa tecnica di costruzione? Quelli che ho finora:

Facilita il processo di distribuzione e importazione di moduli condivisi, in particolare gli aggiornamenti di versione.
Richiede che le dipendenze dei moduli condivisi siano documentate con precisione.
Rimuove i moduli condivisi dal controllo del codice sorgente, velocizzando e semplificando i checkout / check-in _{(quando si hanno applicazioni con oltre 20 librerie questo è un fattore reale)} .
Consente un maggiore controllo o consapevolezza di quali librerie di terze parti vengono utilizzate nella propria organizzazione.

Ci sono dei punti vendita che mi mancano? Ci sono studi o articoli che danno metriche di miglioramento?

dependency-management

— C. Ross
fonte

Penso che tu l'abbia inchiodato.

— Mike Partridge,

Non tornerò mai indietro per le molte ore della mia vita sprecate in configurazioni Maven rotte. Mi sono convinto che, indipendentemente dalle buone intenzioni, in un grande corp, alla fine diventerà un disordine non mantenuto che ti risucchia la vita fino a quando non sei un guscio vuoto.

— MrFox,

@suslik Ti interessa approfondire cos'è un setup "rotto Maven"?

— Andrew T Finnell,

@AndrewFinnell Supponiamo che ci siano 5 gruppi che lavorano su progetti che devi raccogliere per compilare la tua build e, a causa del cattivo coordinamento, tutti finiscono a seconda delle diverse versioni delle librerie. Quindi si scopre che uno dei progetti non doveva ancora essere "rilasciato" ma (nessuno lo ha detto a Maven!) Hai una dipendenza che devi soddisfare. Questo non dovrebbe "accadere", ma la risoluzione automatica lo rende troppo facile. Se tutti avessero una directory / libs da mantenere in svn, ciò costringerebbe le persone a fermarsi e fare domande prima che le cose sfuggano di mano.

— MrFox,

@MrFox Questo è davvero a causa della scarsa coordinazione, non della risoluzione delle dipendenze di Maven. Ho vissuto le stesse situazioni e non sono un fan di Maven, ma penso che gli strumenti non dovrebbero risolvere problemi legati all'uomo come rilasci prematuri, mancanza di comunicazione, mancanza di test, scarsa manutenzione, ecc.

— scriptin

Risposte:

Non sono sicuro al 100% degli aspetti positivi. Ecco alcuni aspetti negativi

Spesso si finisce per aggiungere dipendenze a server / endpoint di terze parti che potrebbero non essere stabili.

Ho avuto per caso con Bower che il repository di alcune dipendenze è stato eliminato o spostato. Quindi arriva un nuovo sviluppatore, clona il mio repository, digita bower installe ottiene errori per repository non accessibili. Se invece avessi registrato il codice di terze parti nel mio repository quel problema scompare.

Questo è risolto come suggerisce l'OP se stai estraendo deps da copie conservate su un server che esegui.
Più duro per i noobs.

Lavoro con studenti d'arte con pochissima esperienza nella riga di comando. Fanno arte con Processing, Arduino, Unity3D e cavarsela con pochissime conoscenze tecniche. Volevano usare un po 'di HTML5 / JavaScript che ho scritto. Passi a causa del pergolato
1. Scarica Zip di repository da github (nota che si trova sulla destra di ogni repository su github. Perché non conoscono git)
2. Scarica e installa nodo (in modo da poter eseguire npm per installare bower)
3. Installa git o msysgit (perché Bower lo richiede e non è installato sui computer di molti studenti)
4. Installa bower ( npm install -g bower)
5. bower install (finalmente per ottenere le nostre dipendenze)
I passaggi 2-5 possono essere tutti eliminati se eseguiamo semplicemente il check-in dei file nel nostro repository github. Quei passaggi probabilmente suoneranno super facili per te e per me. Per gli studenti erano molto confusi e volevano sapere quali erano tutti i passaggi dove e cosa erano per i quali potrebbe essere un buon apprendimento possibilmente, ma era del tutto ortogonale all'argomento della classe e quindi probabilmente rapidamente dimenticato.
Aggiunge un altro passo quando si tira.

È successo molte volte che eseguo un git pull origin mastertest, quindi collaudo il mio codice e ci vogliono dai 5 ai 10 minuti per ricordare che ho bisogno di digitare bower install per ottenere gli ultimi aggiornamenti. Sono sicuro che è facilmente risolvibile con un po 'di hook di script pull.
Rende più difficile la ramificazione del git

Se 2 rami hanno profondità diverse, sei un po 'avvitato. Suppongo che tu possa digitare bower installdopo ogni git checkout. Questo per quanto riguarda la velocità.

Per quanto riguarda i tuoi aspetti positivi, penso che ci siano contro esempi per ognuno di questi

Facilita il processo di distribuzione e importazione di moduli condivisi, in particolare gli aggiornamenti di versione.

vs cosa? Non è certamente più facile da distribuire. Tirare un repository invece di 20 non è più facile ed è più probabile che fallisca. Vedi # 1 sopra

Rimuove i moduli condivisi dal controllo del codice sorgente, velocizzando e semplificando i checkout / check-in (quando si hanno applicazioni con oltre 20 librerie questo è un fattore reale).

Viceversa significa che dipendi dagli altri per le correzioni. Significa che se i tuoi deps provengono da una fonte di terze parti e hai bisogno di un bug corretto devi aspettare che applichino la tua patch. Peggio ancora, probabilmente non puoi semplicemente prendere la versione che desideri più la tua patch, dovresti prendere le ultime che potrebbero non essere retrocompatibili con il tuo progetto.

Puoi risolverlo clonando i loro repository separatamente e quindi indirizzi i deps del tuo progetto alle tue copie. Quindi applichi eventuali correzioni alle tue copie. Ovviamente potresti farlo anche se copi la fonte nel tuo repository

Consente un maggiore controllo o consapevolezza di quali librerie di terze parti vengono utilizzate nella propria organizzazione.

Sembra discutibile. Richiedi agli sviluppatori di mettere sotto le loro librerie di terze parti nella loro cartella <ProjectRoot>/3rdparty/<nameOfDep>. È altrettanto facile vedere quali librerie di terze parti vengono utilizzate.

Non sto dicendo che non ci sono aspetti positivi. L'ultima squadra in cui facevo parte aveva> 100 deps di terze parti. Sto solo sottolineando che non sono tutte rose. Sto valutando se dovrei sbarazzarmi del pergolato per le mie esigenze, ad esempio.

— gman
fonte

Wow, molti voti negativi e non una sola giustificazione per loro. Buon lavoro! :(

— gman,

Non ho mai usato il pergolato, ma la necessità di installogni volta che fai il checkout sembra un difetto di progettazione. Dovrebbe verificare la sua configurazione quando costruisce un progetto: se ci sono cambiamenti, dovrebbe ricostruire da zero. Inoltre, spostare i repository è irrilevante per Maven, poiché estrae gli artefatti dal repository Maven, che memorizza gli artefatti, non i repository effettivi con codice. Puoi cambiare artifactIde groupIdnella prossima versione del tuo artefatto se lo pubblichi nel repository Maven. Quindi, i tuoi punti 1 e 4 sono per lo più irrilevanti per Maven in particolare. # 3 può essere sostituito con mvn clean(a volte)

— scriptin

Pur essendo vero, il n. 2 non è uno svantaggio: è un compromesso. Certo, devi imparare i tuoi strumenti! Ad esempio, Git è piuttosto difficile da capire, ma non mi arrenderò a causa di dem noobs.

— scriptin

Dai un'occhiata a The Twelve Factor App

In particolare leggi cosa hanno da dire sulle dipendenze . Noterai che un buon design fornisce un meccanismo dichiarativo per localizzare le dipendenze, in Java questo viene spesso realizzato attraverso Maven. Ivy e NuGet funzionano bene, ma Maven è attualmente il leader del settore e Ivy è decisamente un duro lavoro.

Se aderisci al processo di rilascio di Maven (sviluppa istantanee fino a quando non è pronta una versione formale, non provare mai a sovrascrivere una versione precedente, usa un gestore di repository adeguato come Nexus o Artifactory), dovresti avere un processo di compilazione che ronza bene.

Una volta che hai messo in atto un solido processo di compilazione dichiarativo, si aprono le porte ad altre buone pratiche come l'integrazione continua con Jenkins , l'analisi continua del codice con il sonar e ti ritroverai a cercare una migliore strategia di ramificazione del controllo versione usando git .

Ognuno dei precedenti si basa sul core che è Maven. In questi giorni, è praticamente una decisione semplicissima.

— Gary Rowe
fonte

Ho guardato l'app The Dodici Fattori, ma è estremamente controversa e solo un po 'è rilevante. Anche spingere Maven non mi aiuta a spiegare perché abbiamo bisogno dell'iniezione di dipendenza. Nel complesso questa risposta non mi aiuta a vendere Iniezione delle dipendenze, mi dice solo un sacco di cose che devo fare per il mio processo di compilazione.

— C. Ross,

Dependency Injection (il modello di progettazione) non è Gestione delle dipendenze (il modello di generazione). Hai già trattato tutti gli aspetti più importanti della tua domanda. Se la tua squadra ha ancora bisogno di convincere dopo aver ascoltato quelli, allora vedere cosa porterà la gestione delle dipendenze dovrebbe essere il convincente finale.

— Gary Rowe,

E l'articolo numero 1 nella nostra top 10 è ...

(rullo di tamburi)

Ogni sviluppatore costruisce esattamente con le stesse versioni di tutte le dipendenze, quindi non devi mai chiederti cosa distribuire in produzione.

— Ross Patterson
fonte

In che modo è diverso dal controllo delle dipendenze? In effetti, se non verifichi le dipendenze, corri il rischio che alcune terze parti infrangano la tua distribuzione. Ho avuto questo accadere più di una volta in cui un dep di bower punta a un repository che qualcuno ha eliminato o rinominato. Se avessi appena copiato la fonte nel nostro repository quel problema scompare.

— Gman,