Repositorio de Mono en Plastic

14:37 1 Comments

Estamos trabajando en una sincronización de dos modos de Subversion con Plastic. Permitirá que los grupos de desarrollo que utilizan Subversion puedan migrar a Plastic poco a poco mientras continúan en sincronización con otras localizaciones que tardarán más en moverse a Plastic.

Como prueba estamos importando el repositorio de Mono. Nuestra intención es crear un sitio público en el cual tener proyectos de código libre con Plastic, y por supuesto, el primer repositorio que se va a replicar será el código base de Mono.

Aquí podéis encontrar algunas capturas de la importación preliminar que hemos estado haciendo hoy.
Esta es una vista de las etiquetas:




Ramas:



Un árbol de versiones del directorio de Mono:



Los últimos changesets que se importaron (por favor, tengan en cuenta que no estamos utilizando el último repositorio de SVN)


El explorador de ramas...



Y la vista de contenido de una rama:



Así que aún tardaremos un tiempo, pero espero que publiquemos un repositorio de Mono bastante pronto para que podáis ver las características de Plastic en un repositorio grande tan amplio como conocido.

1 comentarios:

Como configurar MySQL como backend en Plastic SCM 2.5

13:23 3 Comments

Es muy sencillo de configurar, tan sólo hay que crear (o editar) un fichero denominado 'db.conf' en el directorio de instalación del servidor.
El contenido de este fichero debe de ser el siguiente:

<dbconfig>
<providername>mysql</providername>
<connectionstring>Server=_SERVER_;UserID=_USER_;Password=_PASSWORD_;Database={0};Pooling=true</connectionstring>
<databasepath></databasepath>
</dbconfig>
cambiando los parámetros _SERVER_, _USER_ y _PASSWORD_ con los necesarios según la configuración del servidor que se quiera utilizar. Por ejemplo, un fichero with 'db.conf' ´válido para nuestro entorno de desarrollo sería:
<dbconfig>
<providername>mysql</providername>
<connectionstring>Server=venus;UserID=myuser;Password=mypwd;Database={0};Pooling=true</connectionstring>
<databasepath></databasepath>
</dbconfig>
Finalmente, debemos indicar que el parámetro de configuración de mysql max_allowed_packet soporte hasta 10MB. Para más información de cómo configurar este parámetro puede ver el siguiente artículo.

3 comentarios:

Cómo utilizar Plastic SCM y Bugzilla II

10:13 0 Comments

Como vimos en el post anterior de cómo utilzar Plastic SCM con la extensión de Bugzilla, hay dos opciones diferentes para trabajar con la extensión, dependiendo del patrón de trabajo que su empresa esté utilizando. En este post nos vamos a centrar en la opción de “Tarea en Changeset” (Task on Changeset), que utilizarán empresas que trabajen con el patrón de desarrollo en línea principal o en “rama por desarrollador”.
Para configurar la extensión con este método de trabajo hay que configurar el fichero “bugzillaextension.dll” de la misma manera que en el caso anterior, pero en este caso el fichero “bugzillaextension.conf” se configura de manera diferente, por lo que debe de tener la siguiente apariencia:

<BugzillaExtensionConfiguration>
<BugzillaBaseUrl>http://192.168.1.14:8888/bugzilla/
3.0/</BugzillaBaseUrl>
<BranchPrefix>SCM</BranchPrefix>
<WorkingMode>TaskOnChangeset</WorkingMode>
</BugzillaExtensionConfiguration>

¡Y ya está listo para empezar a trabajar!
Como en el caso anterior, empezamos a trabajar creando una nueva tarea en Bugzilla que se asigna al desarrollador denominado “tester”, se deja la tarea en estado de asignada:

En este caso podemos ver que el número de defecto asignado es el 14, tenemos más defectos creados, así que podemos ver la lista de defectos utilizando la herramienta de búsqueda de Bugzilla:

Y como resultado de la búsqueda obtenemos el listado de defectos con estado nuevo, asignado, reabierto o resuelto, como hemos indicado en la búsqueda, y entre ellos encontramos el defecto que acabamos de añadir, con número de identificación 14:

Ahora pongámonos a trabajar y editar el fichero “assfile” como nos indica la tarea asignada: vamos a Plastic, desprotegemos el fichero, lo editamos con los cambios que tengamos que introducir en él y lo protegemos de nuevo: en este punto Plastic abrirá una nueva ventana en la que incluiremos la información de la protección; esta ventana tiene la siguiente apariencia:

