¿Control de versión para Smalltalk/Seaside?

Question

Soy principalmente un desarrollador de Java EE. Me han pedido que explore la posibilidad de utilizar Smalltalk/Seaside en un próximo proyecto web. Como se puede imaginar, esto ha llevado a muchas preguntas interesantes.

¿Cómo implementa un equipo de desarrolladores la versión del software y el control de revisiones con Smalltalk/Seaside? ¿Puedes usar Subversion o Git?

Por lo que entiendo, Smalltalk usa una imagen en lugar de guardar cada clase en su propio archivo. ¿Cómo afecta eso la capacidad de administrar las revisiones del código fuente, particularmente en un equipo?

¡Muchas gracias por cualquier idea que pueda proporcionar!

Answer 1

instalación de Pharo (y Gemstone)

Cada desarrollador trabaja en su propia imagen. Cada cambio en un método que hace se guarda localmente en el archivo de cambios. Esto permite recuperar cuando se cuelga la imagen. Los commits se realizan creando un archivo monticello, que tiene un nombre de paquete, un número de secuencia y el nombre del desarrollador. Conoce su ascendencia. Este archivo se guarda en un servidor WebDAV. Aquí lo recoge un Jenkins task. Esto ejecuta la unidad y las pruebas de integración y crea nuevas imágenes, por lo que los desarrolladores pueden comenzar con una imagen nueva (al menos) todos los días. Aquí hay algunos detalles sobre merging usando monticello. La composición del producto (estructura del paquete) es otro archivo de Monticello que contiene una descripción metacello. Esto también permite desarrollar en Pharo y desplegar en Gemstone. De vez en cuando necesita agregar migraciones de clase.

Para dependencias no Smalltalk y el desarrollo, prueba de aceptación y las diferencias de producción, añadir la creación de imágenes de VirtualBox utilizando vagrant, chef-solo (o puppet, espero que pronto Coral), veewee. Por supuesto, son versiones administradas usando git.

Además de utilizar herramientas de control de calidad de código estático (smallLint, también comprueba las diferencias entre los dialectos de Smalltalk), añadir Moose y crear su propio contexto dependiente, visualizaciones dinámicas del proyecto (humane assessment)

En VisualWorks Smalltalk el promotor local usa STORE con una base de datos relacional (por ejemplo, PostgreSQL) para almacenar confirmaciones locales. El código está organizado en paquetes de paquetes, con espacios de nombres. Se utiliza una secuencia de comandos de replicación para copiar las versiones locales hacia y desde una base de datos central. A partir de ahí, el flujo es el mismo que con la configuración de Pharo.

[actualización] En Esug2012, Dale Henrichs presentó el trabajo para hacer posible el uso de git y github para administrar el código smalltalk para múltiples dialectos. Básicamente, se definió una estructura de archivos (Cypress para Amber, Gemstone, Pharo, Squeak, VisualAge, STIG para VisualWorks) para almacenar métodos smalltalk en directorios. En este momento, está dirigido más al intercambio de códigos entre dialectos que a un reemplazo del SCM nativo.

Answer 2

Smalltalk tiene sus propios sistemas de empaquetado/versionado, donde los paquetes de código fuente están bajo control, divididos, combinados, etc. ¿Qué dialectos Smalltalk planea usar? Pharo tiene Monticello y Metacello, Squeak tiene Monticello, VisualWorks tiene TIENDA.

Answer 3

VA Smalltalk tiene Envy.

Cualquiera que sea Smalltalk que elija, creo que realmente le gustará Seaside.

Answer 4

Respuesta corta: no puede (por ahora) usar Git o Subversion.

Incluso respuesta más corto: usted no lo necesita :)

respuesta Grande: Véase la explicación sobre cómo Stephan se crea Pharo si mismo :)) Por supuesto, si estás acostumbrado a los sistemas de archivos basados, este será extraño en primera instancia, pero una vez que empiece a trabajar, se dará cuenta de que tiene todas las herramientas que necesita para el control de versiones (monticello -este es el reemplazo de Git/Subversion) y para crear instalaciones complejas (metacello, esto es el reemplazo de cosas como maven). Con algo de trabajo (como siempre y con cualquier plataforma que elija), puede configurar su propio servidor de integración continua (jenkins o hudson o lo que sea) y pronto estará trabajando en equipo como en otros entornos, pero con una gran ventaja: usted desarrollará Seaside/Smalltalk: P

Answer 5

El desarrollo en Smalltalk suele ser más productivo, pero primero debe aprender sobre las nuevas herramientas: Monticello/Metacello para el empaquetado (piense en ello como guardar un paquete en un archivo ZIP propio con mcz extensión y un número de versión propio cada vez que se compromete). Metacello proporciona la información que encaja en los paquetes de Monticello y debe cargarse para proporcionar una aplicación de trabajo completa (similar a POM en Maven, pero en un archivo de clase específico ConfigurationOfXXX donde XXX es el nombre de los componentes). No necesita herramientas de versión de Smalltalk como subversion a menos que desee administrar recursos externos como imágenes o scripts de bases de datos.

También vea la integración de Hudson/Jenking, ya que esto también lo ayudará a automatizar la creación de imágenes y la integración continua.

Answer 6

Hay algunas herramientas para Svn/Git, pero en mi humilde opinión, es mucho mejor ir con el flujo aquí y usar Monticello porque Monticello te brinda una experiencia similar a la de git, pero mucho más simple de usar y mucho más integrada con el "modo Smalltalk".

No especificó qué Smalltalk, pero si va a utilizar Pharo, definitivamente es Monticello (y cuando las cosas se ponen complicadas, Metacello en la parte superior) para usar.

Answer 7

También puede interesarse en Amber.