È buona norma archiviare i runtime del framework sotto il controllo del codice sorgente?

Sto bene con la versione che controlla le risorse binarie. Sono contro la versione che controlla i file generati .

Inoltre, la configurazione dell'ambiente è qualcosa di diverso dallo sviluppo. Per lo più sviluppiamo in Python e ha uno strumento chiamato virtualenv che consente di creare un ambiente isolato leggero (comprese le librerie) per un progetto. Quando controlliamo le nostre fonti, abbiamo uno script di installazione che crea questo virtualenv. Usando un manifest, questo specifica quali versioni delle librerie sono necessarie e altre cose simili. Niente di tutto questo è controllato dalla versione. Lo script di installazione è solo.

Lanciare l'intero framework sotto il tuo progetto principale ingombra la tua storia e seriamente rovina tutto. Non fa parte del tuo progetto e dovrebbe essere trattato diversamente.

Generalmente è una buona idea fare la gestione della configurazione con le versioni del framework. Se il codice richiede una specifica versione di DirectX, quella versione dovrebbe essere facilmente disponibile e, se si controlla una versione precedente del software, dovrebbe essere facile determinare quali dipendenze esterne ha.

Quello che non penso sia una buona idea qui è usare il tipico sistema di controllo delle versioni per archiviare quei binari. Nella nostra azienda, archiviamo ogni versione di framework, librerie e strumenti esterni in una struttura di sottocartelle su un'unità di rete. Dove pensiamo che abbia senso, abbiamo file readme per documentare quale versione dello strumento appartiene a quale versione del software, o, se possibile, abbiamo script per l'installazione o l'utilizzo di una versione specifica. Solo i file Leggimi e gli script entrano nel controllo della versione.

Conserviamo anche versioni precedenti di strumenti e librerie finché pensiamo che potrebbe esserci la possibilità di ricostruire e una versione precedente a seconda di tali strumenti. In questo modo ci dà la possibilità di cancellare alcuni degli strumenti e librerie molto vecchi della nostra unità di rete quando sono stati deprecati (ovviamente, nel caso avessimo archivi su supporti esterni).

Penso che i binari dovrebbero essere negozi da qualche parte. Suggerirei di archiviarli al di fuori di un repository, specialmente se sono grandi e portano a tempi di check-out più grandi. Non vedrò che è una cattiva pratica, ma non è nemmeno una che ho visto.

Questa potrebbe essere una buona idea se la tua organizzazione ha molti progetti che hanno come target diverse versioni di runtime. Ti assicura di avere il giusto binario di runtime quando lavori sui progetti giusti.

Personalmente ritengo che questa sia una pessima pratica. Preferisco creare un wiki con le istruzioni di installazione e caricare i binari necessari su di esso. Questi file sono necessari solo per i nuovi sviluppatori, non è necessario espandere i repository di tutti gli altri.

C'è una buona ragione per farlo, ovvero che hai tutto ciò di cui hai bisogno in una posizione singola , senza alcuna dipendenza esterna.

Questo è molto più importante di quanto tu possa pensare. In sostanza, ti assicuri di non fare affidamento su un artefatto su un server venditore che potrebbe scomparire dopo alcuni anni, dal momento che hai tutto in-house.

Riguardo al deposito gonfiato. Questo è solo un problema se il tuo VCS mantiene una copia locale completa (git fa questo, cvs no) poiché la clonazione e / o l'aggiornamento saranno lenti. In cambio avrai copie su ogni macchina di sviluppo, che potrebbe salvare la tua azienda se lo schema di backup centrale per qualche motivo fallisce un giorno.

È una questione di priorità o politica. Finché la decisione è intenzionale, mi andrebbe bene con questo.