Comment gardez-vous les binaires publiés sous contrôle de version?

14

Comment gardez-vous les binaires publiés sous contrôle de version? Cela permet de suivre les éléments modifiés entre chaque version. Je veux séparer les binaires publiés du référentiel source. Les binaires publiés sont soit construits à partir du logiciel d'intégration continue, soit compilés manuellement.

version-control release-management

— linquize
source

Qu'entendez-vous par «suivre les éléments qui ont changé»? Quels sont les attributs des versions binaires que vous suivez (ou souhaitez suivre)? Cela semble juste étrange, donc je suis curieux.

— Jeremy Heiler

par exemple entre v1.0.0 et v1.0.1, seul ABC.exe est modifié, tandis que la dépendance DEF.dll reste inchangée

— linquize

1

Comment déterminez-vous cela en regardant les binaires?

— Jeremy Heiler

diff ancienne et nouvelle version du même fichier

— linquize

21

Deux options:

a) Non. Assurez-vous simplement que vous disposez de versions déterministes reproductibles, c'est-à-dire que la génération de la même révision de contrôle de source avec la même configuration produit toujours exactement le même binaire.

b) Désignez un répertoire quelque part comme source faisant autorité pour les versions publiées. Intégrez le téléchargement des fichiers binaires à la procédure de déploiement / expédition et assurez-vous que le répertoire de publication publiée est couvert par votre plan de sauvegarde. Vous n'avez pas besoin de contrôle de version ici; les builds sont à écriture unique, si vous avez besoin de changer quoi que ce soit, vous faites une nouvelle build.

Quoi qu'il en soit, les binaires et autres sorties de génération n'appartiennent pas au contrôle de source, pour de nombreuses raisons.

— tdammers
source

7

a) n'est souvent pas possible bien sûr blogs.msdn.com/b/ericlippert/archive/2012/05/31/…

— jk.

@jk: joli lien. Je suppose qu'avoir le code source et tous les fichiers d'entrée pour l'étape de construction entièrement sous contrôle de source (et avoir la bonne version du compilateur installée) peut être "suffisamment déterministe" dans beaucoup de scénarios du monde réel (et pas assez dans d'autres, bien sûr ). Cela dépend de la casse de l'importance d'avoir des binaires reproductibles bit par bit.

— Doc Brown

10

Utilisez un référentiel d'artefacts pour les binaires, pas un système de contrôle de version. Une version spécifique d'un binaire publié n'est pas censée changer au fil du temps, donc le contrôle de version n'a pas de sens puisque le ou les fichiers ne changeraient pas.

Voir par exemple les référentiels Maven comme référentiel pour archiver / publier / proposer des versions et autres binaires (par exemple, comme la documentation)

— mhaller
source

une version spécifique d'un fichier source publié n'est pas non plus censée changer au fil du temps. SCM est un bon endroit pour mettre le binaire livré, il vous suffit de le stocker à côté des fichiers source utilisés pour le construire.

— gbjbaanb

2

gbjbaanb, SCM signifie "Source Control Management". Cela devrait donner à quiconque une indication que ces systèmes ne sont pas conçus pour stocker des binaires mais pour les sources. Si vous souhaitez toujours stocker des fichiers binaires, allez-y. Je ne veux pas.

— mhaller

4

SCM signifie "Software Control Management" mais bon essai. le "code source" n'est souvent pas seulement des fichiers texte, mais des images, des documents, des diagrammes, etc.

— gbjbaanb

Normalement, «Gestion de la configuration logicielle». Je n'ai jamais entendu parler de "Software Control Management".

— James McLeod

7

Il suffit de les mettre dedans. Il n'y a pas de problème avec ça, à moins que vous n'utilisiez git (qui ne fusionne pas bien les binaires, donc vous devrez les gérer vous-même) ou que vous les commettez trop de fois (ne validez que quand c'est prêt à expédier, pas à chaque fois que vous le construisez).

La plupart des binaires delta SCMs fonctionnent assez bien, nous avions l'habitude de mettre une DLL de ressource de 2Mb dans notre SVN et elle serait delta à quelques ko à chaque fois.

J'entends beaucoup d'arguments selon lesquels les SCM sont pour la source, pas pour les binaires, mais c'est clairement faux si l'on considère que la plupart des logiciels sont constitués d'images, même si ce ne sont que des fichiers d'icônes. Ce sont des binaires, mais ils font partie de la source, alors mettez-les et ne soyez pas si dogmatiques à ce sujet. J'entends également que vous pouvez simplement reconstruire le binaire en cas de besoin, souvent c'est le cas, mais cela peut être un énorme effort de perte de temps pour les systèmes plus anciens qui ne sont plus activement pris en charge. Si vous devez recréer un système avec uniquement des Service Packs ou des correctifs plus anciens pour correspondre au système qui a été utilisé pour créer un binaire il y a 3 ans, vous serez heureux d'avoir ajouté le bac à votre SCM à l'époque.

La seule fois où vous devez vous soucier de l'ajout de builds à votre SCM est si vous le faites automatiquement dans le cadre du processus de serveur de build - ne faites pas cela. Vous remplirez votre SCM de builds qui ne vous apporteront aucun avantage. Au lieu de cela, ajoutez-les uniquement lorsqu'ils sont publiés. De cette façon, vous savez exactement ce que possède votre client et vous pouvez reproduire tous les problèmes signalés par le client avec les fichiers binaires qu'ils utilisent, et non ceux que vous avez reconstruits (en utilisant, disons, les dernières mises à jour du compilateur ou du système d'exploitation).

