Ejemplo de repositorio con SVN con un proyecto Magento

Hace ya un buen tiempo, estuvimos charlando con Pablo Montero (compañero de andadas en cuanto a Magento se refiere) sobre cómo estructurar un repositorio (con Subversion) para trabajar con la plataforma.

Vale aclarar que el ejemplo que voy a armar, es sólo eso: un ejemplo. Otra aclaración oportuna, sería que si bien el ejemplo lo aplico con Magento puede pensarse para cualquier otro proyecto y sería más o menos válido (hay mucho de decisiones arbitrarias al momento de crear un repositorio).

Antes de continuar, voy a dar por sentado que mínimamente tenemos una noción del uso de los trunk, tags y branches en SVN.

A manera de repaso simple (intencionalmente demasiado simple), vamos a considerar que:

• trunk: es la rama principal del proyecto y es dónde se alojará la versión productiva.
• tags: se utiliza para dejar marcada, por ejemplo, una implementación; y de esa forma poder volver a ese punto sin mayores problemas.
• branches: suelen utilizarse como líneas de desarrollo independientes del trunk, las cuales en algún momento pueden volver a mergearse con la línea principal.

De seguro podríamos hablar mucho más sobre los branches, pero lo vamos a dejar para otro post. La idea hoy es armar un repositorio para que podamos trabajar con nuestra plataforma de ecommerce favorita.

Antes de pasar a la estructura propuesta, vamos a introducir un término/concepto adicional dentro de los branches que es el de vendor. Dentro de ésta carpeta, podríamos incluir el software de terceros que usamos para nuestro proyecto.

Ahora si, el ejemplo:

/
|
+--/ branches
|  |
|  +--/ vendor
|     |
|     +--/ magento
|        |
|        +--/ 1.2.1.1
|           |
|           +--/ ...
|
+--/ tags
|
+--/ trunk

Si, como que sabe a poco. Vamos a empezar ver cómo podríamos trabajar con esta estructura.

Normalmente vamos a estar trabajando contra el trunk. Si bien sería posible, para grupos de trabajo chicos a medianos en el desarrollo de Magento, podría no ser necesario el uso de múltiples branches para aislar los trabajos de cada programador.

Nuevamente hago hincapié en lo arbitrario de éstas decisiones.

Este punto tiene que ver con la posibilidad que nos brinda la plataforma para aislar nuestro código del provisto por la herramienta.

Nuestro trabajo consistirá en armar los templates y generar nuestros módulos o reescribir los del core, pero nunca vamos (en realidad, nunca debiéramos) tocar nada de lo que ya viene por defecto.

Si aceptamos esto, vemos cómo se justifica un poco el no uso de branches.

Lo que si vamos a tomar del branch, es la versión que estemos usando de Magento. Para esto, al comienzo del proyecto deberíamos hacer un primer merge para llevar a nuestro trunk, la versión que utilizaremos como estable. (De más está decir que primero tuvimos que haber bajado la versión elegida y debimos subirla al branch correspondiente).

Ahora si, el primer paso seria aplicar el merge contra el trunk. Una vez hecho esto, veríamos algo como esto:

/
|
+--/ branches
|  |
|  +--/ vendor
|     |
|     +--/ magento
|        |
|        +--/ 1.2.1.1
|           |
|           +--/ ...
|
+--/ tags
|
+--/ trunk
   |
   +--/ 404
   |
   +--/ app
   |
   +--/ downloader
   |
   +--/ js
   |
   +--/ lib
   |
   +--/ media
   |
   +--/ pkginfo
   |
   +--/ report
   |
   +--/ skin
   |
   +--/ var
   |
   +--/ ...

Una vez que hayamos hecho el checkout y empecemos a trabajar, de seguro vamos a ir realizando los commits pertinentes. Llegado el momento, nos toca hacer la implementación en producción.

Acá es dónde los tags pueden tomar un papel más que importante.

Una buena práctica sería realizar un tag de nuestro trunk al momento de la implementación. Por ejemplo: bajo el nombre de “Release 1.0” (nuevamente, decisiones que cada uno sabrá tomar en cuanto a los nombres).

De ésta forma, el proyecto puede evolucionar y siempre tendremos esa marca a la cual recurriremos si necesitamos situarnos en esa versión por algún motivo.

Ahora veamos otra cuestión. Supongamos que Varien publica una nueva versión. Lo que deberíamos hacer es agregar esa versión dentro de nuestro vendor.

A partir de éste momento, nos quedaría de la siguiente forma:

/
|
+--/ branches
|  |
|  +--/ vendor
|     |
|     +--/ magento
|        |
|        +--/ 1.2.1.1
|        |   |
|        |   +--/ ...
|        |
|        +--/ 1.2.2.0
|           |
|           +--/ ...

En éste punto es donde pareciera que toma un poco de sentido el uso de los branches y el vendor.

Si decidiéramos que es momento de hacer una actualización de versión, empezaría nuestro trabajo de merge.

Una vez resuelto el merge (tarea que podría llevar algo de tiempo y cierta concentración), tendríamos en nuestra versión local del trunk, nuestro proyecto, con todos los archivos de Magento actualizados a la versión elegida.

Lo siguiente en la lista de tareas, es hacer una revisión exhaustiva de nuestro proyecto. En líneas generales no debiéramos de tener problemas, salvo que estemos usando extensiones de terceros o propias.

Incluso, es importante controlar que los skins funcionan correctamente, ya que con los cambios de versión, se presentan cambios en los layouts, en los phtml, incluso en los javascript de, por ejemplo, el checkout.

El último paso en este proceso es hacer un commit para dejar en el trunk la versión final (y mergeada) del código.

Si todo salió bien, a medida que el resto de los involucrados hagan el update del proyecto, ya van a recibir la actualización de código que aplicamos. Al hacer un update en nuestro entorno productivo (suponiendo que hacemos los deploys usando el repositorio), la tienda pasará a actualizarse de manera automática, habiendo sido testeada en nuestros entornos de staging.