RickArt blog

En un artículo anterior comentaba como configurar un entorno ideal de Symfony en el que compartir todo lo redundante entre diferentes Workspaces.

A continuación vamos a tratar la puesta a punto del proyecto anterior para poder trabajar con Zend Studio (PDT podría servir)

Condiciones iniciales

• Disponemos de un entorno configurado con 3 vhosts que comparten un mismo kernel de symfony
• Vamos a dejar listo para trabajar uno de los entornos (dev1). Se debería repetir el proceso para los otros entornos.
• Configuraremos el proyecto para versionarlo sobre un servidor SVN

Previamente a la creación del proyecto nosotros hemos desplazado ciertos directorios a la zona común de modo que ha quedado así:

Creación del proyecto y primer import al SVN

En este momento tenemos les entornos preparados y correctamente configurados de forma que si accedemos a http://dev1.mydomain vemos la página principal típica: Symfony Project Created.

Creamos un nuevo proyecto en Zend en el que indicaremos el nombre del proyecto (myProject) la ruta donde se encuentra el entorno (/data/dev1.mydomain) e idealmente indicaremos la ruta donde se encuentra symfony como external library.

Por otro lado, como el proyecto tiene una área común (/data/common/project) también crearemos sobre esta ruta un nuevo proyecto, idéntico al anterior, al que llamaremos myProyectCommon.

Bien, suponiendo que tenemos ya los 2 proyectos configurados (myProject y myProjectCommon) y también una repositorio SVN localizable por ejemplo en svn://svnserver/repos/myrepos procedemos a conectar los espacios de trabajo con sus respectivas rutas versionadas.

Desde Zend Studio:

Botón derecho sobre el proyecto > Team > Share Project > SVN

En este punto creamos el nuevo repositorio (creamos la conexión).

En la siguiente fase seleccionamos "Use project name" como primera opción y "Use single project layout" como segunda.

Cancelamos el diálogo final (para los 2 proyectos) para poder seleccionar libremente los directorios que queremos ignorar.

Así pues procedemos a aplicar los svn-ignore sobre los siguientes directorios del proyecto principal:

• /log
• /cache
• /www/sf
• /www/uploads

Es importante tener en cuenta que para poder aplicar el parámetro svn-ignore a los dos últimos directorios es necesario haber añadido previamente el el directorio /www al repositorio.

Una vez ya tenemos esas rutas vetadas para ser versionadas por el SVN podemos añadir todo el proyecto.

Desde Zend Studio:

Botón derecho sobre el proyecto > Team > Add to version control

Como ya hemos aplicado el svn-ignore podemos seleccionar todos los items.

Ok, una cosa es haber añadido todas las rutas que deben sincronizarse al repositorio y otra es hacer realmente el import que sube los archivos al servidor SVN. Así pues ha llegado el momento de realizar el primer import.

Regenerando un nuevo espacio de trabajo a través del SVN

El primer espacio de trabajo (dev1.myproject) desde el que se ha creado y adaptado la SandBox está configurado y sincronizado con el SVN, pero para poder verificar que todo está funcionando como es debido vamos a dejar listo otro entorno de trabajo (dev2.myproject) a través del SVN.

En dev2.myproject actualmente no hay nada, así que creamos un nuevo proyecto sobre esta ruta vacía. Como estamos probando (ya que no tiene sentido que un mismo desarrollador tenga configurados 2 workspaces) vamos a llamar a este proyecto myProjectWorkspaceTest.

Desde Zend Studio:

Se crea un nuevo PHP Project (myProjectWorkspaceTest) sobre la estructura de dev2.mydomain

Una vez creado el proyecto se debe iniciar la comparticion del mismo:

Botón derecho sobre el proyecto > Team > Share Project > SVN

Del mismo modo que con el primer proyecto creamos una nueva conexión (myProjectWorkspaceTest)

En la siguiente fase seleccionamos "Use project name" como primera opción y "Use single project layout" como segunda.

