Argomenti contro il check-in dei file binari negli SCM

Lavoro per un'azienda che sviluppa principalmente applicazioni Java e sto cercando di convincere tutti a interrompere il check-in dei file binari (dipendenze e prodotti finali) su SCM.

Sanno che è una cattiva pratica ma pensano che "funziona" e non è un vero problema anche quando molte persone conoscono Maven e altri strumenti per la costruzione oltre a Ant. Sia i PM che i programmatori (circa 50 persone) sono pronti ad ascoltare qualsiasi argomento e persino riconoscere che è uno spreco di spazio di backup, ma voglio essere davvero convincente perché il cambio di abitudine comporterebbe un grande sforzo. Quali argomenti usi per supportare una modifica?

Modifica: Ok, ha senso fare una distinzione tra file che quasi non cambiano, come dipendenze e file generati. Anche così, sono interessato a ragioni contro quest'ultima.

Lo spazio di archiviazione è economico, quindi non è un argomento molto convincente sul perché dovresti o non dovresti fare il check-in dei file.

Invece, puoi fare appello allo scopo di SCM. Ogni file tracciato da SCM rappresenta la necessità di gestire le modifiche parallele e distribuite che il tuo team sta facendo. Niente di tutto ciò è evidente fino a quando due membri del team non provano a modificare lo stesso file. Risolvere tali cambiamenti è ciò a cui SCM è realmente interessato, prevenire la sovrascrittura accidentale del lavoro di un altro sviluppatore e, si spera, automatizzare il processo di fusione di tali cambiamenti.

L'unione di file binari di solito è una vera sfida, perché non esiste un modo sano per uno strumento di unione generico di indovinare come dovrebbe funzionare un file binario unito. Non può sapere abbastanza su come funzionano gli indici o i puntatori di offset nel file se non appositamente progettato per riconoscere quel particolare tipo di file.

Ciò significa che dipende dallo sviluppatore unire il file binario a mano, quindi dire a SCM che il file è stato unito. Dal momento che lo sta facendo uno sviluppatore, l'unione potrebbe in realtà non coprire tutte le modifiche di entrambi i check-in precedenti e poiché il file è binario, non esiste un modo automatico per verificare l'unione.

Per i formati binari che rappresentano realmente le fonti del progetto, come le risorse artistiche, questo è un passaggio sfortunato, ma necessario. Tuttavia, gli output di compilazione non sono origini. Non è necessario unirli, perché le origini possono essere unite e un output di generazione risultante può essere rigenerato. Tracciare e gestire questi cambiamenti è uno spreco del 100%. Spreca le risorse di SCM, anche se non eccessivamente, ma spreca anche tempo per gli sviluppatori a superare i fallimenti di fusione spuri. Il tempo degli sviluppatori è molto costoso e tutto ciò che lo fa perdere è un cancro.

D'altra parte, c'è un caso particolare in cui gli output di build devono essere archiviati. Qualsiasi versione del progetto che sia mai stata spedita o distribuita dovrebbe probabilmente essere conservata a tempo indeterminato. Avere una copia esatta, byte per byte della build effettiva con cui un cliente ha problemi, può facilitare il supporto di tale cliente, dato che avrai la versione esatta che ha.

Quel backup probabilmente non dovrebbe trovarsi nello stesso repository del codice sorgente, poiché generalmente seguiranno pianificazioni diverse e avranno strutture sostanzialmente diverse.

Le dipendenze, anche in forma binaria, dovrebbero essere verificate in modo che quando qualcun altro abbassa il progetto, funzioni. La preoccupazione principale non è il tipo di file, ma come viene creato il file. La regola empirica che uso è che se può essere generato utilizzando un altro file, non viene archiviato - questo significa documentazione generata automaticamente, file binari che creo e così via.

Uno dei principali vantaggi dell'utilizzo di SCM è che è possibile ricostruire il sistema in qualsiasi momento nel passato. Quindi non ha senso memorizzare la build finale nel tuo SCM perché puoi semplicemente controllare il numero di revisione e crearlo.

Dici delle dipendenze ... Il tuo SCM dovrebbe essere configurato in modo da poter fare un checkout pulito su una nuova macchina (con ambiente di sviluppo), premere build e dovresti essere in grado di costruire il tuo sistema senza bisogno di installare altro. Quindi mantenere le dipendenze binarie nel tuo SCM è una buona idea. Le biblioteche cambiano raramente, quindi non occupano molto spazio.

Quasi nessuno lo fa.

Sembra ridondante per includere sia i file di origine che quelli di oggetto (i file di origine sono ovviamente richiesti). Oltre a non essere più necessari, i file oggetto possono occupare molto spazio. Se la tua azienda utilizza un SCM distribuito (Git, Hg, Bzr), i file binari devono essere copiati e archiviati tra tutti gli sviluppatori.