Xnoccio

Después de miles de líneas de código, cientos de días dedicados y decenas de madrugones, noches en vela y vuelos de avión, mis compañeros y yo parimos un juego: “Invasion of the Granny Snatchers” que ha sido galardonado con este premio.

Para nosotros es un gran honor y estamos agradecidos a todos los que nos han apoyado: familia, amigos, compañeros de trabajo, … por soportarnos durante este tiempo,y darnos sus opiniones y sugerencias.

En fin, espero que anime a “Viavansi Games” a retomar sus aspiraciones, os dejo con el enlace del juego para el que quiera probarlo ;)

 http://www.youtube.com/watch?v=WEbPLov4FUU

http://www.assembla.com/wiki/show/GMFPublic

LuntBuild es otro sistema de Integración Continua software libre escrito en Java. Nuevamente nos encontramos ante una herramienta web fácil de instalar y configurar. Ofrece una interfaz base simple, pero flexible, gracias a sus mecanismos de extensión.

En realidad el alcance de LuntBuild va más allá de una plataforma de Integración continua. Por ejemplo, también permite almacenar y gestionar los artifacts generados, gestionar las versiones y dependencias entre proyectos, la gestión de notificaciones o incluso la publicación de blogs asociados a los proyectos.

LuntBuild ha sido desarrollado por PMEase, que también ofrece una versión comercial de esta herramienta llamada QuickBuild. Este software ofrece algunas funcionalidades extra, como la gestión avanzada de usuarios y roles que se echa en falta en la versión software libre.

• Instalación

La instalación básica de la herramienta es muy sencilla. Para ello, será suficiente con descargarla de http://luntbuild.javaforge.com y ejecutar en consola “java -jar LuntBuild-installer-1.5.6.jar” (en el caso de la versión evaluada), y se iniciará el proceso de instalación. Este proceso de instalación es una aplicación de escritorio basada en swing que consta de 13 pasos donde se nos permitirá configurar las diferentes opciones de instalación. Una vez finalizado y una vez instalado podremos ejecutar “bin/luntbuild.sh localhost 8080” (en nuestro caso hemos optado por desplegar LuntBuild en el puerto 8080) para poner en marcha la herramienta.

• Administración, gestión de proyectos

LuntBuild ofrece una interfaz de administración muy potente, por lo que sólo nos veremos obligados a acceder a ficheros de configuración para las opciones más avanzadas.

