version-control - tipos - git version control
¿Control de versión para Smalltalk/Seaside? (7)
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 de 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!
Configuración para Pharo (y Gemstone )
Cada desarrollador trabaja a 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 compromisos se realizan al crear 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 una tarea de Jenkins . 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 la merging usando monticello. La composición del producto (estructura del paquete) es otro archivo de metacello contiene una descripción del metacello . Esto también permite desarrollar en Pharo y desplegar en Gemstone. De vez en cuando necesita agregar migraciones de clase.
Para las dependencias y el desarrollo de non-smalltalk, la aceptación de pruebas y las diferencias de producción, agregue la creación de imágenes de la caja virtual usando vagrant , chef-solo (o puppet , esperemos que pronto Coral ), veewee . Por supuesto, son versiones administradas usando git.
Además de usar herramientas de control de calidad de código estáticas ( smallLint , también verifica las diferencias entre los dialectos de Smalltalk), agregue Moose y cree sus propias visualizaciones dinámicas dependientes del contexto del proyecto (evaluación humanitaria)
En VisualWorks Smalltalk, el desarrollador 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.
El desarrollo en Smalltalk suele ser más productivo, pero primero debe aprender sobre nuevas herramientas: Monticello / Metacello para el empaque (piense en guardar un paquete en un archivo ZIP con la extensión mcz 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 control de versiones que no sean Smalltalk, como subversion, a menos que desee administrar recursos externos como imágenes o scripts de bases de datos.
También mire 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.
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 la "manera Smalltalk". ".
No especificó qué Smalltalk, pero si va a usar Pharo, definitivamente es Monticello (y cuando las cosas se complican, Metacello en la parte superior) para usar.
Respuesta corta: no puede (por ahora) usar Git o Subversion.
Respuesta aún más corta: no la necesitas :)
Respuesta grande: vea la explicación de Stephan sobre cómo se crea Pharo it self :)) Por supuesto, si está acostumbrado a sistemas basados en archivos, esto será extraño en primera instancia, pero una vez que comience a trabajar, se dará cuenta de que tiene todo el herramientas que necesita para el control de versiones (monticello -este es el reemplazo de Git / Subversion), y para crear instalaciones complejas (metacello; este 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: lo hará Desarrollar Seaside / Smalltalk: P
Smalltalk tiene sus propios sistemas de empaquetamiento / control de versiones, donde los paquetes de código fuente están bajo control, divididos, fusionados, etc. ¿Qué dialectos de Smalltalk planea usar? Pharo tiene Monticello y Metacello, Squeak tiene Monticello, VisualWorks tiene TIENDA.
También puedes estar interesado en Amber .
VA Smalltalk tiene Envy .
Cualquiera que sea Smalltalk que elija, creo que realmente le gustará Seaside.