En esta ventana el usuario puede incluir los comentarios de la operación de protección y enlazar dicha operación (changeset) con el defecto o defectos relacionados, ya que en la opción de “tarea en changeset” se pueden enlazar uno o más changesets a una o más tareas o defectos.
Si pinchamos en la opción de “Añadir nueva tarea” se abrirá otra ventana desde la cual podremos seleccionar el defecto que queramos enlazar, en este caso vamos a enlazar el defecto 14 como muestra la imagen:

¡Y ya lo tenemos enlazado!, si ahora vamos a la vista de changesets podemos encontrar información de los defectos de bugzilla enlazados a cada uno de los changesets, desde esta vista además podemos enlazar más defectos a un mismo changeset o borrar defectos que se hayan añadido previamente, y como en el caso del método de trabajo “tarea en rama”, podemos ir directamente a ese defecto en Bugzilla, hacer cambios en los defectos y cambiarlos en cualquier momento.

¡Espero que os guste!

0 comentarios:

Cómo utilizar Plastic SCM y Bugzilla I

10:10 0 Comments

Como probablemente habrá visto ya, Plastic SCM le ofrece la opción de utilizar el sistema de gestión de tareas de su elección ya que se integra totalmente con diversos sistemas del mercado, aquí podrá ver cuales son.
En este post intentaré explicar con un ejemplo cómo utilizar Plastic SCM integrado con uno de estos sistemas, Bugzilla…Lo primero aquí es tener en cuenta que Plastic SCM no sólo se integra con este sistema, sino que además ofrece diversas opciones de integración.
¿Por qué? Simplemente para ofrecer el método de trabajo más adecuado según el patrón de trabajo que utilice su empresa. En primer lugar en este post vamos a ver la opción de “tarea en rama” (task on branch).

Para configurar la extensión de Bugzilla en el cliente se debe de copiar “bugzillaextension.dll”, en el fichero en el que tenga instalado el cliente de Plastic SCM, y se añaden las siguientes líneas (rodeadas en rojo) para indicar al cliente que utilice esta extensión:


Y también debe de crear un fichero “bugzillaextension.conf”. La apariencia por defecto de este fichero es la siguiente:

<bugzillaextensionconfiguration>
<bugzillabaseurl>http://192.168.1.14:8888/bugzilla/3.0</bugzillabaseurl>
<branchprefix>SCM</BRANCHPREFIX>

La opción que se fija por defecto es la de “Tarea en Rama” aunque tambien se puede especificar de la siguiente manera:

<bugzillaextensionconfiguration>
<bugzillabaseurl>http://192.168.1.14:8888/bugzilla/3.0/</bugzillabaseurl>
<branchprefix>SCM$lt;/branchprefix>
<workingmode>TaskOnBranch</workingmode>
</bugzillaextensionconfiguration>

Ahora que ya está configurada la extensión el primer paso para empezar a trabajar con ella será crear un nuevo defecto (bug) en el sistema de control de tareas o defectos que vamos a utilizar: Bugzilla:

Se crea un nuevo defecto, en este caso se pone en estado “NEW” (nuevo) y se asigna a “tester”, también podemos incluir el número de horas estimadas y el plazo para realizar la tarea.
El título que se da a esta nueva tarea es “New Task Created: Comments on a file” (Nueva tarea creada: Comentarios en un fichero) y se incluye una descripción de lo que se va a hacer para la tarea.
Al guardar el defecto podemos ver el número que se le asigna en Bugzilla: en este caso es el 13 y podemos además indicar al sistema que envíe un email al desarrollador al que hemos asignado para que lo resuelva para que sepa que se ha encomendado una nueva tarea:


Cuando el desarrollador tester vaya a comenzar a trabajar en el defecto 13, creará fácilmente una nueva rama y la nombrará según el defecto creado en Bugzilla, además de añadir sus comentarios, puede poner los mismos que en el defecto en Bugzilla:


Entonces tendrá que acceder a la parte superior izquierda de la vista de ramas desde la que se muestra la información ampliada de las ramas, que muestra información del defecto correspondiente en Bugzilla al seleccionar una rama. En la siguiente imagen seleccionamos la rama que se acaba de crear (/scm013) y en la parte de la derecha podemos ver inmediatamente la información del defecto número 13, asociado a esa rama: su número, propietario o desarrollador al que se ha asignado la tarea, título y comentarios como muestra la vista normal:
Además está disponible la vista estándar que también muestra el estado del defecto en cada momento:


