Notre produit logiciel est composé de nombreuses parties. Disons qu'il est fait d'une partie de pilote de noyau, d'un dll utilisateur et d'un logiciel d'interface graphique. Pendant le développement, nous nous compilons et utilisons toutes les dernières versions, mais ce n'est pas la même chose en ce qui concerne la libération.
En effet, la partie du noyau doit être gelée beaucoup plus tôt que l'autre. Ensuite, la DLL est gelée, pour être minutieusement testée et la dernière gelée est l'interface graphique. AS QA ADVANCES, nous devons créer de nouvelles versions de la version complète avec une interface graphique fixe, mais toujours en utilisant le pilote de noyau précédemment inclus et la DLL.
Je me demandais s'il y avait un outil existant, qui gérerait quelle version de chaque partie logicielle est utilisée pour créer une version?
Cet outil s'intègre éventuellement à la chaîne d'outils pour créer la version de chaque logiciel sélectionné et les rassembler dans un programme d'installation Windows ou Linux.
Dès présent, nous utilisons SVN avec Buildbot en tant qu'outil CI sur Linux / GCC et Windows / Vstudio. Nous sommes en mode où l'ensemble du référentiel est ramifié / étiqueté au besoin. Mais cela fait mal et fait du processus de libération douloureux maintenant qu'il existe de plus en plus de pièces logicielles relativement indépendantes.
Nous pensons à modifier la disposition du référentiel pour avoir plusieurs projets sélectionnés de manière indépendante / marquée. Ce serait bien mieux adapté au cycle de développement et de libération logiciels. Mais alors, nous aurions absolument besoin d'un tel outil.
Le problème est lié à avoir différentes pièces de logiciel, chacune avec leurs propres versions ramifiées / marquées, recueillies dans une version complète du logiciel.
EDIT : Quel est nécessaire.
En fin de compte, j'ai compris ce que j'ai besoin est un gestionnaire de paquets pour Windows. Gestionnaire de paquets dans le sens de RPM ou de Deb Manager sur Linux.
Quelqu'un peut-il connaître un gestionnaire de paquets sur Windows?
6 Réponses :
Un outil que j'ai joué avec est Maven , il est très intéressant de la manière dont il dispose les divers cycle de vie. Vous pouvez utiliser non seulement pour les projets Java, mais également .net, ainsi que de nombreux plugins, ainsi que de bons référentiels (j'utilise celui de sonatype ).
Je pense que le terme que vous recherchez est gestion de la configuration logicielle . Il y a un joli document lourd à ce sujet ici aussi: http://www.sei.cmu.edu /reports/87cm004.pdf .
Merci, j'ai regardé cela, mais cela semble trop large. Par exemple SCM inclut le contrôle de la source. D'après ce que je pense maintenant, j'ai besoin de quelque chose qui est derrière le contrôle de la source.
La chose la plus évidente que vous avez est le problème des dépendances entre ces différentes parties du logiciel (comme le noyau 1.0, le pilote A 1.1 etc.). Cela me donnera l'impression que vous devez réfléchir à votre outil de construction s'il est capable de gérer des dépendances qui ne ressemblent pas à cela. Donc, vous devriez jeter un oeil à Maven (déjà mentionné), Scons (je ne suis pas sûr) ou d'autres outils comme ANT en combinaison avec Ivy. Vous devez définir une sorte de base qui décrit les modules dans lesquels la version fonctionne ensemble et peut être libérée. Ceci est méta-information qui devrait être géré par l'outil de construction. Vous pouvez créer quelque chose par vous-même ... mais je ne recommande pas de le faire.
Nous avons un système où "tronc" est ce qui est en production. Nous créons une succursale pour la prochaine version, lorsqu'un développeur obtient ses modifications pour un problème, il les vérifie dans notre gestionnaire de sortie et associe ces fichiers modifiés avec ce numéro de numéro ou ID de bogue.
Lorsque nous allons construire, nous pouvons retenir tous les changements d'achat d'un problème n'incluant pas ce problème dans notre construction. Lorsque nous réduisons la succursale, nous pouvons voir tous les fichiers changeants mais non inclus dans la dernière version - nous les excluons de l'effondrement.
L'autre belle partie de ce système est qu'il faut tous les scripts SQL et les combine (intelligemment) dans 1 gros fichier SQL utilisé pour promouvoir la libération pour tester, qa puis prod.
plus peut être trouvé ici.
Pour gérer votre source, vous souhaitez absolument ramper vos composants individuellement. Les fichiers binaires sont géré via un Gestionnaire de packages . Les meilleures pratiques pour cela vont varier en fonction de votre système d'exploitation cible. Mon entreprise fait des logiciels intégrés, nous la gérons donc avec des scripts personnalisés que nous avons conçus. Sur Linux, vous voulez faire des packages .deb ou .RPM. Voici Guide pour Ubuntu. Je ne connais pas très bien avec Windows, mais InstallShield est un choix populaire dans le logiciel I ' ve installée.
Ils devraient tous avoir des mécanismes permettant de spécifier des gammes de versions de dépendances. Vous pouvez avoir besoin d'une version exacte, d'une certaine version ou de plus récente, ou quoi que ce soit entre deux versions. Ensuite, vous avez un package "parent" qui n'a pas de binaires, mais spécifie simplement les versions des packages de composants. Cela vous permettra de mettre à niveau un composant tout en conservant les fichiers binaires pour les autres composants. Si vous voulez tout garder dans un paquet, il n'ya que peu de raisons de ne pas reconstruire la totalité de la source. Si vos scripts de construction sont contrôlés de version, vos fichiers binaires seront les mêmes.
C'est vraiment bon. Merci. Maintenant, imaginez que je souhaite utiliser le "noyau 0,1" des fichiers binaires produits pour sr-0.1 dans SR-0.2 .
Merci beaucoup. Je produit déjà des packages deb et RPM, mais les fichats Linux sont créés après les fichiers binaires Windows, et ce sont les fichiers binaires Windows qui sont minutieusement testés à l'avance. Notre point difficile est que le package Windows contient des fichiers binaires de la source et des documents pouvant être prêts ultérieurement, une fois que les binaires sont testés. Nous devons donc créer de nouveaux forfaits avec de vieux binaires. Un peu compliqué, je sais.
Nous utilisions utilisais une utilisation Buckminster pour gérer le niveau d'intégration du déploiement du logiciel, malheureusement a cessé d'être soutenu il y a quelque temps, et nous avons maintenant terminé notre déménagement à l'aide de Maven .
Le reste de ma réponse n'a pas été touché mais reste ici pour référence.
Nous avons divers référentiels de code (internes de son Page d'aperçu technique :
Buckminster est un cadre de résolution et de matérialisation des composants. Son but est d'obtenir des composants logiciels pour vous et de les matérialiser dans un contexte de choix, typiquement un espace de travail ou un système de fichiers. Ceci s'applique si vous examinez ce qui est disponible sur votre machine locale, dans votre organisation de développement ou dans le cloud public Open Source. Buckminster supprime l'ambiguïté des descriptions de composants, permet de partager des composants et d'accroître la productivité lorsqu'il est appliqué dans le développement, la construction, l'assemblage et le déploiement de scénarios.
Buckminster est une méta-cadre extensible, comprenant une langue de métadonnées composant et une heure d'exécution, qui peut exécuter soit sans tête, soit sous forme de plug-in dans l'Eclipse IDE. Bien que Buckminster puisse être utilisé pour résoudre des problèmes communs, assembler et déployer des problèmes, ce n'est pas un système de gestion de construction ou de composant en soi. Buckminster peut réutiliser les investissements existants dans une large gamme d'outils de gestion de la construction et de la source - Maven, fourmi, CVS, SVN, PDE, etc. - et est conçu pour placer le moins de restrictions possible sur les services que ces outils externes peuvent fournir.
Utiliser Buckminster Je peux déployer, en une étape, toute version majeure de notre logiciel, ainsi que la configuration spécifique de l'un de mes clients.
git et svn des références et références à des bibliothèques externes et de références, telles que PYDEV ) et il les retire bien ensemble, déploiement uniquement les composants nécessaires à une construction donnée.
J'ai vu cela traduit par la vérification de la version avec des outils d'intégration continue appropriés et des scripts de construction. Qu'utilisez-vous actuellement pour construire votre système?
@THOMASEWENS: répondit à la modification de la question.
Merci. Laissez-moi penser à cela un peu. Je vais essayer de répondre lorsque j'ai une réponse et quelques cycles de rechange.
Une façon dont je l'ai déjà vue, sur un niveau technique dans SVN, est de créer un "métaparactérien" qui est juste une collection d'externes aux différents composants. En modifiant les externes à pointer à la bonne révision, à la balise ou à la branche, puis marquez également le métapositoire, vous disposez d'un instantané de cette configuration dans SVN.