È buona norma archiviare i tempi di esecuzione del framework sotto il controllo del codice sorgente?

So che molti negozi di software tengono i binari sotto il controllo del codice sorgente . Tuttavia, il nostro negozio era arrivato a memorizzare interi framework nel repository: runtime DirectX, CUDA, nVidia Optix, qualunque cosa.

Si dice che semplifichi la configurazione di una macchina di sviluppo (presumibilmente, ottieni le ultime novità e inizia a scrivere codice). Tuttavia, gonfia considerevolmente il repository e lo carica di cronologia irrilevante.

Non ho mai visto un tale schema di utilizzo. La consideri una buona pratica?

[EDIT:] Non ho problemi con i binari di terze parti isolati per il controllo del codice sorgente. La domanda si riferisce a runtime dell'intero framework, generalmente costituiti da oltre 10 binari. Ad esempio, prendi Windows SDK (che non conserviamo nel repository, grazie a dio, ma in linea di principio non vedo differenze).

I binari non sono generalmente adatti al sistema di controllo della versione perché:

• non beneficiano delle funzionalità di controllo versione (unisci, diff)
• aumentano le dimensioni del repository ...
• ... che conta perché non rimuovi facilmente una versione da un VCS (i VCS sono creati per conservare la cronologia), al contrario dei repository di artefatti come Nexus , che sono semplici directory condivise (facili da ripulire: cd+ rm!)
• dovrebbero essere referenziati in un VCS come testo , una dichiarazione di percorso + versione: puoi conservare la cronologia rilevante in quel modo , registrando qualsiasi cambiamento di versione binaria come un cambiamento in quel file di testo (come un pom.xml se stai usando Nexus per esempio)

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

Inoltre, la configurazione dell'ambiente è qualcosa di diverso dallo sviluppo. Sviluppiamo principalmente in Python e ha uno strumento chiamato virtualenv che ti 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 del genere. Niente di tutto ciò è controllato dalla versione. È solo lo script di installazione.

Gettare l'intero quadro nell'ambito del tuo progetto principale ingombrerà la tua storia e rovinerà seriamente le cose. Non fa parte del tuo progetto e dovrebbe essere trattato in modo diverso.

In genere è una buona idea eseguire la gestione della configurazione con le versioni del framework. Se il tuo codice necessita di una versione DirectX specifica, tale versione dovrebbe essere facilmente disponibile e se dai un'occhiata a una versione precedente del tuo software, dovrebbe essere facile determinare quali dipendenze esterne ha.

Quello che non penso sia una buona idea qui è usare il tuo 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. Laddove riteniamo che abbia senso, disponiamo di file readme per documentare quale versione dello strumento appartiene a quale versione del software o, se possibile, disponiamo di script per l'installazione o l'utilizzo di una versione specifica. Solo i file readme e gli script passano al controllo versione.

Manteniamo anche le versioni precedenti di strumenti e librerie fino a quando pensiamo che ci possa essere una possibilità di ricostruire e versioni precedenti a seconda di tali strumenti. In questo modo ci dà la possibilità di eliminare alcune delle librerie e degli strumenti molto vecchi dalla nostra unità di rete quando sono stati deprecati (ovviamente, nel caso in cui abbiamo archivi su supporti esterni).

Penso che i binari dovrebbero essere archiviati da qualche parte. Suggerirei di memorizzarli al di fuori di un repository, soprattutto se sono grandi e portano a grandi tempi di check out. Non vedrò che è una cattiva pratica, ma non è nemmeno quella che ho visto.

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

Personalmente considero questa una pessima pratica. Preferisco impostare un wiki con le istruzioni di installazione e caricare i binari necessari su di esso. Questi file sono necessari solo ai nuovi sviluppatori, non è necessario gonfiare i repository di tutti gli altri.

C'è una buona ragione per farlo, vale a dire che hai tutto ciò di cui hai bisogno in un'unica posizione, senza dipendenze esterne.

Questo è molto più importante di quanto tu possa pensare. In sostanza, ti assicura di non fare affidamento su un artefatto su un server del fornitore che potrebbe scomparire dopo alcuni anni, poiché hai tutto internamente.

Riguardo al gonfiamento del repository. 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 il tuo schema di backup centrale per qualche motivo fallisce un giorno.

È una questione di priorità o politica. Fintanto che la decisione è deliberata, starei bene con questo.