Historia de una integración (i): El principio

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) la cárnica el grupo hispano líder que aporta referencias de éxito en proyectos similares más la clase media y (iii) la empresa regional con aspiraciones que aporta el toque local, instalaciones y una masa de programadores a buen precio. Una organización digna de un imperio persa.

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.
Mis planes para este año implican las siguientes mejoras:
  • 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.
Con ésto doy por terminada esta primera parte de introducción y ecosistema. En la segunda me centraré en la arquitectura de la aplicación.

9 comentarios :: Historia de una integración (i): El principio

  1. Como Wiki, una buena posibilidad si ya usais JIRA es el Confluence, ya que se integra muy bien y tiene algunos plugins para mostrar tablas con los issues etc. que pueden ser muy utiles.
    Y además desarrollar tus propios plugins para añadirle funcionalidad es relativamente sencillo.
    Yo de momento con los proyectos me quedo en Ant+Ivy, todavía el Maven no me ha llamado suficientemente fuerte :).

  2. Has probado trac( http://trac.edgewall.org/)?. Permite una buena integracion entre un gestor de tareas(tickets) y svn, además incorporar wiki, tiene diversos plugins que permiten extender su fucionalidad.

  3. Trac está muy bien, se integra con Mylyn y ya lleva un wiki. Pero necesitas una instancia de Trac por proyecto. No tiene nada de gestion multiproyecto. Algo que para mi es básico porque entre desarrollos, evolutivos y soportes llevamos más de 10 proyectos.

    La gestión multiproyecto de Jira es genial, puedo configurar vistas con información de las tareas en ejecucion de todos los proyectos además del horizonte de trabajo en la misma pantalla. Con Trac que yo sepa no se puede hacer.

    Lo malo de Jira es que es bastante caro, pero aqui ya lo tenian cuando llegué...
    Desgraciadamente no tienen más aplicaciones de la suite de Atlassian, así que para la Wiki estamos pensando en XWiki (http://www.xwiki.org/xwiki/bin/view/Main/WebHome)

    Gracias por participar a los dos.

  4. Genial entrada, a la espera de la arquitectura que habéis implantado.
    Por otra parte, me lastima conocer el manejo de recursos humanos realizado. Al final, los que no curran y tienen enchufes son quienes ganan más.

  5. La idea del wiki me parece genial como sistema de documentación, nosotros lo hemos estado usando para el fin que tu propones, por otra parte si he visto ciertos inconveniente con los requisitos ya que en wiki es dificil manejar el versionado y cómo en cualquier momento te pueden cambier el requisitos.

    Saludos.

  6. Creo que para la cuestión de integrar selenium y hudson, se podría utilizar WebDriver. Lo malo: sería necesario escribir las pruebas en Java. Lo bueno: Puede integrarse fácilmente con Ant.

  7. @Miguel ¿Qué usais vosotros para la gestión de requisitos? Yo encuentro más dificil de seguir los cambios cuando has creado 4-5 tareas sobre la misma pantalla. Sin embargo en la wiki sí sería una única pantalla. Además todas las wikis decentes llevan un registro de cambios automático.

    @Gilbert Gracias, no conocía WebDriver! Le he echado un ojo, es un API construido sobre Selenium. Nosotros usamos Selenium RC para crear tests y en local se ejecuta sin problemas.

    El problema es cuando Hudson ejecuta los tests. Nuestro Hudson se ejecuta como un servicio de un servidor Linux. Selenium RC necesita que el equipo tenga instalado el navegador y que tenga una salida gráfica. Estamos probando con Xvbf pero necesitamos dedicarle más tiempo.
    ¿Sabes si WebDriver tiene las mismas restricciones? En la web no especifican casi nada...

  8. Yo para los tests automáticos desde Ant estoy usando el HtmlUnit, no he mirado si requiere salida gráfica pero no usa nada gráfico así que no creo.
    Eso y un contenedor embebido para poder arrancarlo desde los tests JUnit. Bueno, en realidad un proyecto propio para poder probar con distintos contenedores embebidos :).
    Eso si, como han dicho antes los tests que hay que hacerlos "a mano", pero a cambio puedes hacerlos bastante precisos.

    S!

  9. @Daniel tiene buena pinta ese proyecto tuyo. Voy a echarle un vistazo y ya te cuento en javaHispano.

    HtmlUnit es la otra opción que hemos tenido en cuenta. Lo que pasa es que, hasta donde yo se, no distingue entre navegadores. Nosotros, como supongo que todo el mundo, desarrollamos con Firefox y luego probamos en IE6 (requisitos del cliente), todo manual. El problema es cuando realizamos modificaciones y luego no se prueba lo suficiente en IE...

    Por otra parte, no veo ningún inconveniente en programar los tests en Java, sólo ventajas. Reutilización de código, autocompletar,...

Publicar un comentario