Contrôle de version pour Smalltalk / Seaside ?

Question

Je suis principalement un développeur Java EE. On m'a demandé d'étudier la possibilité d'utiliser Smalltalk / Seaside dans un projet Web à venir. Comme vous pouvez l'imaginer, cela a donné lieu à de nombreuses questions intéressantes.

Comment une équipe de développeurs met-elle en œuvre le contrôle des versions et des révisions de logiciels avec Smalltalk / Seaside. Peut-on 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 cela affecte-t-il la capacité à gérer les révisions du code source, notamment au sein d'une équipe ?

Merci beaucoup pour toute information que vous pourrez nous fournir !

Answer 1

Mise en place pour Pharo (et Pierre précieuse )

Chaque développeur travaille à son image. Chaque modification qu'il apporte à une méthode est enregistrée localement dans le fichier de modifications. Cela permet de récupérer en cas de plantage de l'image. Les commits sont faits en créant un monticello ayant un nom de paquet, un numéro de séquence et le nom du développeur. Il connaît son ascendance. Ce fichier est enregistré dans un WebDAV serveur. Ici, il est récupéré par un Tâche de Jenkins . Il exécute les tests unitaires et d'intégration et crée de nouvelles images, de sorte que les développeurs peuvent commencer avec une image fraîche (au moins) chaque jour. Voici quelques détails sur fusionner utiliser monticello. La composition du produit (structure du paquet) est un autre fichier monticello contenant un metacello description. Cela permet également de développer sur Pharo et de déployer sur Gemstone. De temps en temps, vous devez ajouter des migrations de classes.

Pour les dépendances non-smalltalk et les différences de développement, d'acceptation de test et de production, ajoutez la création d'images virtualbox à l'aide de vagabondage , chef-solo (ou marionnette espérons-le, bientôt Coral ), veewee . Ils sont bien sûr gérés par version en utilisant git.

Outre l'utilisation d'outils de contrôle statique de la qualité du code ( smallLint qui vérifie également les différences entre les dialectes smalltalk), ajoutez Orignal et créer vos propres visualisations dynamiques du projet en fonction du contexte (évaluation humaine)

Sur VisualWorks Smalltalk le développeur local utilise STORE avec une base de données relationnelle (par exemple PostgreSQL) pour stocker les commits locaux. Le code est organisé en paquets, avec des espaces de noms. Un script de réplication est utilisé pour copier les versions locales vers et depuis une base de données centrale. A partir de là, le flux est le même qu'avec la configuration Pharo.

[mise à jour] À Esug2012, Dale Henrichs a présenté des travaux permettant d'utiliser git et github pour gérer le code smalltalk pour plusieurs dialectes. En gros, une structure de fichiers a été définie ( Cypress pour Amber, Gemstone, Pharo, Squeak, VisualAge, STIG pour VisualWorks) pour stocker les méthodes smalltalk dans des répertoires. Il est actuellement destiné à l'échange de code entre dialectes plutôt qu'à remplacer le SCM natif.

Answer 2

Réponse courte : vous ne pouvez pas (pour l'instant) utiliser Git ou Subversion.

Réponse encore plus courte : 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é à des systèmes basés sur des fichiers, cela sera étrange au premier abord, mais une fois que vous commencerez à travailler, vous réaliserez que vous avez tous les outils dont vous avez besoin pour le contrôle de version (monticello -c'est le remplacement de Git/Subversion), et pour créer des installations complexes (metacello -c'est le remplacement de choses comme maven). Avec un peu de travail (comme toujours et avec n'importe quelle plateforme que vous choisissez), vous pouvez installer 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 gros plus : vous développerez Seaside/Smalltalk :P

Answer 3

Il existe des outils pour Svn/Git, mais je pense qu'il est préférable de suivre le courant et d'utiliser Monticello, car Monticello offre une expérience très similaire à celle de git, mais beaucoup plus simple à utiliser et beaucoup plus intégrée à la "méthode Smalltalk".

Vous n'avez pas précisé de quel Smalltalk il s'agissait, mais si vous utilisez Pharo, il faut absolument utiliser Monticello (et lorsque les choses se compliquent, Metacello par-dessus).

Answer 4

Smalltalk possède ses propres systèmes de packaging / versioning, où les paquets de code source sont sous contrôle, divisés, fusionnés, etc. Quels dialectes de Smalltalk prévoyez-vous d'utiliser ? Pharo a Monticello et Metacello, Squeak a Monticello, VisualWorks a STORE.

Answer 5

Le développement en Smalltalk est généralement plus productif, mais il faut d'abord apprendre à utiliser de nouveaux outils : Monticello/Metacello pour l'empaquetage (pensez-y comme à la sauvegarde d'un paquet dans un fichier ZIP propre avec une extension mcz et un numéro de version propre à chaque fois que vous livrez). Metacello fournit les informations sur les paquets Monticello qui s'assemblent et doivent être chargés pour fournir une application complète et fonctionnelle (similaire aux POM dans Maven, mais dans un fichier de classe spécifique ConfigurationOfXXX où XXX est le nom du composant). Vous n'avez pas besoin d'outils de gestion des versions non-Smalltalk comme subversion, sauf si vous souhaitez gérer des ressources externes comme des images ou des scripts de base de données.

Regardez également l'intégration Hudson/Jenking, qui vous aidera à automatiser la création d'images et l'intégration continue.