Mostrando entradas con la etiqueta sincronizacion. Mostrar todas las entradas
Mostrando entradas con la etiqueta sincronizacion. Mostrar todas las entradas

domingo, septiembre 14, 2014

PlasticSCM: Cómo configurar la replicación entre repositorios Plastic locales y remotos

Por: Fernando D. Bozzo


[05/06/2015 - Actualizado con nuevo apartado de Exportación e Importación manual]

Suena complicado el título, como algo de la NASA, pero realmente no lo es.

En resumen: En Plastic, la "replicación" se refiere a la sincronización entre 2 repositorios, que es lo mismo que sincronizar 2 bases de datos, donde todos los datos nuevos que se han agregado en una de ellas se pasan a la otra, y viceversa, para lograr que ambas tengan lo mismo.

Estas bases de datos pueden ser locales, remotas o mezcla de ambas. En el caso de un repositorio remoto, puede ser tanto la PC o Portátil de al lado, como un servidor en otra planta o en otro edificio o ciudad.



¿Qué diferencia hay entre usar la Replicación y no usarla?


La replicación es simplemente una redundancia de repositorios, una forma de tener más de una copia de lo mismo y en ciertos casos es la única forma de poder trabajar con otras personas. Por ejemplo, cuando se trabaja con un Portátil que se puede llevar al cliente, y no se disponga de una conexión al repositorio principal (obviamente, siempre que el Portátil no sea el repositorio principal), entonces se hace necesario trabajar offline, o sea, con un repositorio local para poder ir protegiendo los cambios y mantener un historial de los cambios, que más tarde se sincronizarán con el repositorio central, que está en una PC de casa o de la oficina.

En el caso de no usar replicación de repositorios, se estará usando un único repositorio siempre, que estará todo el tiempo actualizado con lo último y no requerirá ninguna sincronización. Siempre estará la posibilidad abierta para crear otro repositorio en otro PC y hacer replicación.

Ahora, centrándonos en las diferencias, más allá de la sincronización en sí, la única diferencia notable es respecto de la eliminación de changesets, ya que si necesitamos eliminar un changeset o una rama por haberla creado mal, por ser innecesaria o por lo que sea, trabajando con un único repositorio esto es algo que se hace en un solo paso (se borra y listo), pero trabajando con replicación, se debe hacer esa eliminación en cada uno de los repositorios replicados, ya que si solo se hace en uno, al sincronizar se volverá a restablecer el/los changesets y ramas eliminadas, ya que los repositorios que tengan esa información se la pasarán a los que no la tengan.

Al final es algo simple de solucionar, pero es importante saber cómo funciona.



¿Qué ventaja tiene usar la Replicación?


La ventaja principal, es que con un par de clicks podemos hacer un "backup" en otro ordenador conectado a la red o a Internet, cosa que si a nuestro ordenador principal le pasa algo, al menos tenemos la tranquilidad de que tenemos una copia en otro ordenador, y es difícil que se estropeen 2 ordenadores a la vez.

A colación de esto, ¿recuerdan cuántas personas han aparecido en los foros diciendo que habían perdido todo o parte del trabajo (nada menos que los fuentes), y que sólo tenían, con suerte, un EXE para descompilar? ¿o los que se les ha estropeado algún binario (en general un form) con el que estuvo trabajando todo el día?

Espero que con lo fácil que es esto, ustedes no sean nunca esas personas, porque con esta facilidad que ofrece un DVCS y en varios casos sin coste (como este), ya no hay excusas. La comodidad es muy peligrosa en estos temas.




Configuración de una vista de sincronización


Veamos un ejemplo práctico de una replicación de un servidor Plastic local, por ejemplo, la PC o Portátil que usamos para desarrollar, y un servidor externo, que bien podría ser otro PC en la red o en Internet.

Nota: En mi caso, la PC local de trabajo es un Windows 7 virtualizado que llamé win7u, y el servidor es un PC físico con Ubuntu Linux llamado fer-desktop. En ambos casos, ustedes deben reemplazar los nombres de PC por los vuestros, así que las imágenes a continuación son orientativas. Para saber el nombre de vuestro PC, pueden abrir la ventana de comandos DOS, escribir SET <Enter> y ver una variable que dice COMPUTERNAME=NombreDeVuestroPC.



1) Lo primero es abrir la vista de Sincronización de repositorios, en el panel izquierdo, donde podemos observar 2 paneles verticales; el superior con los nombres de las "vistas" de conexiones y el de abajo con las conexiones de esa vista:




