Come posso creare un caso per "gestione delle dipendenze"?

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

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

   Ho avuto successo con la pergola che repo di alcune dipendenze è stato cancellato o spostato. Quindi arriva un nuovo sviluppatore, clona il mio repository, tipi bower install e ottiene errori per i repository non accessibili. Se invece io aveva controllato il codice di terze parti nel mio repository che il problema spariva.

   Questo è risolto come suggerisce l'OP se stai tirando le copie dalle copie tenuto su un server che si esegue.

2. Harder for noobs.

   Lavoro con studenti d'arte con pochissima esperienza nella linea di comando. Fanno arte con Processing, arduino, Unity3D, e arrangiano molto poca conoscenza tecnica. Volevano usare qualche HTML5 / JavaScript che ho scritto. Passaggi a causa di bower

   1. Scarica Zip di repo da github (nota a destra di ogni repo su github. Perché non sanno git)
   2. Scarica e installa il nodo (così possiamo eseguire npm per installare bower)
   3. Installa git o msysgit (perché bower lo richiede e non è installato su macchine di molti studenti)
   4. Installa bower ( npm install -g bower )
   5. bower install (finalmente per ottenere le nostre dipendenze)

   I passaggi da 2 a 5 possono essere tutti cancellati se eseguiamo il check-in dei file nel nostro repository github. È probabile che quei passaggi sembrino super facili a te e me. Erano gli studenti molto confusionario e volevano sapere quali sono tutti i passaggi dove e cosa erano per cui potrebbe essere un buon apprendimento, possibilmente, ma era interamente ortogonale all'argomento di classe e così probabilmente rapidamente dimenticato.

3. Aggiunge un altro passo quando si tira.

   È successo molte volte che faccio un git pull origin master e poi testa il mio codice e ci vogliono dai 5 ai 10 minuti per ricordare che avevo bisogno di digitare bower install per ottenere gli ultimi deps. Sono sicuro che è facilmente risolvibile con alcuni script di pull gancio.

4. Rende più git branching

   Se 2 rami hanno differenti deps, sei un po 'fregato. Suppongo che tu possa digita bower install dopo ogni git checkout . Così tanto per la velocità.

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

Eases the process of distributing and importing shared modules, especially version upgrades.

contro cosa? Non è certamente più facile da distribuire. Tirare un repo anziché il 20 non è più facile ed è più probabile che fallisca. Vedi # 1 sopra

Removes shared modules from source control, speeding and simplifying checkouts/check ins (when you have applications with 20+ libraries this is a real factor).

Viceversa significa che dipende dagli altri per le correzioni. Significa che se i tuoi sostituti stanno prelevando 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 l'ultima che potrebbe non essere retrocompatibile con il tuo progetto.

Puoi risolverlo clonando i loro repository separatamente e poi indichi il tuo progetto alle tue copie. Quindi applichi eventuali correzioni alle tue copie. Ovviamente puoi farlo anche se copi semplicemente il codice sorgente nel tuo repository

Allows more control or awareness of what third party libs are used in your organization.

Sembra discutibile. Richiede semplicemente agli sviluppatori di mettere le librerie di terze parti nella propria cartella in <ProjectRoot>/3rdparty/<nameOfDep> . È altrettanto facile vedere quali librerie di terze parti vengono utilizzate.

Non sto dicendo che non ci sono positivi. L'ultima squadra che avevo era > 100 postazioni di terze parti. Sto solo facendo notare che non sono tutte rose. Sto valutando se dovrei sbarazzarmi di bower per i miei bisogni, per esempio.

Dai un'occhiata all'applicazione The Twelve Factor

In particolare leggi che cosa hanno da dire sulle dipendenze . Noterai che il buon design fornisce un meccanismo dichiarativo per localizzare le dipendenze, in Java questo è spesso realizzato tramite 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 una versione formale è pronta, non provi mai a sovrascrivere una versione precedente, usa un gestore di repository adeguato come Nexus o Artifactory) allora dovresti avere un processo di compilazione che canticchia bene .

Una volta attivato un solido processo di dichiarazione dichiarativa, si apre la porta ad altre buone pratiche come l'integrazione continua con Jenkins , analisi del codice continuo con Sonar e ti troverai alla ricerca di un migliore strategia di ramificazione del controllo delle versioni usando git .

Ciascuno dei precedenti build sul core che è Maven. Al giorno d'oggi, è praticamente una decisione da non sottovalutare.

E l'articolo n. 1 nella nostra lista dei migliori 10 è ...

(rullo di tamburi)

Ogni sviluppatore crea con le stesse identiche versioni di tutte le dipendenze, quindi non ti devi mai chiedere cosa distribuire in produzione.