Arguments contre l'archivage des fichiers binaires dans les SCM

Je travaille pour une entreprise qui construit principalement des applications Java et j'essaie de convaincre tout le monde d'arrêter l'archivage des fichiers binaires (dépendances et produits finaux) dans SCM.

Ils savent que c'est une mauvaise pratique mais ils pensent que "ça marche" et ce n'est pas vraiment un problème même quand beaucoup de gens connaissent Maven et d'autres outils de construction en plus de Ant. Les PM et les programmeurs (environ 50 personnes) sont prêts à écouter tout argument contre et même à reconnaître que c'est un gaspillage d'espace de sauvegarde, mais je veux être vraiment convaincant car le changement d'habitude impliquerait beaucoup d'efforts. Quels arguments utilisez-vous pour soutenir un changement?

Edit: D'accord, il est logique de faire une distinction entre les fichiers qui ne changent presque pas, comme les dépendances, et les fichiers générés. Malgré cela, je m'intéresse aux raisons contre ce dernier.

L'espace de stockage est bon marché, et ce n'est donc pas un argument très convaincant pour expliquer pourquoi vous devriez ou ne devriez pas archiver les fichiers.

Au lieu de cela, vous pouvez faire appel à l'objectif de SCM. Chaque fichier suivi par SCM représente un certain besoin de gérer les changements parallèles et distribués que votre équipe effectue. Rien de tout cela n'est vraiment apparent jusqu'à ce que deux membres de l'équipe essaient de modifier le même fichier. La résolution de ces changements est la raison d'être de SCM, empêchant l'écrasement accidentel du travail d'un autre développeur et, espérons-le, automatisant le processus de fusion de ces changements.

La fusion de fichiers binaires est généralement un véritable défi, car il n'existe aucun moyen sensé pour un outil de fusion générique de deviner comment un fichier binaire fusionné devrait fonctionner. Il ne peut pas en savoir assez sur le fonctionnement des index ou des pointeurs de décalage dans le fichier, sauf s'il est spécialement conçu pour reconnaître ce type de fichier particulier.

Cela signifie que c'est au développeur de fusionner le fichier binaire à la main, puis d'indiquer au SCM que le fichier a été fusionné. Comme c'est un développeur qui le fait, la fusion peut ne pas vraiment couvrir toutes les modifications des deux enregistrements précédents, et puisque le fichier est binaire, il n'y a pas de moyen automatisé de vérifier la fusion.

Pour les formats binaires qui représentent vraiment des sources de projet, tels que les actifs artistiques, il s'agit d'une étape malheureuse, mais nécessaire. Cependant, les sorties de génération ne sont pas des sources. Il n'est pas nécessaire de les fusionner, car les sources peuvent être fusionnées et une sortie de génération résultante peut être régénérée. Le suivi et la gestion de ces changements sont des déchets à 100%. Cela gaspille les ressources du SCM, mais pas beaucoup, mais cela fait également perdre du temps aux développeurs pour surmonter les échecs de fusion fallacieux. Le temps de développement est très cher, et tout ce qui le gaspille est un cancer.

D'un autre côté, il existe un cas particulier où les sorties de build doivent être archivées. Toute version du projet qui a déjà été expédiée ou déployée devrait probablement être conservée indéfiniment. Le fait d'avoir une copie exacte, octet par octet, de la version réelle avec laquelle un client rencontre des problèmes peut faciliter la prise en charge de ce client, car vous aurez la version exacte dont il dispose.

Cette sauvegarde ne devrait probablement pas se trouver dans le même référentiel que le code source, car ils suivront généralement des planifications différentes et auront des structures fondamentalement différentes.

Les dépendances, même sous forme binaire, doivent être archivées de sorte que lorsque quelqu'un d'autre déroule le projet, cela fonctionne. La principale préoccupation n'est pas le type de fichier, mais la façon dont le fichier est créé. La règle générale que j'utilise est que si elle peut être générée à l'aide d'un autre fichier, elle n'est pas archivée - cela signifie la documentation générée automatiquement, les fichiers binaires que je crée, etc.

L'un des principaux avantages de l'utilisation des SCM est que vous pouvez reconstruire votre système à tout moment dans le passé. Il est donc inutile de stocker votre version finale dans votre SCM, car vous pouvez simplement vérifier le numéro de révision et le créer.

Vous mentionnez les dépendances ... Votre SCM doit être configuré de manière à ce que vous puissiez effectuer un check-out propre sur une nouvelle machine (avec un environnement de développement), lancer la construction et vous devriez pouvoir construire votre système sans avoir à installer quoi que ce soit d'autre. Conserver les dépendances binaires dans votre SCM est donc une bonne idée. Les bibliothèques changent rarement et ne prennent donc pas beaucoup de place.

Presque personne ne fait ça.

Semble redondant pour inclure les fichiers source et objet (les fichiers source sont évidemment nécessaires). En plus d'être simplement inutiles, les fichiers objets peuvent prendre beaucoup de place. Si votre entreprise utilise un SCM distribué (Git, Hg, Bzr), ces fichiers binaires doivent être copiés et stockés parmi tous les développeurs.