Por: Fernando D. Bozzo
Una de las cosas que más me gustan de este SCM (Source Control Manager o Administrador de Código Fuente) es la cantidad de opciones que tiene para conectarse y sincronizarse con otros servidores Plastic y con otros servicios como GitHub, BitBucket y otros.
Este artículo está dedicado a quienes necesitan sincronizar sus repositorios con otras personas o con otros servicios, trabajen en solitario o en grupo.
Lo importante es conocer las opciones disponibles para luego elegir.
Quienes vienen trabajando con herramientas de control de código, ya saben que una vez que se comienza a trabajar así, no se puede ni se quiere vivir sin él, y quienes estén comenzando a conocerlo, estarán pudiendo comprobar, al menos, algunas ventajas que aporta, como poder ver y analizar el historial, deshacer o rehacer cambios, hacer un
Diff o un
Merge (....a qué ahora sí les suena esto :), preparar versiones del sistema, también llamadas Releases, preparar parches, trabajar simultáneamente en más de una versión del mismo componente, etc.
Dicho esto, una de las cosas que nos aportará valor y comodidad es poder disponer del control de código donde sea que estemos trabajando, tanto trabajando en solitario como trabajando en grupo y compartiendo un proyecto, y por eso vamos a ver varias situaciones y alternativas de trabajo disponibles.
Supongamos que disponemos de un PC de escritorio en
casa, o de un servidor en la oficina, donde está instalado el componente servidor
de Plastic con los repositorios definitivos, y donde realmente se centralizará todo el control del código fuente. Es necesario mantenerlo siempre actualizado, por lo que las vías para hacerlo son:
- Trabajar directamente en ese PC o en el servidor
- Trabajar en una red local con acceso a ese PC o servidor
- Trabajar desde Internet con acceso a ese PC o servidor
- Trabajar en una ubicación desconectada y sin Plastic, hacer una copia de lo trabajado en zip y sincronizarlo más tarde en el servidor Plastic
- Trabajar en una ubicación sin Plastic, pero con acceso a DropBox, Google Drive u otro servicio de guardado en la nube, para más tarde sincronizarlo en el servidor de Plastic
De ahora en más, hablar de una PC de sobremesa, hablar de una Portátil o hablar de un Servidor de Oficina o Empresa, en todos los casos con el componente servidor de Plastic, los consideraré a todos como "el servidor Plastic", ya que es la función que están realizando, desde el momento en que permiten guardar el código fuente en una Base de Datos local.
Es importante entender esto, porque todo lo posterior tratará sobre formas de
sincronizar los repositorios entre servidores Plastic, que perfectamente podrían sincronizarse entre una PC de sobremesa y una Portátil, o entre una Portátil y un Servidor de Oficina/Empresa, o entre dos (o más) Portátiles, o usando un repositorio externo como GitHub, BitBucket, etc, o cualquier otra combinación que se les ocurra donde intervengan dos o más servidores Plastic.
Finalmente, y para despejar cualquier duda, "
sincronizar" es
la acción de actualizar repositorios en ambos sentidos, o sea que se suben los cambios (archivos y directorios nuevos, modificados o eliminados) que el repositorio destino no tiene y se bajan los cambios que nuestro repositorio local no tiene, quedando el historial en ambos casos igualado.
¿Pero sincronizando no se pisarán mis cambios con los de los demás?
Puede ocurrir, si no se trabaja de forma organizada. Para evitar estos problemas fácilmente, la forma de trabajar debe ser tener una rama por desarrollador como mínimo, y a su vez otra rama por tarea, pero fundamentalmente debe haber un proyecto inicial, con su pjx, los archivos de configuración de Plastic y con toda la estructura de directorios en el repositorio, para evitar diferencias innecesarias en nombre de directorio o capitalización, y demás.
Opciones de sincronización entre repositorios
Estas son algunas de las opciones disponibles:
- Sincronizar un repositorio Plastic local con otro repositorio Plastic remoto. Esta es la opción ideal y la más eficiente. Requiere una conexión de red o por Internet entre ambos servidores Plastic, y que no esté bloqueado el puerto 8087 (u 8088 si se usa seguridad SSL). Ojo, Plastic no soporta Firewalls donde deba autenticarse. En esos casos se deberá usar redirección de puertos.
- Sincronizar un repositorio Plastic local con otro repositorio remoto como GitHub, BitBucket o cualquier otro soportado. Esta opción implica usar un servicio "intermediario", y si el repositorio no es público, probablemente implique algún costo extra asociado, ya que al menos GitHub, si se quiere usar un repositorio privado, se debe pagar, y supongo que con el resto será lo mismo.
- Trabajar con cliente Plastic local y servidor Plastic en red o por Internet. Realmente aquí no hay sincronización. Esta opción se suele usar en las empresas que tienen uno a varios equipos de desarrollo internos o externos, pero donde el código fuente se quiere que solamente esté en el servidor corporativo por ser un bien intelectual de la empresa. La única desventaja de este modelo es que si la red no es veloz se pueden producir picos de congestión si los equipos de desarrollo son numerosos o si se usa para procesos de Integración Continua (CI). Requiere una conexión de red o por Internet entre ambos servidores
Plastic, y que no esté bloqueado el puerto 8087 (u 8088 si se usa
seguridad SSL) y en este escenario ayuda mucho utilizar balanceo de servidores o Servidores Proxy Plastic (esto está mejor explicado en su web)
Supongamos que tenemos un portátil
nuestro que usamos para programar, en el que podemos instalar lo que sea
necesario, y que llevamos de aquí hacia allá todo el tiempo, sea a lo
del cliente, a casa o a un bar. Tenemos un Servidor Plastic
instalado en el portátil, y nuestros repositorios, cada uno con su proyecto. Aquí
trabajamos normalmente y sin mayor problema, ya que tanto el código como
el SCM están en el mismo equipo, por lo que hacemos checkin, merge,
ramas y lo que haga falta.
Si tuviéramos que sincronizarnos con un compañero que trabaja en otra ubicación y donde no compartimos una red local, podríamos usar estas opciones:
- Sincronización Plastic local a Plastic remoto. En este caso los dos nos ponemos de acuerdo en un horario para conectarnos a Internet y la sincronización sería directa de equipo a equipo usando el puerto 8088 SSL (u otro), y para resolver el problema de la IP dinámica se puede usar algún servicio como NoIP, DynDns o similar. El único problema con esto sería ponerse de acuerdo en ese horario, y que, a día de hoy, la versión 5 de Plastic no soporta la conexión a través de Firewalls que requieran autenticación, pero si al Firewall se le configura redirección de puertos, muy probablemente se pueda.
- Sincronización Plastic local a servidor remoto (GitHub, etc). Este es el caso comentado en Opciones de Sincronización, donde se usa un repositorio intermediario.
- Sincronización mediante archivos zip por DropBox. GDrive o similar. Esto realmente no es una sincronización, pero al menos permite incorporar los cambios de otra persona al repositorio local. La idea es crear dos ramas, la nuestra y la de nuestro compañero. Nosotros trabajamos en nuestra rama normalmente hasta que nuestro compañero nos envía un zip mediante DropBox, Google Drive o similar. Nos pasamos temporalmente a la rama de nuestro compañero, descomprimimos el zip en el workspace y hacemos el checkin. Ya está en control de código y podemos hacer un merge de su rama a la de integración. Este mecanismo es un poco Espartano porque nos implica estar haciendo un merge de lo nuestro y un merge de lo del otro, y al otro le implica lo mismo, con lo que se duplica el trabajo de integración y la posibilidad de errores, pero al menos nos puede sacar del paso.
- Sincronización Plastic local a Plastic local. Si, suena raro, pero se pueden crear 2 o más repositorios Plastic locales usando distintos workspaces y distintos nombres de repositorio, para luego, mediante un perfil de conexión (comentado más abajo), sincronizarlos. No sé si tenga alguna utilidad, ya que yo lo usé solo para probar y simular 2 usuarios distintos que sincronizaban sus repositorios (que se pueden modificar por separado), pero es bueno conocer las opciones disponibles.
- Fast-Export/Fast-Import: Finalmente hay una opción que merece ser conocida, que es la opción Fast-Export y Fast-Import, basada en el formato abierto de Git, que permite exportar un repositorio completo a un archivo en este formato de Git, y también permite importarlo. Esto permite una capa más de compatibilidad, no solo con Git, sino con otros SCM que admitan ese formato.
Dentro de la sección de configuración de Plastic, hay un apartado llamado Perfiles, donde se pueden configurar perfiles de conexión con distintos esquemas de autenticación (usuario/password, LDAP, Directorio Activo, etc).
Este apartado merece ser conocido, porque realmente admite muchas opciones de conectividad.
Como se podrá comprobar en la Instalación, los puertos son configurables, y esta configuración se puede cambiar en cualquier momento
Hay mucha documentación disponible en la web de Plastic, aunque lamentablemente está solo en Inglés.
Este es un link al apartado donde explican todo sobre entornos distribuidos.
Hasta la próxima!
Artículos relacionados:
PlasticSCM: Cómo configurar la replicación de repositorios Plastic locales y remotos
