Plastic SCM llega a su versión 2.9 y está listo para descargarse desde nuestra web: www.plasticscm.com.
La nueva versión viene cargada con un buen número de nuevas características y también es mucho más rápida, especialmente bajo carga.
Estas son algunas de las nuevas características:
Soporte de Oracle: hemos añadido Oracle a la lista de backends con los que PLlastic puede funcionar. Hasta ahora soportábamos MySql, SQL Server y Firebird (tanto servidor como embebido). Nos han pedido Oracle varias veces, especialmente desde grandes equipos así que por fin está disponible. Se trata posíblemente del gestor de bases de datos más conocido tanto por rendimiento como estabilidad y escalabilidad y puede usarse con servidores Plastic en Windows, Linux y MacOS X.
Integración continua con Pulse: hemos desarrollado un plugin para el producto de integración continua de Zutubi. Hasta ahora ya nos integrábamos con productos como CruiseControl y FinalBuilder, pero Pulse es quizá mi favorito y estamos trabajando en ampliar la integración para que soporte patrones como rama por tarea, y así poder implantarlo internamente. Otros sistemas, como Hudson, también funcionan con Plastic.
Servidor proxy: otra de las características más esperadas. Ahora se puede configurar un servidor proxy de Plastic para reducir el uso de red mientras se trabaja conectado a un servidor central. El servidor proxy es muy sencillo: símplemente descarga datos bajo demanda que le solicitan los clientes y los cachea para el siguiente uso. Con esto se ahorra uso de red lo que puede ser crítico cuando se acceede al servidor a través de VPN o conexiones lentas. Nota: Plastic puede funcionar en modo distribuido pero algunas empresas prefieren llevar ciertos proyectos de forma centralizada, y es ahí donde el proxy server juega un papel importante.
Sparse tree y cloaking: que se traduce por algo como árboles parciales y evitar que ciertos ficheros se actualicen. Mediante un nuevo fichero de configuración llamado cloaked.conf es posible definir reglas para indicar qué ficheros se pueden descargar y qué ficheros no, es algo complementario a lo que ya se puede hacer con los selectores, pero permite funcionalidades diferentes. Por ejemplo, se puede descargar un árbol de directorios y luego indicar que ese árbol está cloaked lo que quiere decir que no se volverá a actualizar. Es útil para mejorar el rendimiento cuando se trabaja con proyectos muy grandes. Sólo para usuarios avanzados.
Uso de memoria en la replicación. El uso de memoria en todo el proceso de replicación se ha reducido considerablemente, haciendo que el proceso sea mucho más rápido y eficiente que antes. Ahora se puede replicar un repositorio completo sin que el servidor se entere a nivel de uso de memoria!
¡Eliminación del workspace server! Sí, como leeéis, el hemos eliminado el componente servidor de workspaces del mapa. Bueno, de hecho no se ha ido sino que se ha trasladado a cada cliente, de modo que el rendimiento aumenta de forma espectacular. ¿Qué significa esto? Echa un vistazo a un nuevo workspace y verás que contiene un directorio (oculto) denominado .plastic. Contiene información sobre el workspace como el selector y el árbol de la copia de trabajo. Toda esa información solía estar en el servidor y ahora se ha movido al cliente, lo que supone que se reduce significativamente el uso de red, lo que podrán apreciar especialmente los usuarios de redes VPN (en LAN la velocidad ya era tan alta que no se apreciará mucha diferencia). Nota importante: cuando te actualices de Plastic 2.8 a 2.9 verás, en el primer arranque, un diálogo como el siguiente que indicará el progreso de la conversión de workspaces.
Workspaces compartidos: tras las modificaciones realizadas en los workspaces ahora se pueden compartir: se puede ubicar un espacio de trabajo en un directorio compartido (por Samba o por NFS, por ejemplo) de forma que más de un usuario pueda acceder a él e incluso actualizarlo y acceder a información de Plastic desde varias ubicaciones. Antes se podía hacer registrando el workspace en diferentes máquinas, pero se podía llegar fácilmente a condiciones en las que el sistema no se comportase bien porque para Plastic eran workspaces diferentes. Lógicamente es una característica para usar con cuidado: es útil para usarlo con sistemas de compilación, o de paso a producción, no para trabajar a diario ya que el objetivo de un control de versiones es precísamente coordinar diferentes copias de trabajo, ¡¡no trabajar sobre una misma!!
Exploración de changesets: una de las nuevas características más potentes. Ahora se puede caminar por las ramas cambio a cambio (changeset a changeset) leyendo la historia que cuentan. Escribiré otro post sobre esto pero para hacer una breve introducción: en tu propia rama de tarea eres libre de hacer tantos checkins como quieras, pero todos esos checkins deberían de tener un significado, ir describiendo cambios uno a uno, de modo que todos tengan una lógica. Supongamos que vamos a hacer un refactor importante, de muchos ficheros, si comparas el contenido de la rama una vez que has terminado verás tantísimos cambios que será difícil de entender lo que has hecho, sin embargo si has podido descomponer el refactor en pequeñas operaciones y has ido haciendo checkin de cada una de ellas, se podrá revisar posteriormente los cambios que has hecho, como si fuera ver una repetición de la jugada. El mecanismo de commit no es nuevo, por supuesto, pero la herramienta de recorrido de cambios permite que se usen para describir cambios casi contando cómo lo has ido haciendo, dejando registrado no sólo lo que haces sino cómo lo haces, con todas las aplicaciones que eso tiene.
Mejoras en el branch explorer: siempre en evolución, hemos añadido la capacidad de búsqueda que permite ir navegando las ramas que cumplan el filtro, lo que es mucho más útil que antes. También la posibilidad de hacer clic sobre los link de merge y ver de dónde vienen y hacia dónde van. Y por último el editor de visibilidad que tantas veces nos han pedido y que permite ocultar ramas que no interese ver.
Y estas son todas las funcionalidades importantes en 2.9 junto con un buen número de correcciones.
Y por supuesto mejoras de rendimiento: probamos Plastic cada semana en un cluster con 100 nodos y bajo esa carga 2.9 es un 30% más rápida que 2.8. Recordad que Plastic 2.8 era ya 10 veces más rápido que SVN... así que calculad 2.9!!
Y por supuesto a pesar de seguir creciendo Plastic es todavía fácil de usar y de instalar. Echad un vistazo al siguiente vídeo en el que se configura un servidor en menos de 45 segundos!! Y después se hace una importación inicial de código (algo que es muy común en cualquier evaluacion) durante el siguiente minuto!
0 comentarios:
Publicar un comentario