2) Luego añadimos una vista (de conexiones), que en este caso es una agrupación de una o más conexiones que se agruparán bajo un nombre identificativo a elección:




Una vez agregada la vista, ya aparece en la lista:




3) Ahora agregamos el origen de la conexión, que es el PC con el repositorio de origen, por ejemplo, nuestro PC o Portátil de trabajo (recordar, win7u es mi PC, ustedes pongan el suyo!):




 Una vez seleccionado el PC, el puerto y el repositorio, ya aparece el origen creado en la vista:




4) Ahora asociamos el destino de replicación, que puede ser otro repositorio en la misma PC o en otra que esté visible en la red o en Internet, en mi caso será fer-desktop, pero ustedes pongan la suya.

Cuando clickeen "Buscar" es posible que les pida las credenciales para conectarse al repositorio indicado, así que deberán indicarlas, y opcionalmente pueden marcar el check para "Recordar credenciales como un perfil de conexión", que luego se podrá acceder desde la opción "Preferencias" del panel izquierdo:

Nota: En el caso de que el repositorio externo sea de Internet o fuera de nuestra empresa o casa, conviene usar siempre una conexión SSL para mejorar la seguridad, en cuyo caso el servidor debe indicarse como ssl://ServidorRemoto:8088, donde ServidorRemoto puede ser una dirección URL o una IP.





5) Una vez puestos los datos del PC/servidor destino y puerto, se mostrarán los repositorios encontrados en el mismo (solo los que se tenga acceso), para seleccionar uno y aceptar:




6) Ya podemos "Refrescar" la conexión para que verifique si hay algo que sincronizar, por lo que hacemos click-derecho en la conexión deseada:




7) Si hay algo, como en este ejemplo, se mostrará qué hay, y si son cambios entrantes o salientes, siendo los entrantes los que actualizarán nuestro repositorio origen (normalmente el local) y los salientes los que se exportarán al repositorio destino (normalmente externo):




8) Si hay cambios, sincronizamos todo:




9) Se mostrarán las ramas que se sincronizarán y se da la oportunidad de cambiar algunos parámetros de la sincronización:




10) Si hay cambios para sincronizar, se mostrará un avance del proceso:




11) Hasta que finalice:




12) Una vez terminada la sincronización, se mostrará un mensaje de estado:




13) Respecto del check que había comentado cuando agregamos el repositorio destino, que permitía guardar las credenciales como un Perfil de conexión, estos datos se pueden acceder desde la opción de "Preferencias" del panel izquierdo, de donde se pueden modificar, agregar o eliminar perfiles, e indicar si el perfil es de conexión "Automática" o "Manual":


Respecto de elegir conexión Automática o Manual, la decisión se debe basar en si el repositorio a conectarse está todo el tiempo disponible (siempre online) o no (a veces offline).



[Actualizado. 05/06/2015 >>]

Exportación e Importación manual de repositorios


Plastic permite exportar o importar los repositorios, uno a uno, de forma manual por medio del comando cm desde la ventana de comandos. El formato es abierto y se basa en el mismo formato que usa git, con lo cual también se puede usar para importar o exportar en git.


Exportación:

La sintaxis para exportar es la siguiente:

cm fast-export repositorio@servidor:8087 [archivo-destino.dat]

Si no se indica el nombre del archivo destino, se llamará "fast-export.dat", y si existiera, se le irá agregando 1, 2, 3, etc.


Este es un ejemplo de uso en Linux (muy similar a Windows):

cm fast-export FoxUnit@fer-desktop:8087 ./FoxUnit.dat


Importación:

La sintaxis para importar es la siguiente:

cm fast-import repositorio@servidor:8087 archivo-a-importar



Más información en la web oficial:
https://www.plasticscm.com/documentation/technical-articles/kb-fast-import-fast-export.html
[<<]



Notas finales

Este artículo pretendió explicar de forma rápida como configurar una replicación, pero no es extensivo, y hay unos cuántos parámetros y combinaciones interesantes para ver, como por ejemplo la posibilidad de replicar un origen a múltiples destinos y otras opciones, que les dejo para que les investiguen ustedes.

Espero que les haya sido útil.


Hasta la próxima! :D


Artículos relacionados:
PlasticSCM: Opciones de conectividad, transporte del código fuente y backup


viernes, agosto 15, 2014

PlasticSCM: Sincronización con GitHub

Por: Fernando D. Bozzo

En esta nota vamos a ver cómo se vincula y sincroniza un repositorio Plastic con GitHub.

