Pues bien, cuando nos están mostrando que aquello funciona si vemos que un sospecho piloto con la etiqueta error se pone rojo, lo normal es que preguntemos: ¿Qué significa ese piloto? ¿Estás usted seguro que funciona? Si no funciona no lo quiero, se lo tiene usted que llevar y me trae uno nuevo, con su embalaje original.

Lo que quiero decir es que cuando nos entregan algo nuevo no es normal que los LCDs o los indicadores informen de que algo no está funcionando bien y que hay problemas. ¿Por qué cuando se hace la entrega de un software (desarrollado a medida, llave en mano) no hacemos lo mismo? En este caso, en su defecto tenemos algo muy básico pero no por ello menos efectivo que son los logs. No quiere decir esto que los logs sean algo en lo que debamos centrarnos exclusivamente pero sí que son suficientes para decirle al proveedor, “Sr. Jefe de Proyecto, este entregable no lo aceptamos hasta que esos problemas que ahí se indican no estén resueltos”.

Está claro que un entorno de despliegue dotado de herramientas de monitorización se agradece y es un lujo, pero a veces me conformaría con que el servidor de aplicaciones o el servidor web tenga los logs configurados convenientemente. También podemos prestar atención a las distintas opciones que nos brindan los distintos stacks tecnológicos. En Java tenemos muchas herramientas, pero también las tenemos en PHP o Python.

Y también me gustaría decir:

