Contrôle de Version pour Smalltalk / Seaside?
je suis principalement un développeur Java EE. On m'a demandé d'explorer la possibilité d'utiliser Smalltalk / Seaside dans un projet web à venir. Comme vous pouvez l'imaginer, cela a conduit à beaucoup de questions intéressantes.
comment une équipe de développeurs implémente-t-elle le contrôle de version et de révision des logiciels avec Smalltalk / Seaside? Pouvez-vous utiliser Subversion ou Git?
D'après ce que j'ai compris, Smalltalk utilise une image plutôt que de sauvegarder chaque classe dans son propre fichier. Comment est-ce que affecter la capacité de gérer les révisions du code source, particulièrement au sein d'une équipe?
Merci beaucoup pour tout ce que vous pouvez fournir!
7 réponses
Installation Pharo (et pierre précieuse)
chaque développeur travaille à son image. Chaque changement d'une méthode est enregistré localement dans le fichier changes. Cela permet de récupérer lors d'un crash de l'image. Les propagations sont faites en créant un monticello fichier ayant un nom de paquet, le numéro de séquence et le nom du développeur. Il sait que son ascendance. Ce fichier est enregistré dans un WebDAV le serveur. Ici, il est ramassé par un Jenkins tâche. Cela exécute l'unité et les tests d'intégration et crée de nouvelles images, de sorte que les développeurs peuvent commencer avec une nouvelle image (au moins) tous les jours. Voici quelques détails sur fusion à l'aide de monticello. La composition du produit (structure du paquet) est un autre fichier monticello contenant un metacello description. Cela permet également de se développer sur Pharo et de se déployer sur Gemstone. De temps en temps, vous devez ajouter des migrations de classe.
Pour non smalltalk dépendances et de développement, de test d'acceptation et de production des différences, ajouter la création d'images à l'aide de virtualbox vagabondant, chef-solo (ou marionnette, je l'espère bientôt Corail), veewee. Ils sont bien sûr gérés en version git.
en plus d'utiliser des outils de contrôle de la qualité statiques ( smallLint, vérifie également les différences entre les dialectes smalltalk), ajouter orignal et créer vos propres visualisations dynamiques du projet en fonction du contexte (humane évaluation)
VisualWorks Smalltalk le développeur local utilise STORE avec une base de données relationnelle (par exemple PostgreSQL) pour stocker les propagations locales. Le code est organisé en paquets de paquets, avec des espaces de noms. Un script de réplication est utilisé pour copier les versions locales vers et à partir d'une base de données centrale. De là, le flux est le même qu'avec Le Pharo configuration.
[mise à jour] à Esug2012, Dale Henrichs a présenté des travaux pour rendre possible l'utilisation de git et github pour gérer le code smalltalk pour plusieurs dialectes. Fondamentalement, une structure de fichier a été définie (Cyprès STIG pour VisualWorks) pour stocker les méthodes smalltalk dans les répertoires. Il s'agit davantage d'échanger du code entre dialectes que de remplacer le SCM natif.
brève réponse: vous ne pouvez pas (pour l'instant) utiliser Git ou Subversion.
Encore plus courte réponse: vous n'en avez pas besoin :)
grande réponse: Voir L'explication de Stephan sur la façon dont Pharo lui-même est créé :)) Bien sûr, si vous êtes habitué aux systèmes de fichiers, ce sera étrange en premier lieu, mais une fois que vous commencerez à travailler, vous vous rendrez compte que vous avez tous les outils dont vous avez besoin pour le contrôle de version (monticello –c'est le remplacement pour Git/Subversion), et pour créer des installations (metacello-c'est le remplacement pour des choses comme maven). Avec un peu de travail (comme toujours et avec n'importe quelle plate-forme que vous choisissez), vous pouvez configurer votre propre serveur d'intégration continue (jenkins ou hudson ou autre) et bientôt vous travaillerez en équipe comme dans d'autres environnements, mais avec un grand plus: vous développerez Seaside/Smalltalk :P
il y a quelques outils pour Svn/Git, mais IMHO il est beaucoup mieux d'aller avec le flux ici et d'utiliser Monticello parce que Monticello vous donne une expérience très similaire que git fait, mais beaucoup plus simple à utiliser et beaucoup plus intégré avec le "Smalltalk way".
vous n'avez pas précisé quel Smalltalk, mais si vous allez utiliser Pharo il est certainement Monticello (et quand les choses deviennent compliquées - Metacello sur le dessus) à utiliser.
Smalltalk possède ses propres systèmes d'empaquetage / versioning, où les paquets de code source sont sous contrôle, fragmentés, fusionnés, etc. Quels dialectes de Smalltalk prévoyez-vous d'utiliser? Pharo a Monticello et Metacello, Squeak a Monticello, VisualWorks a un magasin.
le développement dans Smalltalk est généralement plus productif - mais vous devez d'abord vous familiariser avec de nouveaux outils: Monticello/Metacello pour le packaging (pensez-y comme sauver un paquet dans un propre fichier ZIP avec extension mcz et un numéro de version propre à chaque fois que vous vous engagez). Metacello fournit les informations avec lesquelles les paquets Monticello s'emboîtent et doivent être chargés pour fournir une application complète (similaire à POM's dans Maven, mais dans une configuration de fichier de classe spécifique de Xxxx où XXX est le nom des composants). Vous n'avez pas besoin d'outils de version non Smalltalk comme subversion, sauf si vous voulez gérer des ressources externes comme des images ou des scripts de base de données.
regardez aussi L'intégration de Hudson/Jenking puisque cela vous aidera aussi à automatiser la construction d'image et l'intégration continue.
quel que soit le petit discours que vous choisissez, je pense que vous aimerez vraiment le bord de mer.