— gbjbaanb
source

1

@ MarnenLaibow-Koser, vous n'avez évidemment pas travaillé dans l'industrie depuis longtemps. Les environnements de construction changent au fil du temps.Alors que vous pourriez en reconstruire un ancien, il est probable que vous devrez passer des jours à recréer l'env avec les bons outils et SDK. Ce que j'espère que vous avez versionné ....

— gbjbaanb

1

J'imagine que vous seriez en mesure de construire un ancien binaire VC6 qui a été compilé sur une machine XP en utilisant un ancien SDK que Microsoft ne juge plus approprié de publier. Si quelqu'un demande ce binaire, il est facile de le saisir au même endroit où tout le reste est stocké. Le coût de gestion qui est énorme par rapport à la douleur d'avoir à reconstruire, et le coût de le stocker avec la source est insignifiant. J'y suis allé (avec une application VB6 faite avec un contrôle tiers lorsque le client a signalé un bug - obtenir le binaire et l'exécuter était beaucoup plus facile que de le reconstruire, ce qui s'est avéré impossible)

— gbjbaanb

1

@gjbaanb J'admettrai également que vous êtes dans une situation différente de moi d'une autre manière: toutes mes dépendances externes sont des logiciels libres, donc elles ne peuvent pas disparaître simplement parce qu'une entreprise ne juge plus bon de les libérer.

— Marnen Laibow-Koser

1

Mon point est que les SCM peuvent tout stocker, il n'est donc pas nécessaire de ne pas stocker le binaire séparément de sa source. C'est pratique et facile et vous garantit de savoir ce qui se passera des années plus tard. Il n'y a aucun inconvénient à le faire. Toute version donnée elle-même n'est également synchronisée qu'avec un commit source particulier. Je ne vois pas le problème, sauf que certaines personnes pensent que SCM signifie uniquement le texte du code source. Non, utilisez-le pour stocker presque tout (parfois des outils de construction ou des bibliothèques s'ils ne sont pas énormes), la vie devient beaucoup plus facile.

— gbjbaanb

1

@gjbaanb Et mon point est que vous vous trompez à ce sujet. :) Bien sûr, les VCS peuvent tout stocker, mais ils ne sont pas bien configurés pour stocker des fichiers qui ne vivent que pour un seul commit (après tout, vous ne voulez pas que votre build r500 soit stocké dans le repo à r550; ce sera juste déroutant) . Le problème fondamental du stockage des artefacts de génération dans le référentiel n'est pas qu'ils sont binaires , mais qu'ils sont des données dérivées et ne seront plus synchronisés avec leur source dans le même référentiel. Les mêmes arguments que j'utilise s'appliqueraient aux fichiers texte générés.

— Marnen Laibow-Koser

5

Je ne garde pas les binaires des versions sous contrôle de version. Au lieu de cela, je les publie à un endroit bien défini afin que d'autres outils et les inspectent et les utilisent. Je fais beaucoup de travail en Java, ce qui signifie que je publie des fichiers JAR dans les référentiels Maven locaux. Cependant, je n'utilise pas ces outils pour suivre ce qui a changé par version. Après tout, ce sont des binaires et il n'y a pas vraiment grand-chose à suivre à part le nombre de fichiers.

Afin de suivre les changements entre les versions, je voudrais étiqueter ou étiqueter les versions dans mon système de contrôle de version avec le numéro de version de la version. Mais ce n'est vraiment que pour suivre les fichiers source, pas les binaires. Les binaires sont des artefacts de la génération et n'ont pas besoin d'être sous contrôle de version.

— Jeremy Heiler
source

1

La meilleure solution consiste à utiliser exclusivement votre système CI pour toutes les versions significatives sur le plan organisationnel (versions, versions candidates, etc.).

Cela lie systématiquement les fichiers binaires publiés au contenu du référentiel sans avoir à stocker réellement les fichiers binaires dans le référentiel.

Par exemple, si vous utilisez SVN, utilisez le schéma d'organisation de branche principale; effectuez tous les développements quotidiens dans / trunk et créez une balise / pour chaque version une fois qu'elle est prête.

Configurez votre système CI pour construire à partir de balises ainsi que de tronc, et faites-le écrire la sortie dans un répertoire réseau dont la structure reflète la structure de niveau supérieur du référentiel:

/ builds / trunk / [rev] [date] [build_id] /
/ builds / tags / release_0_1_3beta4 / [rev] [date] [build_id] /

Le système de build devra traiter le répertoire / builds / trunk / comme un tampon circulaire, stocker les n dernières builds, supprimer les anciennes builds au fur et à mesure.

Le répertoire / builds / tags / , d'autre part, est un magasin permanent. Les artefacts de construction eux-mêmes sont stockés dans des répertoires dont les noms sont générés selon le schéma suivant:

[rev] [date] [build_id]

où [rev] est l'ID de révision SVN, [date] est la date au format YYYYMMDD et [build_id] est un compteur unique à 3 chiffres, incrémentant à partir de la première génération, rendant chaque répertoire de construction unique.

Le processus détaillé ci-dessus vous offre les avantages suivants:

Les artefacts de build sont liés systématiquement à la source qui les a générés, vous pouvez donc trouver très facilement la source d'un artefact de build particulier (et vice versa).
Cela constitue la base d'une automatisation supplémentaire des versions. Par exemple, génération automatique de documents de sortie etc ...

— William Payne
source