Empresas que en su sitio web pone que están certificadas en CMMi nivel 3 y sin embargo ponen path absolutos en medio de scripts de PHP ;(

¿Qué objetivos pretende cubrir un sistema de versionado?

1. Identificar de forma sencilla el estado de los fuentes. Esa identificación estará asociada a un instante de tiempo
2. Establecer una codificación que permita distinguir unas versiones de otras
3. Informar sobre qué contiene la versión

Existen muchas propuestas y cada una de ellas se adecua a unas necesidades. Nosotros hasta la fecha usábamos una muy conocida basada en:

• alpha
• beta
• Releases Candidate
• X.Y.Z

La versión alpha es una versión completa desde un punto de vista funcional. El equipo de proyecto debería ser capaz de justificar que los requisitos y expectativas detectadas se han alcanzado. Los que nos dedicamos a esto sabemos que es prácticamente imposible, especialmente en proyectos de más de 6 meses. La entrega oficial de una versión es un punto de inflexión en la relación entre el cliente y el proveedor. Está claro que el proveedor le está transmitiendo al cliente que para el proyecto se encuentra en su etapa final y que es el momento de ir cerrando los temas pendientes (artefactos documentales, sesiones de formación, etc).

La versión beta constituye otro momento importante en la vida del proyecto. Tras la entrega de la versión alpha se recoge comentarios, opiniones, peticiones de cambio, “…es que yo pensaba, yo creía que…” (por ambas partes), el departamento de sistemas añade sus “…esto lo quiero así, si hibernate te genera el DDL eso me da igual…“, y evidentemente si no quieres que el proyecto se te vaya en costes, negocias. Personalmente creo que es una -falsa- negociación porque como proveedor comienzas a ver el final y tu mayor deseo es implantar el proyecto y verlo como ayuda a los verdaderos usuarios finales.

Y luego vienen las versiones RCx, que junto con la versión beta, modelan las distintas iteracciones cliente-proveedor. Así, hasta llegar a la versión 1.0.0 donde se hace entrega oficial de los fuentes y corresponde con la versión que pasa a producción. A partir de ahí, comienza el soporte y mantenimiento que dará lugar a:

• 1.0.Z: Resolución de incidencias sobre la versión 1.0.0
• 1.Y.0: Si aumenta la Y, la Z se pone a cero e implica que se han incorporado mejoras y probablemente resolución de incidencias
• Z.0.0: Conlleva lo anterior pero además implica cambios importantes a múltiples niveles (diseño, funcionalidades, UI, etc..)

Esto es, de forma muy resumida, lo que venimos usando desde hace 2 años. Muy relacionado con otras prácticas de nuestra metodología nos hemos visto obligados a realizar una pequeña modificación e incorporar el concepto Partial Delivery:

1. No están reflejadas en el roadmap del proyecto, no constituyen ningún hito
2. Normalmente vienen originadas por una petición externa al equipo de proyecto
3. Están referenciadas en la herramienta de gestión de proyecto
4. Se podrían haber sustituido por conceptos como revisión propios de los S.C.M. pero resulta más sencillo trabajar con alpha-PD1 que con rev657.

Por aclarar algunos puntos:

1. En nuestro entorno de despliegue, y como parte de las actividades de integración continua, el estado de los fuentes es referenciado como 1.0.0-SNAPSHOT-r2203 o 1.0.0-DEV-r2203. Para la revisión usamos buildNumber.
2. Sólo versionados aquello que necesitamos referenciar.

En ciertos proyectos, por su diseño y base tecnológica, incorporamos otras prácticas. Por ejemplo, en aquellos con un alto índice de modularidad  cada módulo mantiene su propio versionado y las entregas incluyen un documento (o MasterBuild) en el que se detalla o define la entrega. Como ejemplo podemos ver aquellos que se basan en OpenCms o Drupal.

Y tú, ¿Cómo llevas a cabo este proceso?

• 5 meses en total
• 4 meses desarrollando la aplicación
• 1 Jefe de proyecto, 1 desarrollador del lado del cliente, 2 desarrolladores JEE y 1 asegurador de la calidad

Para la construcción hemos contado con:

• Marco tecnológico Java: Spring framework, Eclipse Birt, Hibernate
• ExtJS
• DEIN – Ecosistema Software (de esto ya os hablaré)

Me gustaría contar algunas lecciones que hemos aprendido:

1. Nos es conveniente homogeneizar los entornos de desarrollo local de todos los miembros del equipo. Aunque el cliente nos indique cuál es su entorno de producción y eso quede reflejado en los requisitos no funcionales del análisis, es altamente aconsejable la disparidad. Es una forma muy simple se disminuir riesgos y asegurar un mayor nivel de calidad. Concretamente en este proyecto hemos usado:
   1. Ubuntu, Eclipse, Jetty, JDK 1.5 (entorno de desarrollo local)
   2. Windows XP, Eclipse, Tomcat JDK 1.6 (entorno de desarrollo local)
   3. Debian, Tomcat, Apache, JDK 1.5 (entorno de despliegue virtualizado que DEIN proporciona)
2. Las tareas de análisis nunca terminan. Cuando el analista decide que hay una versión estable de los requisitos y se ponen en marcha las tareas de implementación, se activa un proceso iterativo entre el diseño-implementación y el análisis. El objetivo final para el cliente es que lo que le entreguemos satisfaga sus espectativas, sin embargo, nosotros compartimos ese mismo objetivo y además tenemos que asegurarnos de que lo construido y lo analizado está sincronizado y se corresponden. ¿Por qué? Porque aunque sean desarrollos a medida (llave en mano) es probable que surjan ampliaciones, revisiones, etc. y por eso mismo tenemos que ser consecuentes con lo que hacemos. No es la primera vez que me encuentro un documento de análisis perfectamente maquetado con una página inicial en la que se indica que lo validó tal persona hace un año y recientemente se ha publicado una versión.
3. Es importantísimo hacerle ver al cliente cuánto cuestan los cambios y todo lo que adicionalmente solicita. Entiendo que es una tarea complicada, pero ahí está la destreza de un buen jefe de proyecto. Lo que no podemos hacer es admitir cambios y mejoras durante la evolución del proyecto con el fin de mejorar la experiencia de los usuarios finales, y que luego, cuando el proyecto está terminando te inunden en procesos eternos llenos de burocracia.
4. En tu planificación prioriza al máximo el obtener una primera release que puedas mostrar a los usuarios finales. Haz todas las entregar parciales que puedas y la disponibilidad del cliente permita. En este proyecto concretamente, el cliente ha tenido la oportunidad de ver todos los avances de forma diaria. DEIN se encargaba se desplegar todas las noches un SNAPSHOT del proyecto en el entorno de despliegue, que por supuesto estaba disponible para el cliente.
5. Establece sesiones de trabajo (preferiblemente, semanalmente) con todos los miembros del equipo. Aprovecha esta sesiones de trabajo para hacer una puesta en común de perspectivas, dudas, aclaraciones, consideraciones, propuestas, etc…
6. Procura que todos tus proyectos tengan algo de I+D+I. Disponer de un departamento de verdad de I+D+I no es sencillo y requiere inversión, pero cuando no se tiene esa opción, algo debemos hacer. Cuidado con los experiementos en proyectos pequeños, es muy sencillo incumplir en la planificación si algo no sale todo lo bien que esperábamos.

Supongo que la lista podría continuar, pero son los que puedo contar y pueden ser útiles. En cuanto me autoricen, publicaré algunas capturas de pantalla (y con suerte un screencast) sobre el proyecto.

Algo que debe formar parte de todo buen ecosistema software que se precie es un conjunto de buenas prácticas que recomienden cómo debemos usar las herramientas que lo forman. En este caso hablaremos de subversion, el sistema de control de versiones que uso. Gracias a las propiedades de subversión podemos controlar:

1. Los terminadores de línea
2. Los tipos mime de los archivos
3. Los archivo que siempre ignoramos y que proyecto tras proyecto tenemos que ignorar. ¿El directorio /target tal conocido por aquellos que usan Maven? ¿El directorio /build?

Pues bien, para evitar que cada vez que se añada un archivo tengamos que configurar sus propiedades svn, que mejor forma que tener todas esas propiedades bien definidas en un archivo y que se usen en el ecosistema.

A continuación se muestra el archivo de configuración que estoy usando en Opina para las propiedades svn:

#
# Opina: gestor de encuestas
# Copyright (C) 2005-2008 Opina Development Team
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of version 2 of the GNU General Public
# License as published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA
#
# $Id: opina-svn-properties 1842 2008-10-09 19:46:18Z recena $
#

[auto-props]
*.sh         = svn:executable;svn:eol-style=native;svn:keywords=Id
*.bat        = svn:mime-type=text/plain;svn:eol-style=CRLF
*.bmp        = svn:mime-type=image/bmp
*.class      = svn:mime-type=application/java
*.doc        = svn:mime-type=application/msword
*.exe        = svn:mime-type=application/octet-stream
*.gif        = svn:mime-type=image/gif
*.gz         = svn:mime-type=application/x-gzip
*.jar        = svn:mime-type=application/java-archive
*.jpg        = svn:mime-type=image/jpeg
*.jpeg       = svn:mime-type=image/jpeg
*.pdf        = svn:mime-type=application/pdf
*.png        = svn:mime-type=image/png
*.tgz        = svn:mime-type=application/octet-stream
*.tif        = svn:mime-type=image/tiff
*.tiff       = svn:mime-type=image/tiff
*.zip        = svn:mime-type=application/zip
*.txt        = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.xml        = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Id
*.xsd        = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Id
*.xsl        = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Id
*.wsdl       = svn:mime-type=text/xml;svn:eol-style=native;svn:keywords=Id
*.htm        = svn:mime-type=text/html;svn:eol-style=native;svn:keywords=Id
*.html       = svn:mime-type=text/html;svn:eol-style=native;svn:keywords=Id
*.css        = svn:mime-type=text/css;svn:eol-style=native;svn:keywords=Id
*.js         = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.jsp        = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.txt        = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.java       = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.properties = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id
*.sql        = svn:mime-type=text/plain;svn:eol-style=native;svn:keywords=Id

Una vez que tenemos configuradas nuestras propiedades tenemos que hacer dos cosas:

1. Indicarle a nuestro cliente de subversion que estas propiedades existen y tienen esos valores
2. Indicarle a nuestro cliente de subversion que las tenga en cuenta.

En mi caso uso subversive como cliente de subversion, es un plugin para Eclipse. Para importar estas propiedades hacemos lo siguiente: Windows > Preferences > Team > SVN > Properties Configuration > Automation properties > import. Una imagen mejor, ¿no?

Ahora debemos localizar el archivo de configuración que el cliente usa:

~/.subversion/config (Linux)
%USERPROFILE%\Application Data\Subversion\config (Windows)

Ahora cambiados dos propiedades en ese archivo de configación

global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store build dist target
enable-auto-props = yes

Espero que esto ayude un poco a aquellos desarrolladores que son un poco despistados y se olvidan de configurar convenientemente las propiedades svn. Ahora el siguiente paso es hacer hook (pre-commit) que se encargue de que las cosas están bien configuradas, y en caso contrario, envíe un correo al QA para repartir collejas.

El diseño e implementación de tests son actividades muy importantes y necesarias en el ciclo de vida de un proyecto software. Estas actividades forman parte de una disciplina denominada aseguramiento de calidad del software. Recientemente he llegado a la conclusión de que son esos pequeños detalles, que normalmente se dejan pasar por alto, los que más tiempo nos hacen perder a la hora de realizar un paso a producción. Realizar un paso a producción tiene sus connotaciones, y una de ellas es que normalmente o se realizan en las instalaciones del cliente o las realiza el propio cliente. Podríamos considerar en lugar del cliente, al usuario final para así dejar a un lado la parte empresarial de la profesión.

Con intención de recoger esos tests que nos adviertan de esos pequeños detalles, he preparado el siguiente listado de tests que incluiré por regla general en mi plan de tests para proyectos Java:

1. Comprobar que la JVM que hay configurada en el sistema operativo es válida según el catálogo de requisitos no funcionales. Eso no evitará que si nuestra aplicación se despliega sobre un contenedor o servidor de aplicaciones, éste esté configurado con una JVM distinta a la del S.O., pero esta situación es menos frecuente.
2. Si nuestra aplicación necesita una base de datos, comprobar que la configuración es correcta y que la versión y base de datos están recogidas en el catálogo de requisitos no funcionales.
3. Realizar una comprobación como la anterior para servicios como directorio activo, correo electrónico, etc. De esta forma, podremos descartar problemas de integración con sistemas externos a nuestro software.
4. Si nuestro software necesita escribir en el sistema de ficheros, comprobar que disponemos de los permisos correspondientes.
5. Si nuestro software necesita acceder a internet o fuera de una red de área local, realizar la correspondiente comprobación.

Estos tests son muy simples pero nos ayudarán a detectar posibles problemas de integración con el entorno donde nuestro software se tiene que instalar. ¿Alguna sugerencia para añadir a estas pruebas de carácter muy básico?

John tiene una empresa llamada Wakaleo Consulting en la que ofrece servicios profesionales sobre:

• Software Development Environment
• Enterprise Java Kickstart
• Training, Mentoring and Coaching

Hace algún tiempo comentaba algo sobre aquellas empresas que ofrecen servicios muy especializados sobre procesos de construcción de software, metodologías, buenas prácticas, herramientas como Maven, PMD, etc. Pues Wakaleo parece ser otra de ellas. Me sigo preguntando si estas empresas tienen cabida en el mercado español…

John ha publicado las transparencias que ha usado en una de sus últimas ponencias en las que habla sobre JUnit.

La verdad es que en la nueva versión de Opina comenzamos a usar JUnit 4 pero ahora estamos evaluando TestNG y el cambio me ha gustado mucho. Personalmente no fui el promotor del cambio, sino mi compañero José María. Todo vino a raíz de necesitar hacer una provisión de datos en la que hemos usando XStream y poder configurar el orden en el  que se ejecutan las pruebas. Con independencia de que también hemos organizado las pruebas en grupos para darle forma a las operaciones CRUD que usamos en nuestras pruebas unitarias.

En esas estructuras de directorios normalmente encontramos ficheros compilados (p.e, .class), archivos de propiedades (p.e, .properties), archivos de configuración (p.e, .xml), recursos gráficos (p.e, .png), metainformación (p.e, manifest.mf) y algunos otros más. Personalmente me gustaría destacar todos aquellos archivos que formen parte de la configuración de una aplicación. Las configuraciones más comunes son las referentes a la conexión de base de datos, sistema de correo, sistemas LDAP, etc.

Una muy buena aproximación para mejorar la facilidad de mantenimiento, automatización y personalización de estos “distribuibles” es usar Maven y sacarle partido a los distintos plugins que existen (packaging types / tools) y la gestión de perfiles. Con esto podremos conseguir generar el WAR de nuestra aplicación web configurado para el entorno de producción de nuestro cliente. Bastará con realizar un proceso como el siguiente:

1. Realizar un export del sistema de control de versiones correspondiente a la versión que se desee, que entiendo que estará etiquetada en directorio tags de nuestro repositorio.
2. Dar de alta un perfil con la configuración del entorno que nuestro cliente nos ha facilitado.
3. Ejecutar algo similar a: mvn package -P oracle -Denv=client-dev
4. Desplegar, manual o automáticamente, nuestro WAR (artefacto) donde corresponda.

Doy por supuesto que los miembros del equipo de desarrollo estarán muy familiarizados con la generación de estos distribuibles, sin embargo, son otros perfiles los que, durante el desarrollo del proyecto y/o tras su finalización, tendrán que continuar con su soporte, mantenimiento y evolución. Un ejemplo con el que muchos se pueden sentir identificados es el típico proyecto de llave en mano para un cliente que nos encarga algo a medida. En ese contexto, si el cliente nos demanda que le enviemos un SNAPSHOT para que su personal vaya haciendo pruebas, ¿Qué “distribuible” preparamos?

Es muy frecuente que si se trata de un proyecto software, haya sido un departamento, área o división de desarrollo quien nos haya realizado el encargo. Con esto quiero decir, que el perfil que va a recibir nuestro “distribuible” es probable que con unas simples instrucciones sea capaz de generar el “distribuible” apropiado a partir de un export del repositorio. Ahora bien, no basta con hacer un export, comprimirlo y enviarlo al cliente con las instrucciones, entre otras porque en el repositorio es muy probable que haya información sobre nuestros entornos de desarrollo, múltiples perfiles configurados o simplemente, información que no es útil para el cliente y que únicamente provoca ruido. Con lo cual, parece razonable pensar que vamos a necesitar un “distribuible” con las fuentes de nuestro proyecto que, acompañadas de una guía de instalación y configuración, permitan que el propio cliente pueda ir asumiendo estas tareas que tarde o temprano serán de su plena responsabilidad.

La opción planteada me parece lógica. El cliente nos demanda las fuentes del proyecto, nosotros se las entregamos con los archivos justos y precisos que necesitan para la configuración, pruebas unitarias/integración y la posterior generación del WAR, JAR, AAR o el que corresponda, que se desplegará en el entorno correspondiente.

Con la intención de dar un pasito más y pensando en los perfiles del departamento, área o división de infraestructuras, creo que agradecerán si les ahoramos hacer un export, tener instalado maven, tener instalado el JDK correspondiente y otros pequeños detalles que pueden hacer que algo fácil y mecánico, se retrase durante días. En prácticamente todas empresas e instituciones que conozco es el personal de sistemas o infraestructuras quien verdaderamente realizara los despliegues en los entorno de producción, por lo tanto, nos interesa facilitar al máximo las cosas.

Entiendo que para un administrador de sistemas le resultará más cómodo descomprimir un archivo comprimido (zip, tar.gz, etc.), editar el archivo de configuración que estará documentado en la correspondiente guía de la que antes hablaba y colocar la estructura de directorios y archivos en el lugar correspondiente para su despliegue. Este nuevo caso nos encontramos con que necesitamos preparar un “distribuible” con los binarios de nuestro proyecto.

Son muchas las circunstancias que puede hacer que el administrador del servidor de aplicaciones del cliente necesite volver a desplegar una aplicación determinada, como por ejemplo, cambios en la configuración de red, DNS, modificaciones en las credenciales (usuarios/contraseñas), migraciones, etc, ¿En todas esas situaciones es necesario que haya un desarrollador presente? Si las cosas se hacen bien, podemos ahorrarnos mucho trabajo. Tengo que reconocer que la realidad es otra, pero lo bueno es saber que existen otras formas de hacer las cosas.

Para concluir me gustaría añadir que aparte de lo que podamos generar en nuestra fase de empaquetado (package) y que además lo tenemos automáticamente con Maven, es muy recomendable preparar al menos otros dos “distribuibles” adicionales, uno con los fuentes y otro con los binarios. Para ello es de gran utilidad el plugin de Maven Assembly. Como me he extendido demasiado, aprovecharé otro post para poner algún ejemplo con este plugin. En Opina lo usamos para generar opina-bin-1.0.8.zip, que es el binario de la versión 1.0.8 de Opina que está listo para ser descargado, descomprimido, configurado y desplegado.