((Il contesto che ho è, ma non penso sia troppo importante per questa domanda: solo sviluppo di Windows, Visual Studio, principalmente C ++ con alcuni .NET / C #))
(Penso che) I binari dovrebbero entrare in Controllo versione , la domanda è solo: dove?
La soluzione più semplice è sicuramente quella di mettere tutti i binari (di terze parti o di costruzione propria) di cui hai bisogno in (alcune sottocartelle) del repository sorgente del tuo prodotto.
Il "problema" è quindi se si hanno più repository di prodotti o quando gli sviluppatori stanno lavorando su più versioni differenti dello stesso repository contemporaneamente. Che è esattamente ciò che affrontiamo.
'Ovviamente, potremmo semplicemente mantenere i binari dove sono e convivere con una moltitudine di file binari identici replicati localmente e archivi binari ridondanti.
Esempio:
C:\dev\product_a\v1.0pty\boost-1.44\bin\*
C:\dev\product_a\v2.0pty\boost-1.44\bin\*
C:\dev\product_a\v3.1pty\boost-1.44\bin\*
C:\dev\product_b\v0.9pty\boost-1.44\bin\*
... tutte le cartelle bin per boost-1.44 conterranno esattamente gli stessi file dll, lib e pdb binari. Totalmente ridondante.
Ogni volta che qualcosa viene aggiunto alla cartella 3pty , le versioni di ogni repository che sono state verificate localmente dovranno copiare tutti i nuovi binari dal server. (Non un grosso problema, ma ancora.)
(Ovviamente, ci sono gestori di pacchetti come NuGet che may sono appropriati anche in un ambiente "enterprise".)
Abbiamo pensato di andare verso una soluzione "semplice", in cui abbiamo un repository di terze parti che viene sempre controllato su un percorso locale fisso e tutti i progetti che necessitano di qualsiasi componente fanno riferimento ai file necessari - e funzionerebbe su macchine sviluppatore e costruirà server perché è sempre lo stesso percorso locale unico.
Per tornare all'esempio sopra, avremmo un separatore repository 3pty , e verrebbe semplicemente estratto come:
C:\devpty\master\boost-1.44\bin\*
e tutti i progetti in qualsiasi altro repository potrebbero semplicemente fare riferimento alle cose lì.
Avere questo controllo di versione interno consentirebbe un facile aggiornamento di (nuovi) binari di terze parti e sarà anche conveniente quando i binari di terze parti, come C ++, spesso contengono anche molti file di intestazione, ecc.
- È un approccio valido?
- Ci sono dei buchi evidenti in questo approccio?
- Cosa comprerebbe un gestore di pacchetti dedicato (enterprise) che questo approccio non può fare?
Nota che non usiamo Git, Mecurial né SVN, quindi per favore non speculazioni o speculazioni riguardo al tipo di SCC.
Affrontare alcuni commenti:
- Il punto di mettere i binari sotto Controllo versione è: sapere esattamente quando, e chi li ha cambiati, oltre a fornire l'accesso e l'aggiornamento più semplice possibile agli sviluppatori.
- Questi binari non sono artefatti generati come tali. Mentre l'esempio Boost può essere costruito da noi stessi, alcuni sono librerie di terze parti in cui solo hanno i binari.
- Wrt. Collegamenti simbolici: anche se penso di essere pienamente consapevole di cosa possono fare i Junction Points, non li considero molto utili qui.