En este caso también cancelamos el diálogo que aparece al final del proceso pero con intención diferente a la primera vez que lo hicimos. En este caso lo hacemos para poder cambiar (switch) seguidamente de repositorio.

Botón derecho sobre el proyecto > Team > Switch

Seleccionamos el proyecto principal (myProject) y desde el repositorio SVN (la vista) eliminamos el proyecto del mismo temporal (myProjectWorkspaceTest).

Cuidado con el archivo: .project y los directorios: .cache y .settings, es posible que sea necesario eliminarlos manualmente si no se ignoraron en el primer import.

Si ahora hacemos un svn-update esto nos debería dejar el espacio configurado para funcionar.

Así pues, si ahora accedemos a http://dev2.myproject deberíamos ver también el archiconocido: Symfony Project Created

Se deberán realizar algunos ajustes tales como crear en dev2 los directorios cache y log (que no se han obtenido del SVN ya que están como svn-ignore) y asignar permisos de escritura a estos 2 nuevos directorio.

Finalmente para dar por finalizado el proceso se ha optado por eliminar del SVN los directorios y archivos relacionados con el proyecto de Zend (Eclipse): .project, .cache, .settings

Es cierto que Symfony ofrece múltiples opciones para configurar en entorno en el que empezar a trabajar de forma rápida. El más extendido es, sin duda, la sandbox, peeeero en algunas ocasiones viene bien pensar en un entorno algo más sofisticado de cara a permitir el desarrollo compartido entre múltiples desarrolladores.

Condiciones iniciales

Se piensa en un entorno que:

• Permita mantener entornos independientes para 3 desarrolladores.
• Permita mantener sincronizado el código de forma fácil con un repositorio de código.
• Optimice el contenido para evitar repetir la información estática entre entornos.

El servidor de desarrollo y el de producción serán Linux.

Configuración del espacio de cada desarrollador

Para el caso que nos ocupa se ha optado por una estructura del tipo:

Sobre esta estructura están mapeados 3 Virtual Host, uno para cada desarrollador. Estas rutas además son accesibles por SAMBA para facilitar su manipulación en Zend desde Windows (el caso que se tratará aquí).

Así pues si ahora dejamos un archivo /data/dev1.mydomain/www/index.php con su pertinente echo "Hello World!"; podremos acceder directamente al mismo desde http://dev1.mydomain siempre que tengamos correctamente configurado correctamente el archivo archivo hosts.

Instalación de Symfony

Se ha optado por la instalación de Symfony vía SVN checkout entre otras razones para poder aplicar parches de forma rápida. También se ha optado por esta opción ya que para compartir las librerías en el servidor de desarrollo esta es una de las mejores opciones.

Vamos a suponer que el espacio de desarrollo (no donde apuntan los vhosts) es /data.

Así pues se hace un checkout mediante el comando

svn co http://svn.symfony-project.com/branches/1.1

o

svn co http://svn.symfony-project.com/tags/RELEASE_1_1_4

desde /data/common/symfony de forma que en /data/common/symfony/1.1 tenemos todo el paquete Symfony y podremos hacer updates directamente para obtener las nuevas versiones. [Nota: Se entiende que este paso serviría para cualquier otra versión de Symfony]

Creado un proyecto symfony

En este momento tenemos configurados convenientemente los 3 vhosts y las librerías de symfony listas para poder trabajar, así que lo que nos falta es configurar un proyecto de Symfony que haga uso de las mismas.

Este tipo de instalación de symfony (SVN checkout) espera que ya exista una estructura de proyecto creada, como este no es el caso, tenemos que procurarnos una, bien a través de la descarga de la SandBox bien a partir de la creación de una sandbox desde nuestra instalación a de Symfony.

[data/dev1.mydomain]              $  cd /data/common/symfony/1.1/data/bin
[data/common/symfony/1.1/data/bin]$  ./create_sandbox.sh
[data/common/symfony/1.1/data/bin]$  rm sf_sanbox.zip
[data/common/symfony/1.1/data/bin]$  tar xvf sf_sandbox.tgz
[data/common/symfony/1.1/data/bin]$  rm xvf sf_sandbox.tgz
[data/common/symfony/1.1/data/bin]$  mv sf_sandbox/* /data/d1.mydomain/

Ahí podemos ver que tenemos correctamente instalada la versión de Symfony (modo sandbox = autónoma = independiente de las librerías en /data/symfony)

[data/common/symfony/1.1/data/bin]$  cd /data/d1.mydomain
[dev1.mydomain]                   $  ./symfony -V

Si todo ha ido bien deberíamos obtener algo tal que:

> symfony version 1.1.5-DEV (/data/common/symfony/1.1/lib)

Reconectando las librerías

Bien, lo que nos interesa ahora es desenchufar el proyecto de la versión incorporada en la SandBox para que haga uso de las librerías descargadas y residentes en /data/symfony. Esto se consigue editando

/data/dev1.mydomain/config/ProjectConfiguration.class.php

<?php

require_once dirname(__FILE__).
  '/../../common/symfony/1.1/lib/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();

class ProjectConfiguration extends sfProjectConfiguration
{
  // ...
}

Ahora que el proyecto ya apunta a las librerías del repositorio podemos eliminar las librerías que vienen con la sandbox:

[dev1.mydomain]$ rm -r lib/symfony/

Seguidamente hacemos un pequeño cambio para que el DocumentRoot apunte a www en lugar de a web.

[dev1.mydomain]$ mv web www

Y modificamos nuevamente:

/data/dev1.mydomain/config/ProjectConfiguration.class.php

<?php

require_once dirname(__FILE__).
  '/../../common/symfony/1.1/lib/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();

class ProjectConfiguration extends sfProjectConfiguration
{
  $this->setWebDir($this->getRootDir().'/www');
}

[En nuestro caso particular hemos tenido un problema ocasionado por el hecho de que symfony se ha instalado en /home/myuser/ y los vhosts (/home/myuser/dev1, /home/myuser/dev2, ...) en realidad están apuntando simbólicamente a /srv/www/, por lo que ha tenido que crearse también un apuntandor a symfony para que compartan el espacio /srv/www/]

El siguiente paso ha sido eliminar /www/sf/ y crear el enlace simbólico a la zona descargada:

[dev1.mydomain]$ rm -r www/sf/
[dev1.mydomain]$ ln -s /data/common/symfony/1.1/data/web/sf/ www/sf

[Aquí nosotros nos hemos topado con un problema del tipo 'You don't have permission to access /sf on this server.' al intentar acceder a alguna de las imágenes de /sf. Esto se ha resuelto modificando la configuración de vhost de Apache para que de permisos al directorio /sf]

De la instalación de la sandbox tampoco nos interesan:

[dev1.mydomain]$ rm -r data/symfony
[dev1.mydomain]$ rm data/sandbox.db

Configuración de más áreas compartidas

En el apartado anterior hemos visto como se ha eliminado el directorio /sf que viene con la distribución de la SandBox para que pase a unificarse en una ruta única para todas los entornos de desarrollo. Estos han tenido que crear un link simbólico a ese nuevo /sf.

Esta misma filosofía se sigue para otra información, que llamaremos estática y que no interesa replicar en cada entorno, para este objeto se piensa en:

1. Tenemos la necesidad de crear una ruta (que no es código) a la que deben tener acceso todos los entornos de desarrollo (por ejemplo /images/user_avatars).
2. Si es algo común (no único de un entorno) se deja en /data/common/
3. Se procede a la creación de los links simbólicos (mediante ln -s) desde los entornos de desarrollo.

Ahora nos quedará configurar el entorno de desarrollo en algún IDE (idealmente Zend o PDT) y configurar el proyecto en algún repositorio de código (idealmente SVN)