Y tan pronto como se haya realizado la tarea se hace doble click en el diálogo o simplemente click en el botón de la extensión, que nos llevará a ese defecto en Bugzilla, dónde podremos cambiar el estado que se refresca instantáneamente en Plastic:

¡Simple e intuitivo…que lo disfrutéis!

0 comentarios:

¡Nueva versión, Plastic SCM 2.5 ya disponible!

9:16 0 Comments

Nos alegramos de poder anunciaros que acabamos de lanzar el nuevo Plastic SCM 2.5, que ofrece un nuevo mundo de posibilidades para tus necesidades de gestión de la configuración.

Esta nueva versión incluye:



  • El sistema de triggers, demandado por algunos de vosotros, que permite la ejecución de comandos de usuario para tareas tales como instaurar políticas de creación de ramas o crear reglas de formato.
    Los triggers de “Antes” y “después” de eventos inician de manera automática acciones cuando tienen lugar los eventos. El sistema de triggers proporciona tanto triggers de espacios de trabajo que se ejecutan desde el servidor de espacios de trabajo (crear espacio de trabajo, configurar el selector, añadir nuevos ítems, protección y desprotección), y los triggers de repositorio que se ejecutan desde el servidor de repositorios (crear rama, atributo, etiqueta y repositorio) en el servidor, y en el cliente se ejecuta el trigger de "update".


  • Sistema de ramas "smart": El nuevo sistema de ramas que se ha incluido en Plastic SCM permite que los usuarios implementen cualquier tipo de patrón de trabajo ya que las propias ramas "recuerdan" su punto de partida, por lo que cada vez que un usuario cambia a una rama no tiene que configurar su base... y no sólo esto...las propiedades de una rama se pueden ir cambiando pero su historia no se pierde ya que Plastic se encarga de guardarla.


  • Sistema de atributos: Permite que los usuarios incluyan información adicional en cualquier objeto del sistema. Se trata de un sistema muy potente y altamente configurable ya que los desarrolladores pueden añadir cualquier atributo y cualquier valor para los atributos...y realizar búsquedas utilizando los atributos (como buscar las ramas que han sido integradas, siendo el atributo estado y el valor integrada...; o buscar etiquetas que se han entregado a los clientes A y B, etc).


  • Las extensiones de Plastic SCM para herramientas de control de tareas (Jira, Mantis, DevTrack, OnTime, VersionOne y Bugzilla) se han mejorado considerablemente: Como se puede observar en la imagen inferior, hemos incluido una opción en la interfaz gráfica desde la cuál se puede ver la información de la tarea asociada en la extensión. Y además hemos extendido la funcionalidad de las extensiones, ahora soportan dos diferentes métodos de trabajo: Tarea en rama o tarea en changeset.



  • Mejoras en el rendimiento de diversas operaciones como añadir nuevos ficheros, proteger y desproteger al realizarse en bloque: ¡hemos conseguido que estas operaciones sean el doble de rápidas!.


  • Mejoras en el sistema: en la integración con Eclipse, el importador de CVS y el instalador.


  • Correción de errores.


¡Hemos logrado un importante avance en esta nueva versión como resultado de un gran trabajo de nuestro equipo de desarrollo!

0 comentarios:

Problemas de usuarios

14:15 0 Comments

Después de leer el interesante post de Jonathan sobre clasificación de errores, me interesó el artículo del que habla ya que parece un enfoque muy interesante. Hemos tenido problemas en los últimos meses con este tema y parecía una buena opción.

Después de realizar varios ejemplos con distintas variantes de la fórmula decidimos intentarlo por lo que implementé unos cuantos cambios para soportarlo en nuestra herramienta interna de control de tareas (es un poco primitiva pero con muchas opciones de personalización), aquí se puede ver el resultado:



Creo que el método se tiene que ajustar más a nuestras necesidades pero ya se ve una mejora a la opción de tener un campo "prioridad" muy subjetivo para los defectos.

¡Gracias por la estupenda referencia Jonathan!

Por cierto, podéis encontrar el artículo original aquí. ¡Merece la pena!

0 comentarios: