J'aimerais obtenir des commentaires sur cette idée, car je peux voir les avantages et les inconvénients de chaque approche. En tant que développeur Java, il s'agirait de stocker des fichiers JAR dans le référentiel de code, mais cela pourrait facilement s'étendre à d'autres langues compilées.
Avantages:
contre:
11 Réponses :
Nous archivons vers une structure de répertoire et étiquetez les versions appropriées dans le contrôle de la source. Cela nous donne accès aux versions construites et à la source qui les a générées.
Ceci est facilement effectué à l'aide de scripts de construction pour automatiser le marquage et l'archivage des constructions de libération.
+1 - Yup, c'est ce que nous faisons aussi. Bâties de version complète qui ont passé tous les tests et tout est archivé par notre serveur de construction d'intégration continue sur un "serveur de libération" dans un partage sur disque
+1 Souvent, les seules sorties à maintenir sont celles qui sont réellement libérées. Les autres peuvent être tenus pendant quelques semaines, mais ont ensuite supprimé de faire de la place, car ils peuvent toujours être recréés. De toute façon, les sorties n'appartiennent pas au contrôle de la source.
+1 Cela a le plus de sens. Le contrôle source devrait "en théorie" être en mesure de recréer la construction, mais si les outils changent, il est logique de disposer d'un emplacement parallèle avec les fichiers binaires réels.
@Nick: C'est plus que d'essayer de garder les choses propres. Si vous stockez à la fois la sortie et l'entrée, cela devient possible (par conséquent, éventuellement réel) que les deux ne correspondent pas. Ensuite, vous avez fini d'expédier quelque chose que vous ne pouvez pas reconstruire et ne connaissez donc pas le contenu de.
compromis: stockez les outils et le code source dans le référentiel et les bâtiments. De cette façon, vous pouvez toujours recréer n'importe quelle construction d'un produit.
Et vous pouvez toujours avoir un référentiel séparé pour les artefacts compilés.
Je pense que c'est un bon compromis. Cependant, je suis aussi un peu paranoïaque sur les outils plus anciens ne fonctionnant plus à un moment donné à l'avenir.
@Jin Kim: En supposant que vous conserviez également les versions sur un serveur FTP ou l'équivalent, cela ne devrait pas vous préoccuper.
mettre des communiqués de clients spécifiques dans le référentiel.
En théorie, ce n'est pas nécessaire car nous pourrions toujours reproduire cette version, mais il est agréable de pouvoir simplement obtenir l'exact .msi qui a été envoyé à un certain client à une certaine date - nous testons ensuite cela dans un VM propre.
Une des raisons est que cela vous protège contre toute modification en dehors de votre environnement de construction de Say Windows ou Visual Studio Mise à jour. Vous ne pourrez peut-être pas reproduire une construction bit-bit d'un MSI si MSI lui-même a mis à jour!
J'aurais tendance à ne pas être d'accord avec cela - je préférerais savoir que je peux construire de tout point abriarary une réplique exacte de ce qui a été envoyé. Parce que, selon les humains impliqués, que .msi pourrait ne pas être reproductible dans la pratique. Cela pourrait être une construction unique de certains développeurs qui a oublié de vérifier ses modifications et est donc "sans soutien". Faites toujours confiance à votre processus de construction pour le faire correctement, et si vous ne pouvez pas, vous avez quelque chose que vous devez corriger.
Vous attendez-vous à ce qu'un MSI reconstruit diffère de quelque manière que ce soit? Je ne veux pas dire fonctionnellement, mais au niveau du bit-for-for-bit.
Je pense qu'il convient de stocker une sortie de construction dans le système de contrôle de la version. Les deux pour tester une version spécifique d'une construction et également pour faciliter certaines tâches de développement.
Cependant, vous devez vous assurer que vous gardez également tout dans le référentiel qui serait nécessaire pour recréer cette construction exacte si nécessaire. Vous devez utiliser le marquage / étiquetage de Consitent afin de faciliter cela. Vous devrez peut-être tester une solution de bogue avec différentes versions de divers composants et, en fonction de la complexité de votre système global, vous pouvez essayer différentes combinaisons.
Je ne vois aucun avantage à encombrer le système de contrôle source avec la sortie.
Cela dépend beaucoup de votre environnement et de votre taille d'équipe. Dans de grands projets avec des outillages complexes, tout la compilation de zéro simplement parce que vous avez besoin de la version de certains composants n'est pas toujours réalisable. Faites votre propre jugement.
Nous allons faire l'étiquetion du référentiel pour n'importe quelle version afin que nous puissions obtenir la source réelle pour tout numéro de construction et ensuite que nous ayons zip et télécharger les fichiers de construction publiés réels réellement déployés - Juste pour être sûr qu'il n'y a pas de peau de dernière minute sournois etc pendant le déploiement qui ne sont pas reflétés dans le coffre lui-même.
Si vous pouvez créer un système de construction assez bon qu'il est trivial pour recréer une construction exacte avec juste une caisse de code, je ne crois pas qu'il y ait besoin de stocker vos constructions dans le référentiel.
Pour la plupart de mes affaires, je ne stocke pas de constructions spécifiques de mon code, mais je stocke des versions spécifiques des bibliothèques que mon code repose sur. Il y a quelques mois, je mets beaucoup d'efforts pour le rendre trivial à charger dans une étiquette et de type "fourmi" et tout construit correctement sans s'appuyer sur quoi que ce soit en dehors de l'arbre. (à l'exclusion du bon Javac et de la fourmi)
Malheureusement, une partie de notre codeBase n'a pas de bon système de construction (c.-à-d. Nécessite la mise en place manuelle de SDKS et saisir diverses bibliothèques externes et des variables d'environnement de poking) et il serait difficile de recréer exactement une version spécifique d'une construction. Basé sur le référentiel (nous avançons constamment de l'avant et ne sortons pas vraiment de l'ancien code, le poste de travail des développeurs est donc mis en place suffisamment près que nous n'avons pas encore été brûlé en devant retourner dans une ancienne branche avant notre sortie actuelle) et Dans ce cas, nous stockons les constructions de notre libération (pour le doigt gras inévitable "Oh non, j'étais sur le mauvais serveur faisant des tests" ou quelque chose de tout aussi insidieux).
+1. Tout ce qui ne peut être créé dans le processus de construction à partir d'autres intrants doit lui-même être considéré comme une entrée. Il est donc correct d'enregistrer dans les bibliothèques tiers, voire des héritage dont la construction ne peut pas être automatisée.
Parfois. La plupart du temps, la réponse est aucun mais il y a toujours des scénarios où si cela a du sens, le faire.
Comme à l'écart, je suis surpris que cela soit toujours ouvert. Ces questions de type de discussion sont généralement votées fermées en moins de 5 minutes.
Les nazis de fermeture doivent être dans un autre fuseau horaire et encore endormis.
Ce n'est pas une discussion vague sur une question subjective, c'est une question de pratiques optimales.
Je ne pense pas qu'il y ait une bonne raison de la version la construction réelle. Étiquetez la version source et faites-la pour que seul un groupe contrôlé ait accès à la modification des balises. Une étiquette de construction ne doit jamais avoir une vérification à laquelle elle devrait donc être triviale pour recréer la construction.
Je stocke les constructions sur un dossier sur le serveur et ils sont sauvegardés régulièrement. Mais je balise la révision qui représente cette construction. Dans le dossier de construction, je stocke non seulement les exécutables, les fichiers binaires ou pages (notre cas est ASP.NET), mais également les scripts de changement que nous recevons de SQL Delta.
Les balises sont nommées avec le même identifiant que les champs, donc si vous avez la version "System_2009-07-30-01", vous aurez une étiquette avec ce nom. Donc, si vous avez besoin de réparer quelque chose, vous regardez simplement le nom de construction, regardez la balise, puis regardez la révision dont vous avez besoin pour voir ce qui peut se passer.
Pour atténuer la préoccupation selon laquelle les anciens outils de construction peuvent ne pas fonctionner dans un environnement plus récent, nous archivons nos images de machines de construction pour des versions majeures. Il est facile de faire pour nous parce que nos machines de construction sont virtualisées. Il est plan b au cas où d'autres moyens ne fonctionnent pas.
Je pense que les sources, les dépendances, les fichiers binaires et les outils de construction devraient être les vidéos ensemble ... C'est le seul moyen de suivre ce qui se passe avec les grands projets où la libération finale provient de nombreux projets sources ...
Oui, définitivement bloquez votre référentiel. IMO, le référentiel source est juste que - pour source de quelque nature que ce soit, mais pas pour la sortie des constructions à la fin. Mais c'est juste mon opinion