Quels artefacts à sauvegarder pour une construction nocturne?

https://stackoverflow.com/questions/230595

04-07-2019
|

Question

Supposons que je configure une génération nocturne nocturne . Quels artefacts de la construction dois-je sauvegarder?

Par exemple:

Code source d'entrée
binaires de sortie

Aussi, combien de temps dois-je les sauvegarder et où?

Vos réponses changent-elles si je fais l'intégration continue?

La solution

Voici quelques artefacts / informations que je suis habitué à conserver à chaque build:

Nom de la balise que vous créez (balise et effectuez un nouvel achat avant de créer)
Les scripts de construction eux-mêmes ou leur numéro de version (si vous les traitez comme un projet séparé avec son propre contrôle de version)
La sortie du script de construction: journaux et produit final
Un instantané de votre environnement:
- version du compilateur
- version de l'outil de génération
- bibliothèques et versions dll / libs
- version de la base de données (client et serveur)
- version de l'ide
- version de l'interpréteur de script
- version du système d'exploitation
- version du contrôle de source (client et serveur)
- versions des autres outils utilisés dans le processus et tout ce qui pourrait influencer le contenu de vos produits générés. Je fais généralement cela avec un script qui interroge toutes ces informations et les enregistre dans un fichier texte qui devrait être stocké avec les autres artefacts de construction.

Posez-vous cette question: "si quelque chose détruit entièrement mon environnement de construction / développement, de quelles informations aurais-je besoin pour en créer un nouveau afin de pouvoir refaire ma construction # 6547 et obtenir le même résultat que celui obtenu la première fois ? "

Votre réponse est ce que vous devriez garder à chaque construction et ce sera un sous-ensemble ou un sur-ensemble des choses que j'ai déjà mentionnées.

Vous pouvez tout stocker dans votre SCM (je recommanderais un référentiel séparé), mais dans ce cas, votre question sur la durée pendant laquelle vous devriez conserver les éléments perd de leur sens. Ou vous devriez le stocker dans des dossiers compressés ou graver un CD / DVD avec le résultat de la construction et les artefacts. Quoi que vous choisissiez, ayez une copie de sauvegarde.

Vous devez les stocker aussi longtemps que vous en aurez besoin. La durée dépendra du rythme de votre équipe de développement et de votre cycle de publication.

Et non, je ne pense pas que cela change si vous procédez à une intégration continue.

Autres conseils

Vous ne devriez rien garder pour le sauver. vous devriez le sauvegarder parce que vous en avez besoin (c’est-à-dire que l’assurance qualité utilise des versions nocturnes pour tester). A quel moment, "combien de temps pour le sauvegarder" devient aussi long QA les veut.

Je ne voudrais pas "enregistrer" code source autant que tag / label. Je ne sais pas quel contrôle de source vous utilisez, mais le balisage est trivial (performances et espace disque) pour tout système de contrôle de source de qualité. Une fois que votre construction est étiquetée, à moins que vous n'ayez besoin de fichiers binaires, il ne sert à rien de les avoir simplement parce que vous pouvez simplement les recompiler si nécessaire à partir du code source.

La plupart des outils de CI vous permettent de marquer chaque construction réussie. Cela peut devenir problématique pour certains systèmes car vous pouvez facilement avoir plus de 100 tags par jour. Dans de tels cas, je vous recommande de continuer à utiliser une version nocturne et de ne la marquer que.

Ceci n’est pas une réponse directe à votre question, mais n'oubliez pas de contrôler la version de la configuration de construction nocturne. Lorsque la structure du projet change, vous devrez peut-être modifier le processus de génération, ce qui cassera les anciennes versions à partir de ce point.

En plus des fichiers binaires que tout le monde a déjà mentionnés, je recommanderais de créer un serveur de symboles et un serveur source et assurez-vous que vous obtenez les informations correctes et pertinentes. Cela aidera énormément au débogage.

Nous sauvegardons les fichiers binaires, supprimés et non supprimés (nous avons donc exactement le même fichier binaire, une fois avec et une fois sans symboles de débogage). En outre, nous construisons tous les éléments deux fois, une fois avec la sortie de débogage activée et une autre sans (encore une fois, dépouillé et dépouillé, de sorte que chaque construction donne 4 binaires). La construction est stockée dans un répertoire en fonction du numéro de révision SVN. De cette façon, nous pouvons toujours conserver le source du référentiel SVN en vérifiant simplement cette révision (de cette façon, le source est également archivé).

Un sujet surprenant dont j'ai récemment entendu parler: si vous vous trouvez dans un environnement susceptible d'être audité, vous voudrez sauvegarder toute la sortie de votre construction, la sortie du script, la sortie du compilateur, etc.

C’est le seul moyen de vérifier vos paramètres de compilation, vos étapes de construction, etc.

De plus, pendant combien de temps pour les enregistrer et où les enregistrer?

Sauvegardez-les jusqu'à ce que vous sachiez que la construction ne sera pas mise en production tant que vous disposez des éléments compilés.

Votre système SCM est un endroit logique pour les enregistrer. Une autre option consiste à utiliser un outil qui les enregistrera automatiquement pour vous, comme AnthillPro et ses semblables.

Nous faisons quelque chose de proche de " embedded " développement ici, et je peux vous dire ce que nous économisons:

le numéro de révision SVN et l'horodatage, ainsi que la machine sur laquelle il a été construit et par qui (également gravé dans les fichiers binaires de la construction)
un journal de construction complet, indiquant s’il s’agissait d’une construction complète / incrémentielle, de toute sortie intéressante (STDERR) des outils de cuisson de données produits, d'une liste de fichiers compilés et de tous les avertissements du compilateur (ceci compresse très bien, étant du texte)
les fichiers binaires réels (pour les configurations de construction de 1 à 8)
fichiers produits en tant qu'effet secondaire de la liaison: un fichier de commande de l'éditeur de liens, un mappage d'adresses et une sorte de "manifeste". fichier indiquant ce qui a été gravé dans les binaires finaux (CRC et taille de chacun), ainsi que la base de données de débogage (équivalent .pdb)

Nous vous envoyons également le résultat de l'exécution de certains outils par le biais de l'option "effet secondaire". fichiers aux utilisateurs intéressés. Nous ne les archivons pas car nous pourrons les reproduire plus tard, mais ces rapports incluent:

total et delta de la taille du système de fichiers, ventilés par type de fichier et / ou répertoire
total et delta des tailles de section de code (.text, .data, .rodata, .bss, .sinit, etc.)

Lorsque des tests unitaires ou des tests fonctionnels (par exemple, des tests de fumée) sont en cours d'exécution, ces résultats apparaissent dans le journal de construction.

Nous n'avons encore rien jeté - étant donné que nos builds cibles finissent généralement à environ 16 ou 32 Mio par configuration, et ils sont assez compressibles.

Nous conservons des copies non compressées des fichiers binaires pendant une semaine pour en faciliter l’accès; après cela, nous ne conservons que la version légèrement compressée. Environ une fois par mois, nous avons un script qui extrait chaque fichier .zip généré par le processus de construction et 7-zips tout un mois de sorties de construction (ce qui permet d’avoir de petites différences par construction).

Une journée moyenne peut comporter une douzaine ou deux versions par projet ... Le buildserver se réveille toutes les 5 minutes environ pour rechercher les différences et les versions pertinentes. Un plein .7z sur un grand projet très actif pendant un mois pourrait être de 7-10GiB, mais il est certainement abordable.

Pour l’essentiel, nous avons pu diagnostiquer tout de cette façon. Parfois, il y a un problème sur le système de construction et un fichier n'est pas la révision qu'il est censé être lors de la construction, mais il y a généralement suffisamment de preuves de cela dans les journaux. Parfois, nous devons extraire un outil qui comprend le format de la base de données de débogage et lui donner quelques adresses pour diagnostiquer un incident (nous avons des empilements de pile automatiques intégrés au produit). Mais généralement, toutes les informations nécessaires sont là.

Nous n'avons pas encore eu à déchiffrer les archives .7z, pour ne citer que celles-là. Mais nous avons les informations ici et j’ai des idées intéressantes sur la façon d’exploiter des données utiles.

Enregistrez ce qui ne peut pas être reproduit facilement. Je travaille sur des FPGA où seule l'équipe FPGA dispose des outils et où certains cœurs (bibliothèques) de la conception sont autorisés à être compilés sur une seule machine. Nous sauvegardons donc les trains de bits de sortie. Mais essayez de les vérifier les uns sur les autres plutôt qu’avec un tampon de date / heure / version.

Enregistrer sous dans le contrôle de code source ou simplement sur le disque? Ne rien enregistrer dans le contrôle de code source. Tous les fichiers dérivés doivent être visibles dans le système de fichiers et mis à la disposition des développeurs. Ne pas archiver les fichiers binaires, le code généré à partir de fichiers XML, les résumés de messages, etc. Une étape de conditionnement distincte rendra ces produits finaux disponibles. Comme vous avez le numéro de modification, vous pouvez toujours reproduire la construction si nécessaire, en supposant bien sûr que tout ce dont vous avez besoin pour faire une construction soit complètement dans l’arbre et soit disponible pour toutes les générations par la synchronisation.

Je voudrais sauvegarder vos fichiers binaires construits exactement tant qu'ils ont la possibilité d'entrer en production ou d'être utilisés par une autre équipe (comme un groupe d'assurance qualité). Une fois que quelque chose a quitté la production, ce que vous faites avec cela peut varier beaucoup. Pour beaucoup d’équipes, elles ne conservent que leur version la plus récente (pour l’invalidation) et rejettent leurs versions.

D'autres ont des exigences réglementaires pour conserver tout ce qui a été produit jusqu'à sept ans (banques). Si vous êtes une entreprise productrice de produits, je garderai tout binaire installé par un client au cas où un technicien du support technique souhaiterait installer la même version.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow