Trabajo distribuido con Plastic

Trabajo distribuido con Plastic

12:31 0 Comments

Una de las nuevas características más importantes de Plastic SCM 2.0 es el sistema distribuido. Hoy voy explicar la configuración que utilizo para trabajar desde mi portátil, desconectado de la red; y de cómo utilizo el sistema distribuido para sincronizar cambios.

Esto es exactamente lo que me encanta del sistema distribuido: no es sólo útil para grandes equipos de desarrollo que trabajen en diversas localizaciones, también ayuda a los desarrolladores a poder trabajar desde sus portátiles...¡aunque formen parte de equipos pequeños!

Mirad la siguiente figura: es un diagrama de implementación de diversos servidores que estamos utilizando aquí en nuestra oficina. Por supuesto que todos estos repositorios podrían estar en un único servidor, pero hemos configurado un escenario con múltiples servidores para probar las capacidades de Plastic diariamente.

Como podéis ver en la imagen, tenemos tres servidores de repositorios, dos de ellos funcionando en Linux/Mono y un tercero en Windows. El servidor de windows (mordor) además funciona como servidor de espacios de trabajo, así que es el que hemos configurado como servidor de espacios de trabajo en nuestros ordenadores. Con lo que mi selector de espacios de trabajo tendría un apariencia más o menos así:

rep "cmuser" mount "/06cmuser"
  path "/"
    label "BL091"

rep "importers" mount "/05importers"
  path "/"
    label "BL091"

rep "licensetools" mount "/04licensetools"
  path "/"
    label "BL091"

rep "pnunit" mount "/03pnunit"
  path "/"
    smartbranch "/main/SCM2937"

rep "nervathirdparty" mount "/02nervathirdparty"
  path "/"
    label "BL091"

rep "codice"
  path "/"
    smartbranch "/main/SCM3278"

Si, ¡6 repositorios montados en el mismo espacio de trabajo!

Si os fijáis detenidamente veréis una regla a la que posiblemente no estéis acostumbrados...si, la regla del selector de smartbranch...Ya está en funcionamiento en Plastic 2.0 aunque aún no hemos sacado información pero escribiremos más sobre esta característica en breve, ahora es el momento de centrarnos en el sistema distribuido:-P

Cuando trabajo desde casa suelo conectarme a la oficina por VPN, y luego trabajo con el portátil igual que si estuviese en la oficina. Nada cambia...pero de vez en cuando la red deja de funcionar...lo cual no es un problema trabajando con Visual Studio (soporte para trabajo sin conexión) o si continúas trabajando en la misma tarea (se puede seguir haciendo cambios, buscando los ficheros modificados cuando se recupere la conexión y desprotegiendo todo). Pero, ¿qué pasa si no tienes conexión a internet y quieres crear nuevas ramas o cambiar de una rama a otra?

Pues ese es el motivo por el que he instalado un servidor de Plastic en mi portátil y utilizo el sistema distribuido para seguir trabajando incluso cuando la red deja de funcionar.

He configurado un servidor en mi ordenador (beardtongue) en el puerto 6060. En este momento estamos utilizando el método de autenticación de usuario/contraseña por lo que he puesto el mismo método de identificación en mi servidor, aunque podría utilizar uno diferente y la replicación funcionaría igual (ver el manual del sistema distribuido).

Una vez que está configurado, recordad que el cliente tiene que apuntar al servidor adecuado. Para esto se puede editar a mano el fichero client.conf file (en documents & settings si eres usuario de windows) o run plastic --configure.

Los repositorios que necesito utilizar diariamente son codice (en el que está el código de plastic), thirdparty (librerías y cosas parecidad) y pnunit (nuestro sistema de pruebas); por lo que después de configurar mi servidor he creado tres repositorios vacíos denominados "codice", "thirdparty" y "pnunit" en mi servidor:

  $ cm mkrep localhost:6060 codice
  $ cm mkrep localhost:6060 pnunit
  $ cm mkrep localhost:6060 thirdparty

Una vez que se han creado, he replicado la rama principal de los tres repositorios en mis repositorios locales:

  $ cm replicate br:/main@rep:codice@venus:9090
      rep:codice@localhost:6060
  $ cm replicate br:/main@rep:pnunit@juno:9092
      rep:pnunit@localhost:6060
  $ cm replicate br:/main@rep:thirdparty@venus:9090
      rep:codice@localhost:6060

