subscripción
Blog de Julio César Pérez Arques
Historia de una integración (i): El principio
Marzo 31st, 2009 - [Enlace local]
Esta es la historia de un proyecto de desarrollo software. Como toda buena historia tiene momentos difíciles, personajes complejos, un final féliz y más de una lección que aprender.
Antecedentes
En enero del 2008 comenzó una nueva etapa profesional para mi, cambié de compañía en búsqueda de nuevos retos y proyectos donde trabajar, y continuar aprendiendo, en lo que verdaderamente me apasiona, las nuevas tecnologías de desarrollo software. Atrás dejé una cómoda posición como Analista en una factoria de software al cargo de varios aburridos y antediluvianos proyectos de mantenimiento de una importante TELCO.Así me encontré al frente de un equipo de desarrollo de 3-6 personas, residente en un importante cliente del sector sanitario público, y dirigiendo un buen número de proyectos Java, consistentes en nuevos desarrollos y mantenimientos.
Pero no sólo yo tenía ganas de cambios para el 2008. En una decisión tan valiente como inesperada, el cliente decide implantar un completo sistema SAP R/3 para sustituir la gran mayoría de sus sistemas de gestión.
Para esta obra faraónica se ha confiado en la típica pirámide de empresas, compuesta por (i) la super multinacional que aporta el nombre, más la élite, (ii)
El proyecto
Mi parte en la historia sería la de dirigir un proyecto consistente en desarrollar una aplicación web Java que hiciera de front-end para varios módulos del futuro SAP R/3 del cliente. El proyecto empezó oficialmente en junio con la idea de llevarlo de forma paralela a la implantación de SAP. El objetivo era poner en funcionamiento una primera versión para el 1 de enero del 2009 para un número de usuarios controlado y poco a poco ir difundiendo su uso. A día de hoy la aplicación está implantada de forma completa y funcionando estable y eficázmente.Como os imaginaréis ha sido una experiencia apasionante pero también muy exigente. Aunque me ha hecho pasar más de un trago amargo, en general estoy satisfecho con su resultado final y sobretodo con lo aprendido por el camino. Un camino que intentaré plasmar en esta serie de posts que espero se conviertan en un útil ejercicio de retrospectiva al que estais todos invitados.
Ecosistema software
No quería cerrar el post sin contar algo de verdad. Así que describiré las distintas partes que forman el ecosistema software que he ido construyendo desde mi llegada.- Eclipse. Una de las primeras decisiones que tomé fue usar Eclipse JEE como ide principal, por su potencia como editor e integración con el resto de herramientas y librerias que usamos. Anteriormente se usaba una antiquísima versión del IntelliJ IDEA pero no entraba en los planes corporativos adquirir licencias más modernas.
- CVS. Es el sistema de control de versiones que tiene implantado nuestro cliente para todos sus proyectos. No hay más. Mi parte aquí se redució a fomentar algunas buenas prácticas de uso, principalmente a incorporar las dependencias de cada proyecto en su estructura.
- Tomcat. Las aplicaciones se implantan en un servidor JBoss 3.2.6 y en un 4.2.2 las más recientes, pero en desarrollo usamos un Tomcat 6 como servidor individual por su mayor velocidad de arranque y fácil integración con Eclipse. Nuestras máquinas de desarrollo no son ninguna maravilla y Eclipse no se integra con JBoss 3.2.6 por si solo (sí con el 3.2.3), para ello necesitabamos las JBoss Tools. Pero entonces todo el entorno iba a pedales, cuando con Tomcat 6 vuela.
- ANT. El cambio a Eclipse-Tomcat y el hecho de incoporar las dependencias a la estructura de proyecto obligó a crear nuevos scripts Ant para automatizar las tareas de construcción de los proyectos. Aunque sólo los nuevos proyectos y los antiguos más significativos han sido migrados al nuevo entorno.
- Hudson. No fue hasta el último trimestre cuando conseguimos implantar Hudson como servidor de integración continua. Actualmente realiza las tareas de construcción, testing unitario y análisis de código Java con los plugins de Emma, Checkstyle y Findbugs.
- JIRA. Como herramienta de gestión de proyectos/tareas continuamos usando una antigua versión de JIRA. Es una maravilla y eso que no creo que estemos aprovechando todas sus posibilidades. Sólo echo de menos un wiki principal para todos los proyectos o individual por proyecto.
- Selenium. Hemos estado experimentando con Selenium para hacer testing funcional de aplicaciones web. Sin embargo estamos teniendo problemas a la hora de ponerlo en funcionamiento en el Hudson. Lo que está dificultando mucho su aceptación y uso generalizado. Aún así lo encuentro básico para dar el siguiente paso de calidad en nuestro modelo de desarrollo. Todos sabemos el infierno que es actualmente el desarrollo web...
- Maven. Aunque Ant es una herramienta genial, el elevado número y hetereogeneidad de proyectos que llevamos hace difícil el mantenimiento de los scripts. Por eso y otras razones quiero probar Maven en uno o dos proyectos serios.
- Mylyn. Mylyn es un plugin para integrar Eclipse con la mayoría de sistemas de control de tareas/tickets de forma avanzada. No sólo permite tener visibilidad de los tickets en Eclipse, también dota de memoría a Eclipse para recordar qué ficheros del proyecto están asociados con cada tarea. Con lo primero espero, sobretodo, mejorar la trazabilidad entre lo que hace el código realmente y lo que dice la descripción de la tarea.
- Wiki. Tengo ganas de probar una wiki para gestionar la documentación interna que vamos generando, en lugar de, como hacemos ahora, crear y copiar documentos word a una carpeta compartida. También me gustaría probarla como herramienta de especificación de requisitos de los proyectos con capacidades reales de colaboración y control de versiones automatizado. La idea sería enlazar desde la descripción de las tareas en el Jira a las páginas del wiki.
