Así que en Sixservix hemos decidido llamar a  Alberto Vilches para que nos cuente todo esto. Seguro que ya muchos de vosotros le conocéis, Alberto es un desarrollador con más de 10 años de experiencia en estas lides, javero de pro que famélico de nuevas tecnologías decidió hace un par de años devorar todo lo referente a este nuevo lenguaje.

El viernes 4 de Marzo a partir de las 17:00h le tendremos en nuestras instalaciones para que nos cuente qué es Groovy y por qué no podemos pasar ni un día más sin utilizarlo.

Esto me ha obligado a buscar otras opciones. Pues googleando un poco encontré las librerías de glassfish para añadir nuevas task a Ant. Para conseguir que esta librería nos funcione en nuestros scripts de Ant simplemente tendremos que anadir a nuestro path:

<path id= “glassfishtask.classpath”  >
<fileset dir= “./lib/” >
<include name= “**/*.jar” />
</fileset>
</path>

En esa ruta tendremos que situar todos los jars de administración de glassfish, sí, son unos cuantos. Os dejo una captura de pantalla para que los veáis.

Ya tenemos todo este churro de librerias en nuestro path. Ahora le tenemos que decir a Ant dónde está el descriptor que define las tareas que puede usar, para esto añadimos esto a nuestro script:

<typedef resource=”com/sun/tools/appserver/antlib.xml” classpathref=”glassfishtask.classpath” />

Concretamente este xml se encuentra en el sun-appserv-ant.jar, uno de los que hemos añadido. Pero además en el pantallazo vemos una carpeta lib. Esto es la pequeña chapucería (xD) que he tenido que hacer para que esto funcione, y es que hay que copiar “config”  situada en la raiz de nuestra instalación de glassfish (p.e. d:/glassfish/config ).

Ahora ya tenemos todo lo que necesitamos para empezar a trabajar. Os dejo un ejemplo de una tarea:

<target name=”deploy-INT” description=”Despliega la aplicacion” >
<sun-appserv-deploy file=”${dist}/Storetto.ear”
name=”Storetto”
force=”true”
precompilejsp=”false”
verify=”false”
createtables=”false”
upload=”true”
user=”admin”
passwordfile=”glassfishpassword.txt”
host=”172.16.18.99″
port=”4848″
asinstalldir=”D:/hudson/lib” />

Muy importante es el atributo “asinstalldir” , el cual debe apuntar a donde tengamos nuestras librerias y nuestra carpeta config.

Espero que os sirva de ayuda, gracias.

Actualmente en el proyecto en el que estoy involucrado (Storetto) tengo que reconocer que hemos dejado un poco dejado de la mano de Dios este asunto. Hacemos las subidas usando la técnica “manubrio”, muy funcional, pero arcaica y muy dada a fallos (compilamos con nuestros propios IDE’s y realizamos la subida). Esto nos produce multitud de quebraderos de cabeza debido, principalmente, a que no es lo mismo una subida a producción, integración o desarrollo en cuanto a archivos properties y xml’s.

Después de algún susto y viendo lo poco productivo que supone hacer eso así hemos decidido arrancar este camino hacia la integración continua. Con menos verguenza que el destista de Pedro Guerra nos embarcarnos en esta aventura.

En un entorno de integración continua deben intervenir muchos actores : el proyecto a integrar, una sistema de control de versiones, test, una manera de construir ese proyecto y de integrarlo. Veamos qué tenemos. Ahora mismo cuento con un sistema de control de versiones subversion, algo que sí que no nos podía faltar, con el proyecto propiamente dicho y…. poco más.  Así que habrá que empezar por alguna parte, y como no se puede comenzar la casa por el tejado (el servidor de integración continua) creo que comenzaremos por algo que nos ayude a construir el proyecto: usaré Ant, sencillo y efectivo. En este humilde artículo os intentaré mostrar cómo he resuelto yo este problema, pero no voy a poner todo el fichero build.xml que he creado (sería muy repetitivo) sino sólo las partes más interesantes, y tampoco será una guía de Ant, por lo que daré muchas cosas por supuestas.

Pues nada, manos a la obra. Crear un script de ant que compile que se actualize tu proyecto, compile y genere los jar, war y finalmente tu ear realmente no es excesivamente difícil. Como ya he dicho algo que quería era actualizarme el proyecto de mi svn cada vez que contruyera la aplicación. Para conseguir que Ant tenga soporte para svn he tenido que “parchear” o meterle un pluggin . Podría enrollarme contando cómo hacerlo, pero creo que no tiene mucho sentido y prefiero dejaros la web de donde yo lo hice . Es bastante fácil, a grandes rasgos consiste en bajarte unas fuentes, compilarlas y referenciar en tu script de ant a el “jar” generado.

Antes de continuar con nuestro script, tendremos que hacer un checkout de nuestro proyecto. El lugar donde lo hagamos es indistinto, luego configuraremos una propiedad en nuestro script que apuntará al proyecto. Se me pasó por la cabeza hacer un checkout cada vez que se lanzara la tarea y luego borrar todos los archivos; esto estaría bien si se tratara de un proyecto pequeño, pero en mi casa no es sostenible, el script tardaría una barbaridad en bajarse todo y luego en borrar todo de nuevo. Así que me creo una especie de repositorio de fuentes

Primero tenemos que definir una serie de propiedades que serán usadas a lo largo de todo el script. Sobra decir la utilidad que tiene esto a la hora de pasarle a otra persona el script o cambiarlo de ubicación, etc…. . Estas son alguna de las que yo he utilizado:

Mi problema principal a la hora de realizar las subidas era el tener que renombrar ficheros de propiedades dependiendo de a donde fuera a subir el archivo generado. Así que la primera tarea Ant que se debe ejecutar en mi script será la que decida a que entorno subir, para eso creamos una estructura similar a esta:

Que nos permite llamar a una u otra tarea dependiendo de la construcción que queramos hacer y simplemente poniendo en la línea de comandos >ANT PROD/LOCAL. Veamos una de estas tareas:

Esta tarea cómo se puede ver, crea la carpeta donde copiaremos los archivos que cambian dependiendo de la construcción, los renombra y llama a otro target de Ant, ese target será al que todos los “modos de despliegue” llamen. Ahora usaremos la típica estructura de dependencias de Ant. Llamaremos al target “generate-ear” que dependerá de otro target, ese a su vez de otro, etc.. para crear una estructura secuancial de acuerdo con nuestras necesidades de despligue. Vamos a ver algunos ejemplos:

Primero creamos los directorios, puede ser que sea la primera vez que lanzamos el script. Y luego, como de pequeño me enseñaron que había que dejar las cosas según las encontraras, vaciamos su contenido. Creamos dos directorios, una donde iremos poniendo los compilados y ficheros que necesitemos para constriur nuestros ficheros de despliegue y otro donde depositaremos nuestros ficheros ear,war,xml que usaremos más tarde para crear el fichero ear.

Una vez que hemos barrido nuestra casa, procederemos a actualizar nuestro proyecto, veamos cómo:

Lo siguiente que vamos a hacer es contruir nuestro jar de modelos de datos. Storetto utiliza como sistema de acceso a datos EJB 3.0. Éstos van empaquetados , juntos con muchas otras cosas en un jar. Veamos cómo lo construimos:

Como se puede ver la técnica a seguir es compilar y copiar todos los archivos que queremos que formen parte de nuestra jar a un directorio “temporal”, para finalmente lanzar la tarea “jar”. Esto lo repetiremos tantas veces como ficheros .war o .jar necesitemos crear para nuestro fichero EAR. Una vez creados todos estos ficheros se lanzará la generación del fichero de despliegue:

Evidentemente esto son sólo algunos casos, sirvan cómo ejemplo de cómo construir un fichero de despliegue. Con esto ya hemos dado un paso adelante. Hemos conseguido unificar la construcción de nuestro proyecto. Este script ant nos valdrá, con algunos retoques, para los siguientes pasos en nuestro camino hacia la Integración Continua total. En el día a día de un equipo de desarrollo pequeño e invuclado en una puesta en producción no es factible abordar toda esta tarea de una sola tacada, así que volveremos a la carga con los siguientes pasos en nuestro camino : Test Unitarios y/o instalación de un servidor de integración continua Hudson.

Hace poco descubrí una herramienta que desconocía y que puede llegar a ser muy útil, sobre todo para copias datos entre diferentes base de datos: los Database links.  ¿Qué narices es esto?. Pues muy sencillo, es un “enlace” entre dos base de datos,dicho de manera algo profana. De esta manera puedo tirar sentencias estando conectado desde una DDBB A a una DDBB B. Veamos un ejemplo :

SELECT * FROM usuarios@varma2

Siendo “varma2″ en nombre de Database link. Simplemente habrá que ponerlo inmediatamente a continuación del nombre de la tabla seguido de una arroba. Es bastante sencillo. Veamos cómo crear uno:

CREATE DATABASE LINK varma2
CONNECT TO "usuario"
IDENTIFIED BY "password"
USING '(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST =
MiHostname)(PORT = 1521)) (CONNECT_DATA = (SID = VARMA2)))'

Esta sentencia bastaría con ejecutarla desde la bbdd A, llamemosle VARMA1, desde la que deseariamos lanzar las consultas contra esta bbdd identificada con el SID = VARMA2 Podríamos crear una relación circular entre ambas simplemente creado otro enlace desde VARMA2 que apuntara a VARMA1

CREATE DATABASE LINK varma1
CONNECT TO "usuario"
IDENTIFIED BY "password"
USING '(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST =
MiHostname)(PORT = 1521)) (CONNECT_DATA = (SID = VARMA1)))'

Ya tenemos creados nuestros links entre ambas base de datos. Ahora las posiblidades son infinitas, ya que podremos realizar consultas, borrados, insercciones de una manera muy rápida entre ellas. Fijaros en esta sentencia:

INSERT INTO usuarios (select * from usuarios@varma1)

Podremos hacer migraciones de datos sencillas y muy rápidas sin tener que usar las herramientas exp/imp, mucho más potentes, pero mucho engorrosas.Por último, os preguntareis, donde consulto los links que tiene creados mi bbdd, muy fácil, la tabla de sistema que soporta esto es : “all_db_links”.

Espero que os sirva de introducción y de ayuda, al menos tanto como me ha sido útiles para mi. Los Database links tienen muchísimas más opciones y posibilidades, pero creo os ayudará mucho mejor un buen manual de Oracle.

¿Por qué este blog?. La idea de este blog es llevar día a día una bitácora de mi trabajo, publicar todas las ideas que crea interesantes para compartir y que crea que pueden aportar algo, tanto a otras personas como al día a día de mi trabajo, y generar un feedback con otros técnicos que nos puedan enriquecer a todos.

Sin más dilación, bienvendos a éste, mi humlide blog.

Alea jacta est.