Bueno ya llevo mis primeras semanas dedicadas al tema de Arquitectura de Plataforma y sumergiéndome en el mundillo del desarrollo Java, aunque sea desde el punto de vista no ya del desarrollador sino de la gestión de sistemas y la organización de proyectos. El primer punto en el que queríamos focalizar los esfuerzos es en la gestión de entornos: desarrollo, pre-producción y producción y el paso que realizan los proyectos a través de estos.
Primero describir el escenario inicial: existen diversos grupos de desarrolladores trabajando en varios proyectos, muchos de ellos interelacionados entre si. Este proceso de desarrollo muchas veces se realiza en la propia máquina de los desarrolladores y se va subiendo a un repositorio común, en nuestro caso subversion. El problema aparece cuando se intenta llevar una versión a producción y esto se hace desde el equipo de algún desarrollador, por lo que en muchos casos ese código ni ha subido aún al subversion, se tienen instaladas librerías o versiones del JDK que no se corresponden con las que hay en producción, no queda registrada que versión pasa a producción y cuál había, otras veces el proyecto se compila dentro de la máquina de producción, etc… es decir, en el caso de un desarrollo ya medianamente grande se va creando un pequeño/gran caos.
Para solucionar este problema hemos desarrollado el siguiente esquema de funcionamiento en el que encontramos una pieza clave: el servidor de integración.
Todas las «piezas» que se quieran pasar a producción deberán ser construidas en este servidor de integración y además siempre se obtendrán todos los elementos necesarios para la construcción del sistema apartir del control de versiones.
Con ello matamos varios pájaros de un tiro:
– Tendremos controlada la versión de los proyectos desplegados, sobretodo si generamos un Tag de subversion tras la compilación correcta.
– El entorno de construcción está controlado, siempre se usará la misma versión de la máquina virtual, librerías, etc… y nos aseguraremos que en producción dispongamos de ese mismo entorno.
– No requeriremos de compiladores ni dependencias de ese tipo en los entornos de producción, cosa que es altamente recomendable por motivos de seguridad.
– Los desarrolladores ya no tendrán acceso a las máquinas de producción, simplemente tendrán que solicitar una nueva compilación de su proyecto al servidor de integración y los encargados de sistemas lo pasarán a pre-producción y una vez probado a producción.
Buscando alguna interfaz que nos permita hacer más amigable el proceso de compilación de proyectos en una máquina remota me he encontrado con los llamados servidores de integración continua, a los que dedicaré un post individual, pero que nos pueden facilitar enormemente esta tarea además de darnos algunas ventajas adicionales.
Por otro lado hemos descubierto que no debemos basarnos únicamente en los elementos ejecutables que pasan a producción, sino que en muchos casos habrá que hacer subidas también de datos requeridos para el funcionamiento de la aplicación: modificaciones a las bases de datos o al LDAP o directorios con ficheros necesarios. Estos objetos se empaquetarán junto con la consiguiente nueva versión del proyecto y deberán gestionarse de forma paralela a este, tanto en versionado cómo en su posterior subida a producción.
Finalmente otra gran ventaja la encontramos al disponer de entornos de pre-producción para cada proyecto que nos permitan probar las nuevas versiones de las aplicaciones antes de pasar a producción. Una buena infraestructura de virtualización nos puede ser de gran ayuda en esta parte ya que nos va a permitir tener multiples entornos dentro de un mismo servidor compartiendo recursos.