Nota: Plastic tiene sus propios repositorios, y no necesita conectarse a repositorios externos como GitHub o BitBucket para funcionar. Esto solo se hace cuando específicamente se quiere trabajar con esos repositorios.


Un aviso importante:


   Una vez hecha la sincronización con GitHub ya no hay marcha atrás, y lo que se suba quedará subido y no se podrá borrar localmente. Aunque se intente borrar localmente (por ejemplo un changeset) en la siguiente sincronización se volverá a descargar todo y volverá a aparecer, y si no se controla bien los archivos que suben, sus conversiones a texto, su capitalización y el tipo de archivo (que no sea basura), puede perjudicar la sincronización con GitHub, lo que en la práctica puede significar tener que volver a hacer todo desde cero (crear otro repositorio Plastic, otro repositorio GitHub, etc), por eso insisto tanto en tomar las precauciones necesarias para no tener que perder tanto tiempo luego en reconfiguraciones.

Una vez aclarado el tema, ahora sí, el proceso de sincronización.


Pasos a seguir para sincronizar con un repositorio GitHub


1) Seleccionar el alias del workspace que se quiere sincronizar desde la solapa superior, justo bajo el título de la ventana (ejemplo: dvcs_vfp9). Como el workspace está vinculado a un directorio y al Repositorio (de hecho es un alias para una vista del repositorio), Plastic sabe de donde tomar la información y donde actualizar. También puede observarse que justo bajo la solapa del workspace está la información del mismo, en el formato:

Rama @ Repositorio @ servidor : puerto  y Workspace path (directorio del workspace)




2) Ahora vamos vincular nuestro repositorio con GitHub. Hacemos click-derecho en la rama /main sobre la parte gris que está fuera del punto azul (es poco margen al principio, pero se puede seleccionar y se quedará coloreada de azul claro, bajo los puntos circulares), se abrirá el menú contextual y en el título del panel derecho deben ver que dice "Nombre de la rama" (si dice "numero de changeset" eligieron mal), en este menú eligen "Replicación / Sincronizar con Git":



3) Aquí ponen la URL del repositorio de GitHub ( ejemplo: https://github.com/fdbozzo/dvcs_vfp9.git ) y el usuario y contraseña que usaron para darse de alta en GitHub, y pulsan "Sincronizar" (no se preocupen del nombre que figura en la captura, que es solo ilustrativo):



4) Si todo salió bien, deberían ver esto:



Si lo anterior sale en rojo, es que algo salió mal (por ejemplo, siguiente imagen) y se debe analizar el mensaje de error dado. En este caso, el error se debió a un bug de Plastic que reporté en febrero y que solucionaron:




5) Una vez que cierren esta pantalla, ya está hecha la sincronización y guardadas las credenciales para las próximas sincronizaciones.En el Explorador de ramas, si actualizan con F5 o con el icono de la flecha circular (a la derecha de ACCIONES PRINCIPALES), deberían poder ver dos o más puntos azules, al menos más puntos de los que veían antes de sincronizar. Esta vista es un gráfico de changesets (cambios) en el tiempo, donde pueden ver la fecha (arriba), y hacia la derecha siempre está lo más nuevo.



Nota importante:
Las ramas nuevas no hacerlas nunca del primer nodo de /main (el de más a la izquierda), debe hacerse de los posteriores y normalmente se hace desde el último changeset de la derecha, ya que si no les quedarán ramas fantasma que no podrá ver nadie mas.



Solución a algunos problemas sincronizando con GitHub u otro repositorio externo no-Plastic


Cuando se trabaja con repositorios externos como GitHub, BitBucket u otros, a veces las cosas pueden no salir como esperamos.

Si el problema es de conexión, o sea que da un error nada más intentar sincronizar, lo primero que se debe verificar son los datos de conexión al repositorio externo, como la URL, el usuario y la contraseña, que a veces poner mal un carácter impide la conexión.

Si se detecta que lo que uno de los usuarios ve no se corresponde con lo que debería ver, una solución podría ser que el usuario se cree un nuevo repositorio local, en un nuevo workspace y un nuevo directorio, vuelva a configurar la conexión al repositorio externo y sincronice. De esta forma se le bajará todo nuevamente, y si el repositorio local anterior tenía algún problema, entonces ese problema desaparece.

Normalmente esto lleva unos minutos, dependiendo del tamaño del repositorio externo.




Hasta la próxima!



domingo, julio 06, 2014

PlasticSCM: Opciones de conectividad, transporte del código fuente y backup

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