En mi caso la replicación de la rama principal tarda un poco la primera vez.
La razón es que está realmente copiando todas las revisiones, los changesets, etiquetas y datos de la rama principal a mi repositorio local, y tenemos más de 1Gb sólo en las ramas principales de todos los repositorios.

Una vez que la replicación ha terminado tengo todo el historial de las ramas principales de los tres repositorios en el servidor de mi portátil. Hay otro modo de llevar a cabo la replicación y requiere utilizar lo que llamamos paquetes de replicación. Imaginemos que por algún motivo mi portátil no puede acceder a uno de los servidores, por ejemplo, a venus. Entonces podría ir a una máquina con accesos y ejecutar

  $ cm replicate br:/main@rep:codice@venus:9090
      --package=replication.pack

Que implica que la replicación creará un paquete con todos los datos para la rama br:/main.

Una vez que haya terminado, podría copiarlo en una memoria usb y pasarlo a mi portátil, en éste ejecutaría

  $ cm replicate rep:codice@localhost:6060
      --import=replication.pack

Para importar los datos a mi repositorio.

Hasta ahora he configurado un servidor en mi portátil y tengo una copia completa de las ramas principales de los repositorios con los que necesito trabajar diariamente.

Entonces crearé un espacio de trabajo y configuraré un selector como el siguiente (claro que las cosas son más sencillas si se utiliza un sólo repositorio):

rep "pnunit" mount "/03pnunit"
  path "/"
    label "BL091"

rep "nervathirdparty" mount "/02nervathirdparty"
  path "/"
    label "BL091"

rep "codice"
  path "/"
     label "BL091"

Y se configura un espacio de trabajo para poder compilar y depurar BL091.

Bien, pero el sentido del sistema distribuido no está tan sólo en poder trabajar en modo lectura, sino hacer modificaciones.

Si tengo que trabajar en la tarea 4312. Entonces crearía una rama Then -4312 (desde la GUI o desde línea de comandos, dependiendo de cómo se quiera trabajar), y configuraría el siguiente selector

rep "pnunit" mount "/03pnunit"
  path "/"
    label "BL091"

rep "nervathirdparty" mount "/02nervathirdparty"
  path "/"
    label "BL091"

rep "codice"
  path "/"
     branch "/main/issue-4312" label "BL091" co "/main/issue-4312"

Ahora podría hacer tantos ciclos de desprotecciones y protecciones como fueran necesarios y estarían en el servidor de mi portátil.

En algún momento volveré a la oficina y querré incluir las ramas en el servidor real. En este caso he creado una rama para el repositorio codice, situada en venus:9090, así que hago lo siguiente:

  $ cm replicate
     br:/main/issue-4312@rep:codice@beardtongue:6060
     rep:codice@venus:9090

Que replicará todos los cambios de la rama 4312 creada en mi portátil al servidor principal.
También podría actualizar mis copias de las ramas principales ejecutando de nuevo los comandos de replicación desde los servidores del equipo, que ahora sería mucho más rápido que la primera vez.

Pero, ¿que pasa si modifico la rama principal en mi portátil?, No habría ningún problema, depende totalmente del modo en el que se quiera trabajar, si queremos que todos puedan modificar la rama principal o no depende de cada equipo de trabajo. Si se hace así, ¿qué pasa si alguien modifica la misma revisión en el servidor principal a la vez?, tanto si se replica desde un portátil al servidor o viceversa, Plastic detectará que se a modificado una revisión en ambos lados. Creará una rama "fetch" que contenga los ficheros modificados en paralelo con lo cual los cambios se podrán sincronizar con una simple operación de integración...

¿Cuál es mi manera preferida de trabajar? Dependerá del escenario. "roaming developers" será mejor que trabajen en ramas separadas (nosotros lo hacemos continuamente con el patrón de rama por tarea) y utilizaría la rama principal como sólo lectura. Entonces incluirían los cambios en el servidor y actualizarían la rama principal para cada nueva versión.

Esta es tan sólo una manera sencilla de conseguir sacar partido a los beneficios del nuevo sistema distribuido de Plastic SCM: utilizarlo para desarrollar desde un portátil incluso sin acceso a internet.

¿Qué será lo siguiente? Como habréis visto toda la funcionalidad del sistema distribuido está disponible a través de la línea de comandos, así que se incluirá en la interfaz gráfica en cuanto bastante pronto...