Aunque la documentación oficial es bastante completa (http://luntbuild.javaforge.com/manual/guide/manual.html), la interfaz resulta compleja y exige al administrador que esté familiarizado con los conceptos relacionados con la Integración Continua.

La herramienta permite la generación de copias de seguridad desde la propia interfaz web, aunque éstas no pueden ser automatizadas. Al igual que en el caso de Continuum, siempre podemos optar por la simple copia de seguridad de la base de datos de la aplicación.

Un factor negativo a destacar en nuestra evaluación ha sido la complejidad en la actualización a nuevas versiones, haciendo necesario la ejecución de scripts de migración entre versiones.

• Seguridad

La herramienta soporta gestión de usuarios, pero sólo admite un conjunto de roles predefinidos, por lo que tiene un mecanismo sencillo pero poco flexible. No admite la gestión de permisos basados en proyectos.

Por otro lado, para muchas de las opciones de seguridad nos hemos visto obligados a acceder a complejos ficheros de configuración como el situado en la ruta /WEB-INF/applicationContext.xml.

• Integración con sistemas externos

LuntBuild ofrece un mecanismo de extensión muy sencillo, basado en expresiones OGNL (Object-Graph Navigation Language) que a su vez pueden invocar a nuevos plugins. Este mecanismo de extensión, aunque es restrictivo, permite inyectar comportamientos de forma sencilla. Por otro lado, al igual que ocurre con Continuum, la definición de mecanismos de testeo, bugtracker, validación , etc., depende de la correcta configuración de plugins report y build en los ficheros pom.xml de los proyectos.

La herramienta tiene soporte para los principales sistemas de control de versiones como Subversion, CVS, SourceSafe, StarTeam, etc… no dependiendo su integración de la definición del SCM del pom.xml en proyectos Maven, como sí ocurría en el caso de Continuum.

• Tipos de proyectos

LuntBuild soporta proyectos en formato Maven, Ant, Shell scripts y Rake.

• Facilidad de uso

Nos encontramos ante una herramienta con una interfaz potente, pero poco usable e intuitiva y carente de una adecuada documentación en linea. Por ello impone una curva de aprendizaje lenta.

Por otro lado, la documentación oficial es suficientemente completa, pero de nuevo resulta compleja para personal sin experiencia en este tipo de herramientas.

• Estabilidad

Nos encontramos de nuevo ante un software muy estable; a continuación se detallan las últimas versiones liberadas de la plataforma:

Por otro lado, el sistema permite la gestión de hilos de compilación y contempla compilación distribuida, lo que mejora su estabilidad en entornos con una gran carga. En este aspecto dispone de mejores características que Continuum.

• Conclusiones sobre LuntBuild

Esta herramienta es muy completa, ofreciéndonos en un solo producto muchas de las funcionalidades necesarias, y dispone de la posibilidad de integración con multitud de sistemas externos. Quizás el principal factor negativo es una gran complejidad de uso para usuarios con poca experiencia en sistemas de Integración Continua y algunas funcionalidades extra que sería deseables y que solo están disponibles en la versión comercial. En cualquier caso, podemos considerarla una excelente herramienta.

Esto es un post que se sale un poco de la línea tradicional de este blog, pero quiero aprovechar este medio para realizar un poco de “denuncia social” de algo que me ha pasado y que es absolutamente injusto.

Desde julio dispongo de un contrato iPhone 3G con Movistar. Esto significa 24 meses de permanencia, con una tarifa plana de datos 3G que sólo puedes utilizar desde el iPhone.

El pasado sábado día 11/10/08 observé que, mientras lo utilizaba, el iPhone comenzaba a mostrar fallos extraños, como que el brillo de la pantalla se bajaba automáticamente, la vibración se activaba y desactivaba sólo, etc. Probé varias opciones: apagar y encender, restaurar una copia de seguridad, etc., sin resultados, por lo que decidí llevarlo a reparar a una tienda Movistar (República Argentina 15 de Sevilla) que a su vez lo envió a Apple con fecha 14/10/2008.

Hoy, con fecha 23/10/2008 recibo el teléfono SIN REPARAR, y una indicación de Apple que dice que mi iPhone tiene daños internos “debido a que se han vertido líquidos sobre él o ha sido sumergido en líquido”.

Doy mi palabra de que bajo ningún concepto mi teléfono ha sufrido dicho trato. Además, este teléfono ha estado continuamente protegido por una funda Zagg Invisible Shield tanto en la pantalla como en la zona frontal, y con un ‘calcetín’ protector por encima, y lo cuidaba al extremo de la paranoia, como observo que hacen la mayoría de los afortunados poseedores de un teléfono como éste. No sé si el teléfono tendría realmente humedad o no cuando llegó al AppleCare Service de Cork, Irland… pero como si tenía el Nilo dentro, no ha sido mi culpa o responsabilidad. Hay muchísimas causas no aplicables al poseedor del teléfono por las que un terminal puede disponer de humedad en su interior, por ejemplo, por fallos de fábrica en la estanqueidad.

El caso es que en este tipo de situaciones se da una situación tremenda de indefensión. Lo que dicte el servicio técnico se convierte en verdad absoluta, y sin derecho a réplica. Fijaos por ejemplo en el caso de un pobre poseedor de un teléfono al que no se lo quisieron arreglar “por instalar software ajeno a terceros”, y lo que había instalado era ¡un tono!

http://es.engadget.com/2008/01/11/apple-niega-el-soporte-a-un-usuario-que-cambio-el-tono-de-llamad/

¿Y ahora qué?

Y para redondear la desgracia, Movistar no se hace cargo de nada, no sabe no contesta, pero desde luego, se remite a la permanencia de 24 meses por un servicio que no puede darme, como es una tarifa plana asociada a un terminal iPhone 3G que no funciona por causas ajenas a mi voluntad y responsabilidad.

A falta de poder hacer nada con esto, salvo intentar reclamar por las pobres vías que nuestra sociedad nos da, al menos puedo contar a nuestros lectores mi caso, para que lo tengan en cuenta si están pensando en adquirir un iPhone y encima con Movistar.

Actualización: después de un segundo envío a Apple, han pasado de mí e insisten con lo de que se ha mojado. Dado que yo no lo he mojado, empiezo a pensar en el impacto de un día de niebla el mismo día que se rompió… sobre todo mirando esto, que el iPhone se muere con el clima húmedo de Bélgica…  Así que me sigo sintiendo un poco robado. He pasado a la última opción, abrirlo y ver qué pasa… una vez que hemos perdido la garantía, qué le vamos a hacer. Eso sí, como se recupere, Cydia, jailbreak y de todo. Leña al mono. Y si no se recupera, esa es la gracia: Movistar me “está obligando” a darme d baja, porque no existe la opción de volver a comprar otro (sería otro alta y otro contrato)… y me sale más barato pagar la indemnización.

Actualización 2:  Arreglado abriéndolo! Efectivamente tenía algo de líquido pegajoso haciendo contactos, con lo que algo de razón tenían en Apple… claro que también decían que era irreparable, y en media hora el iPhone está como nuevo. Algo de razón tenía yo en que NO lo había mojado, y efectivamente…  había sido (mucho ojo para los que os penséis en ponerlas) una filtración del líquido adherente de las fundas Invisible Shield de Zagg…

Formul@ (léase Formula) es un software desarrollado por VIAVANSI (cuyo desarrollo finalizó en 2007), que permite diseñar visualmente (mediante una interfaz Ajax con funcionalidades de drag&drop) formularios dinámicos que posteriormente pueden ser utilizados remotamente por otras aplicaciones. Ello es debido a que la necesidad de gestión visual de “dynamic forms” es cada vez más común y recurrente en multitud de proyectos. ¿En cuántos sistemas de información existe el requisito de disponer de formularios de entrada de datos, y cuánto esfuerzo de desarrollo y mantenimiento evolutivo implica?

Nuestra idea consistió en desarrollar un componente específico especializado que se responsabilizase de esta tarea dentro de una arquitectura de servicios, del mismo modo que se usa un servidor de base de datos para persistir información o se usa un servidor SMTP para enviar un email.

Básicamente y a grandes rasgos, Formul@ se encarga de las siguientes tareas:

• Definición visual de formularios complejos.
• Almacenamiento de la definición en un metamodelo XML.
• Rendeo de los formularios bajo demanda de aplicaciones cliente. Nótese que al basarse en una definición modelada en XML, del mismo modo que un formulario se rendea en web, podría rendearse en una aplicación de escritorio, en un teléfono móvil, etc… Un sólo trabajo de definición, múltiples salidas para el formulario.

Te invitamos a que pruebes la demo del diseñador de formularios Formul@.

A nivel técnico Formul@, que inicialmente surgió como desarrollo interno de I+D, hace uso de las últimas tecnologías disponibles en el mundo Java como son Java Server Faces (JSF), Java Persistent Api (JPA, Ajax, Maven, Web services usando JSR 181, XSL-FO, etc.

A nivel funcional, si probáis la demo del diseñador podréis observar que pueden crear varias páginas, dentro de las páginas bloques de varios tipos, dentro de éstos contenedores para maquetar, dentro de los contenedores campos de diversos tipos… Y luego las aplicaciones cliente pueden usar y controlar el comportamiento de los formularios a través de un API.

Formul@ ha sido desarrollada para la Junta de Andalucía, por lo que está liberada como software libre dentro del Repositorio de Software Libre de la Junta de Andalucía.

Actualmente estamos trabajando para la Junta con el objetivo de incluir muchas mejoras en el motor. ¡Pon Formul@ en tu vida!

PD: Formul@ no sólo se ha utilizado en varios proyectos de desarrollo de VIAVANSI, como no podría ser de otra forma… por ejemplo, otras empresas (como nuestros colegas de Guadaltel, ahí va una referencia gratuita en agradecimiento por el paintball) lo han utilizado (dentro del ámbito local andaluz) como motor visual de formularios dinámicos en la Oficina Virtual del Ayuntamiento de Córdoba, en el sistema de Comunicaciones Internas eCO de la Junta de Andalucía, en el ambicioso Sistema de Gestión Global del Gasto (G3) de la Junta de Andalucía, etc.

16:00, a punto de presentar viafirma.org en la Open Source World Conference de Málaga. Así que sirva este post a modo de tweet.

Aúpa Viafirma!! :-D

Apache Continuum

Continuum es una potente herramienta de Integración Continua desarrollada por Apache; su descarga está accesible en la URL: http://continuum.apache.org/download.html

• Instalación

La instalación de Continuum Server es sencilla; para una instalación básica basta con descargar el paquete de instalación apropiado de la web de Continuum, descomprimir el paquete en el directorio destino escogido y configurar las conexiones a base de datos a utilizar. Una vez instalado, para su ejecución solo se requiere lanzar uno de los scripts incluidos en el directorio bin.

Como hemos podido comprobar, la configuración básica es realmente sencilla, pero en la mayoría de los casos necesitaremos configurar conexiones a bases de datos, sistemas de correo, gestión de permisos avanzada, etc., además de desplegar Continuum sobre un servidor de aplicaciones. Para este tipo de configuraciones deberemos modificar los ficheros de configuración basados en xml o properties según el caso.

En términos generales la documentación del producto es buena, si bien resulta algo pobre. Esto suele ser tradicional en la mayoría de los proyectos del grupo Apache; existen algunos apartados con documentación muy completa, pero quedando otros aspectos de la documentación por terminar.

En Continuum nos enfrentamos a una curva de aprendizaje relativamente lenta para personal no especializado, debido a algunas configuraciones no documentadas y multitud de conceptos que hay que saber manejar desde el principio. Por ejemplo, se suele requerir adaptar el fichero continuum/conf/application.conf, o los ficheros pom.xml de los proyectos Maven de forma acorde a lo que espera Continuum.

• Administración, gestión de proyectos

Con esta herramienta muchas de las tareas administrativas podrán ser realizadas mediante la consola web. Aunque otras  tareas avanzadas requieran la modificación de ficheros de configuración.

La herramienta permite la definición de tareas periódicas desde su interfaz web de una forma sencilla, pudiendo automatizar tareas. Si bien la configuración de estas operaciones es sencilla, la documentación oficial al respecto es nula.

Respecto a las gestión de copias de seguridad, sólo se contempla un backup basado en un cliente xml-rpc, no existiendo documentación asociada a este cliente. Por otro lado, la opción alternativa se basa en realizar copias externas de la base de datos y los ficheros de trabajo, en función del tipo de instalación y base de datos utilizada.

Se puede destacar que no existe documentación en linea mientras se utiliza la herramienta. Ello, unido a la escasa documentación, provocó que durante nuestra evaluación tardásemos más tiempo del esperado en configurar nuestras primeros proyectos Maven sobre Continuum.

Continuum es un software en constante crecimiento, el cual ha mejorado mucho en las últimas versiones. Sin embargo, la actualización a nuevas versiones no resulta siempre directa; en la mayoría de los casos resulta necesario ejecutar alguna herramienta de migración para actualizar desde versiones anteriores.

• Seguridad

El sistema dispone de un mecanismo de seguridad muy completo, basado en usuarios, roles, y permisos sobre operaciones o proyectos, permitiéndonos la definición de una matriz completa de permisos. Sólo necesitaremos modificar el fichero de configuración security.properties cuando estemos realizando configuraciones avanzadas.

• Integración con sistemas externos

Apache Continuum no ofrece mecanismos de extensión o plugins, limitándose a permitirnos la llamada a plugins Maven desde los comandos de compilación asociados a los proyectos. Esto hace que dependa de la correcta configuración de plugins Maven report y build en los ficheros pom.xml de los proyectos gestionados.

Por este motivo, si requerimos que Continuum ejecute procesos de testeo, bugtrackers, validación de reglas de estilo, etc., necesitaremos definir éstos en el fichero pom.xml del proyecto. Sin embargo, no obtendremos una integración completa entre Continuum y los plugins Maven utilizados (Continuum lanza los procesos, pero no integra sus respuestas para plasmar los resultados en pantalla). Del mismo modo, la integración con el sistema de control de versiones dependerá de la correcta configuración del plugin SCM en el fichero pom.xml del proyecto gestionado.

Otro aspecto que se echa de menos es un mecanismo para despliegue de aplicaciones y librerías que sea independiente de la definición de estos mecanismos en Maven. Nuevamente se exige una correcta configuración de estos aspectos en el pom.xml del proyecto.

En general, esta parece una debilidad grave de Continuum, ya que depende en exceso de que los ficheros pom.xml estén perfectamente configurados, y por ello la realización de procesos de verificación es dependiente de la buena voluntad del desarrollador, no de las personas responsables de estas tareas (como gente de Desarrollo o de Calidad).

• Tipos de proyectos soportados

Apache Continuum está especialmente enfocado a proyectos Maven, si bien también ofrece soporte a proyectos con scripts Ant y otro tipo de proyectos sin formato basados en scripts de compilación. Aunque las limitaciones se podrían solventar mediante proyectos shell, se echa en falta la integración con otros lenguajes o mecanismos como ivy, rake, etc.

• Facilidad de uso

Nos encontramos ante una herramienta con una potente interfaz web, que utiliza un conjunto de iconos preestablecidos para indicar los estados y acciones disponibles, ofreciéndonos a su vez una leyenda para su fácil interpretación.

El único apartado negativo es que no aporta ayuda en línea sobre los diversos conceptos y elementos de la interfaz, por lo que es necesario un mínimo conocimiento previo de los conceptos tratados.

Respecto a la documentación oficial, ofrece una documentación muy escueta con multitud de apartados tan sólo esbozados, siendo por ello recomendable recurrir a artículos externos o libros especializados.

• Estabilidad 

Estamos ante un software estable y fiable como la mayoría del software desarrollado por el grupo Apache. A continuación se detallan las últimas versiones liberadas de la plataforma:

Una buena prueba de estabilidad del software es que está siendo utilizado internamente por varios de los proyectos gestionados por la propia Apache.

Respecto al rendimiento, el principal defecto es que no dispone de gestión de hilos de compilación, ni de mecanismos para la compilación distribuida, aunque es posible ver el listado de tareas pendientes y detenerlas si se desea. La ausencia de aquellas opciones hace que en ocasiones se puedan causar picos de caída de rendimiento, o falta de adaptación a las prestaciones de estaciones multiprocesador.

•  Conclusiones finales sobre Continuum

Apache Continuum es aún un producto relativamente joven con mucho espacio para crecer y mejorar. Ha avanzado en buena medida desde sus primeras versiones, las cuales no alcanzaban el nivel de calidad mínimo exigido a este tipo de soluciones. Sin embargo, las nuevas funcionalidades que han ido apareciendo en las últimas versiones, unido a su intuitiva consola de administración, lo hacen una buena herramienta y una opción seria para implementar una infraestructura de desarrollo basada en esta plataforma de Integración Continua.

Los principales puntos negativos encontrados han sido la falta de algunas funcionalidades típicas disponibles en otras soluciones de Integración Continua, donde destaca sin duda la inexistencia de un mecanismo de extensión de funcionalidad que permita la inyección de plugins. Continuum se basa al 100% en la configuración previa establecida en el pom.xml (reporting, checkstyle, scm, etc.), exigiendo así que la definición del proyectos sea completa para su correcto funcionamiento. Por decirlo de una forma reducida, ello implica que todos y cada uno de los proyectos deben disponer de la misma configuración, y si se desea ampliar una funcionalidad, ello implica la modificación del fichero pom.xml de todos los proyectos. Sin duda, Continuum adolece de una gestión centralizada de extensiones que permitiese configurar este tipo de funcionalidades a nivel plataforma, no a nivel proyecto.

• Comentario personal

Apache Continuum resultó un software genial durante el tiempo que estuvimos utilizándolo en los proyectos internos del departamento de I+D, pero causó demasiados problemas cuando comenzamos la migración de todos nuestros proyectos de desarrollo a un entorno de integración continua. Hay que aclarar que la mayoría de los problemas que encontramos no son directamente achacables a Continuum, sino a la poca experiencia con este tipo de soluciones del grupo de desarrolladores y a las exigencias que se imponían sobre proyectos que, por falta de tiempo, nunca eran configurados al 100%. Finalmente lo descartamos eligiendo una solución más sencilla en su manejo y con menos exigencias respecto a la configuración completa de los proyectos gestionados.

Continuación: LuntBuild. Eligiendo nuestro entorno de Integración Continua (III).

El próximo Lunes 20 de Octubre, nos vamos a Málaga a presentar Viafirma en la Conferencia Internacional de Sofrware Libre( programa ).

Objetivos

El objeto de este artículo es en plasmar la metodología y conclusiones obtenidas en una comparativa técnica que hemos realizado sobre algunas de las herramientas de integración  continua disponibles en el mercado. Para ello se establecen unas bases para la elección de la plataforma y se realiza una comparativa completa partiendo de una selección de herramientas.

Existe un buen número de herramientas de Integración Continua en el mercado: Continuum, CruiseControl, LuntBuild, Hudson, Atlassian Bamboo, etc… Para facilitar el estudio se ha realizado una primera preselección consistente en las herramientas estrictamente Open Source más utilizadas en el mercado: Apache Continuum, LuntBuild y Hudson.

Antes de entrar en detalles, comentaremos cúales son los principales objetivos funcionales que se buscan a la hora de implantar un sistema de Integración Continua:

• Reducción del tiempo de integración. Se trata de agilizar el proceso de integración de los diversos proyectos y aplicaciones, buscando un sistema que se responsabilice de automatizar la compilación, ejecución de tests y despliegues, así como de avisar de posibles problemas a los diversos participantes en el desarrollo de un proyecto.

• Reducción de errores. Uno de los objetivos más importantes que se persiguen con este tipo de sistemas es la detección de errores y conflictos en un estado temprano.

• Testeo de la calidad de código y reglas de estilo. Para asegurar un mínimo de coherencia de los nuevos desarrollos con las políticas de calidad establecidas, se busca un sistema capaz de automatizar este tipo de tareas de manera sencilla.

• Reducción del riesgo. Permitiendo que versiones tempranas del producto estén disponibles lo antes posible, con un número de incidencias minimizado de forma automática, y con una gestión de la configuración automática que reduce errores en despliegues.

• Disponibilidad continua de la última versión del código para pruebas, agilizando los procesos de despliegue de nuevas versiones en los diferentes entornos.

Metodología del análisis

Para seleccionar el sistema de Integración Continua más adecuado, hemos procedido a analizar las diversas características funcionales y técnicas de interés. Para ello se ha procedido a instalar las tres plataformas objeto del estudio (Continuum, LuntBuild y Hudson) y se ha puesto en marcha al menos un proyecto Maven sobre ellas, tratando de evaluar una serie de variables de interés.

A continuación se indican los criterios de selección utilizados en la comparativa:

• Instalación.

Evaluaremos la facilidad de instalación y configuración de las herramientas, con parámetros como la documentación oficial de instalación, posibilidades de configuraciones avanzadas, dificultad de la instalación, etc.

• Administración, gestión de proyectos.

Partiendo del hecho de que el entorno en el que se va a realizar la implantación no tiene por qué contar con personal especializado y dedicado exclusivamente a la gestión y administración de la plataforma, será recomendable que las tareas de administración asociadas al sistema elegido sean las mínimas, y que su ejecución sea lo más sencilla posible. Se analizarán parámetros como la documentación oficial destinada a esta temática o si el sistema permite una fácil generación y restauración de copias de seguridad (tanto de la definición de los proyectos y tareas configuradas como del histórico de compilaciones). También se estudiará si las tareas de administración relacionadas con la plataforma se puedan realizar mediante la interfaz Web. Así mismo, verificaremos si se permite recuperar el historial de las últimas tareas de compilación realizadas, así como poder configurar el número de días y compilaciones que se mantendrán en el historial. Con respecto a la gestión de tareas periódicas, comprobaremos si el sistema permite la definición de tareas periódicas, para facilitar la automatización de tareas repetitivas. Además, teniendo en cuenta que este tipo de herramientas están en continua evolución, se evaluará la facilidad de instalación de nuevas actualizaciones. Por último se estudiará el rendimiento de la solución. Dado que las compilaciones son tareas muy pesadas, se evaluarán los diferentes mecanismos que aporta cada sistema de Integración Continua para la gestión de hilos de compilación y la ejecución distribuida de tareas.

• Seguridad.

Se evaluará la versatilidad y potencia en la gestión de roles, perfiles y permisos asociados a proyectos y acciones disponibles en la herramienta. Resulta interesante además poder definir perfiles de usuario específicos. Así mismo, se estudiará la posibilidad de definición de permisos especiales para proyectos concretos. Por último evaluaremos la complejidad a la hora de establecer una política avanzada de permisos, observando el nivel de personalización que permite la plataforma.

• Integración con sistemas externos.

En la mayoría de los casos es necesario que la herramienta de Integración Continua interactúe con otros sistemas específicos, por lo que puede ser necesario el desarrollo de nuevos plugins que extiendan la funcionalidad de la plataforma. Por este motivo evaluaremos la sencillez y los mecanismos que ofrecen estos sistemas a la hora de inyectar funcionalidad personalizada.

Evaluaremos también el nivel de integración que tienen las diferentes herramientas de Integración Continua con sistemas de control de versiones, así como el nivel de integración con herramientas de evaluación de código (como checkstyle, PMD, etc…). Analizaremos además el nivel de integración con sistemas de gestión de incidencias, particularizando en el sistema Mantis BT. Por último evaluaremos el nivel de integración de soluciones con sistemas de test como Junit o JMeter .

• Tipos de Proyectos soportados.

Evaluaremos los diferentes tipos de proyectos soportados, así como sus posibilidades de extensión para futuros modelos. Aunque haremos especial hincapié en el soporte completo de proyectos basados en Maven2, si bien también es relevante que el sistema permita la gestión del mayor número posible de formatos.

• Facilidad de uso.

Ya que la plataforma de Integración Continua elegida deberá convertirse en una pieza central de nuestro entorno de software, la herramienta deberá ofrecer una interfaz sencilla, usable e intuitiva, de forma que se facilite la interacción con la herramienta por personal no especializado, sin problemas serios de aprendizaje. Haremos especial hincapié en las ayudas en línea disponibles y en la organización de la interfaz.

• Documentación de usuario.

Evaluaremos la cantidad y calidad de la documentación de usuario disponible.

• Estabilidad.

La herramienta elegida deberá disponer de unas excelentes características de estabilidad. El objetivo no es elegir la última tecnología relacionada con la Integración Continua, sino disponer de un entorno funcional operativo lo más robusto posible.

Próximamente:
Apache Continuum. Eligiendo nuestro entorno de Integración Continua (II).