Julián Perelli    Projects    Blog    Talks

SVN vs FTP

03 May 2012

Problema de trabajar en equipo

Parece trivial decir que el trabajo en equipo es esencialmente que “varias personas trabajan en conjunto para resolver el mismo problema”, pero de ésta misma idea surgen varios problemas, que son inherentes al trabajo en equipo pero están fuera del problema real a resolver.

En el paradigma de compartir archivos sin ningún “árbitro” o “semáforo”, que sucede comúnmente a través de un FTP o una carpeta compartida en samba, sucede que para trabajar sobre un archivo, cada integrante realiza 3 tareas:

  1. Copia un archivo del servidor a su pc personal.
  2. Modifica el archivo localmente.
  3. Vuelve a subir el archivo al servidor.

Estos 3 pasos o bien suceden manualmente (los realiza el desarrollador conscientemente), o bien los realiza el sistema operativo sin que sea notado.

El problema mas común sucede en el tercer paso, ya que pasa un tiempo entre el primer y tercer paso. Al trabajar en equipo, un desarrollador puede haber resuelto un bug, modificando algún archivo sin haber avisado, mientras que otro puede “pisar” el archivo sin darse cuenta que el 2do desarrollador lo había modificado. Esto hace que se reintroduzcan bugs por subir una versión vieja al servidor. Ya que los desarrolladores pueden trabajar en distintas franjas horarias, puede ser que ninguno de ellos conversen para saber qué archivos modifican.

El segundo problema mas común surge cuando esos mismos 3 pasos son realizados sobre una carpeta que contiene cientos o miles de archivos, de los cuales sólo se modifican algunos que están dispersos en diferentes lugares, pero se transfieren absolutamente todos porque resulta imposible buscar y seleccionar cada uno de los que fueron modificados. Esto provoca una transferencia de una cantidad desmesurada de datos por la red, que puede llegar a tardar horas, por solo haber modificado algunos cuantos kilobytes de datos.

El tercer problema común es la falta de backup automático con cada cambio introducido. Sin backups automáticos, se pierden los cambios únicos que introducen o reparan bugs. Esto es esencial para recuperar rápidamente el sistema cuando falla.

El cuarto problema común es cuando hubo alguna modificación del código y nadie parece saber qué realiza esa porción de código. A quién preguntarle? Quién sabe qué tarea realiza ese archivo o esa porción de código?

Para enumerar, los problemas más fuertes son:

  1. Sincronización de lecturas/escrituras entre desarrolladores.
  2. Elección de archivos específicos a modificar (transferencia mínima).
  3. Backup + revisiones + rollback.
  4. Identificación de responsables (no repudio).

Pareciendo utópico, el uso de un sistema de versionado resuelve todos estos problemas (y más) de manera simple (sin introducción de nuevos problemas).

Experiencia

Escenario de aplicación

Se trabaja con el desarrollo de la página web del Ministerio de Salud de la Provincia de Buenos Aires, bajo tecnologías estándar HTML+CSS+JQuery, con una base de datos MySQL y un gestor de contenidos Wordpress.

Equipo de trabajo

El equipo de trabajo consta de 4 personas dedicadas fijas, con los conocimientos específicos descriptos a continuación:

Es destacable que la mayor parte del equipo no tiene conocimientos de programación, pero sí trabajan con archivos de texto plano, aunque utilicen herramientas de trabajo gráficas.

Herramientas disponibles

Los trabajadores se encontraban utilizando cada uno su pc más dos servidores, de la siguiente manera:

Bajo este modelo, cada desarrollador debía bajar los archivos del samba, modificarlos, y subirlos al FTP y al samba.

El samba sólo estaba sirviendo como una forma de backup.

Los desarrolladores que no tenían apache instalado, solo podían ver el resultado de su desarrollo en producción, por lo cual terminaban creando archivos “temporales” de tipo index1.php, index32.php, indexPEPE.php, para poder visualizar el desarrollo.

Problemas encontrados

Se encontraron los cuatro problemas mencionados en la parte principal de este documento:

  1. Los diseñadores podían pisarse los archivos y lo hacían a veces sin darse cuenta. Para que ésto no sucediera, ellos debían recordar que sólo algunos de ellos podían modificar ciertas partes del sitio web para evitar conflictos. Esto era una tarea engorrosa, y hacía que los mismos desarrolladores terminaran resolviendo problemas de sincronización en vez de enfocarse de lleno al diseño.

  2. Con la utilización de templates en dreamweaver, a veces era necesario cambiar una url o realizar algún otro cambio pequeño en muchos lugares de la página. Para hacer ese cambio, se aplicaba el template, que modificaba sólo los archivos html que usaban el template. Pero dado que estos archivos estaban dispersos por todo el sitio, terminaban pasando el sitio completo a producción (html, pdf, css, js, flash, jpg, etc), tardando varias horas en hacer una simple actualización, por lo cual muchas veces se optaba por no realizar la actualización.

  3. Si alguien había modificado algo que estaba mal, no había manera de volver atrás, si se había introducido un error, debían repararlo volviendo a modificar los archivos.

  4. Varias veces, para saber quien había ingresado una imagen al sitio, hubo que preguntarle a cada uno de los desarrolladores y esperar unas horas hasta que el responsable apareciera. También se encontraban muchos archivos y carpetas que alguna vez habían sido puestos en el servidor, pero nadie sabía si se estaban usando ahora o no (sumaban unos 2gb, lo que representa un 25% del tamaño total del sitio).

Solución

Como solución íntegra se utilizó un versionador de código para contrarrestar todos los problemas antes mencionados de manera transparente a los desarrolladores.

Herramientas utilizadas:

TortoiseSVN es una herramienta simple que se integra al entorno Windows para acceder a un repositorio de una forma sencilla, con el menú contextual.

También puede accederse al repositorio directamente a través de entornos de programación (IDE) comunes, tanto desde una pc Windows, como linux o incluso mac.

Para enviar modificaciones al servidor, se hace un simple clic a “SVN commit”, y el sistema automáticamente detecta los archivos modificados, subiendo los cambios realizados al servidor. Entonces el sistema de versionado hace los chequeos necesarios para que no se “pisen” archivos, y luego guarda todo en un historial de revisiones bajo el nombre del usuario que realizó la modificación.

Recepción del cambio de paradigma

Los desarrolladores tardaron unos 5 a 10 minutos en entender y empezar a utilizar la herramienta.

Las primeras reacciones fueron de alivio al enterarse que el sistema es muy simple de utilizar.

Luego se palpó con gran sorpresa el poder de la utilización del repositorio, al realizar cambios en el template del sitio en unos 30 segundos, comparado a las 4 o más horas que tardaba antes, pudiendo así realizar cambios que antes eran imposibles de realizar.

Hasta hoy se evitaron unas 6 reintroducciones de código viejo (“pisar” archivos) por conflictos de sincronización, que hubieran sucedido antes sin notarlo.

Se utilizó una vez el rollback, o la restauración de una versión antigua pero funcional en producción para reparar rápidamente un error introducido, con lo cual la página dejó de funcionar y se recuperó en cuestión de segundos, hasta que el error fue reparado con tiempo, tranquilamente en desarrollo. Esto tranquilizó mucho a uno de los desarrolladores que estaba muy nervioso por el error que había cometido.

Se encontraron varias veces a los responsables de realizar ciertos cambios en algunos archivos de la página, lo cual ayudó la rápida comunicación para agregar dinamismo y velocidad al grupo.

Related Posts