Los inconvenientes principales eran:
- Para trabajar en un proyecto (hoy Arena se compone de 7 proyectos distintos) no había otra opción que compilar todos los demás, ya que al no estar sistematizado el deploy no siempre el SNAPSHOT se correspondía con la última versión del código. Entonces perdía un poco de sentido la separación en artefactos distintos.
- Algunas veces se pusheaba al repositorio código que rompía los tests, o incluso no compilaba. Al no tener releases estables, podía darse el caso de que un deploy del SNAPSHOT rompiera los trabajos prácticos de los alumnos de una cursada, como sucedió alguna que otra vez.
- Los artefactos se desplegaban en un repositorio propio y no en Maven Central, lo que implicaba un paso extra de configuración a la hora de preparar el entorno de desarrollo. Trataremos este tema en el siguiente post de esta serie.
Eligiendo un CI para Arena
Para los ansiosos, la implementación final de lo que contaré a continuación (incluyendo el próximo post) puede verse en el repositorio de Arena en GitHub. De todos modos, recomiendo leer cada una de las decisiones que tomé para entender qué es lo que hace el CI cada vez que se sube código nuevo al repositorio.CIs Candidatos
Además de que fuera gratuito para Open Source Software (OSS), se necesitaba que cumpliera tres características:- que fuera fácil de configurar y que no necesitara hosting propio.
- que soportara Java de forma nativa.
- que tuviera algún mecanismo para subir el settings.xml, necesario para poder hacer el deploy a Sonatype.
- Jenkins, quizás el más conocido y flexible de los que voy a mencionar, pero con el overhead de tener que hostearlo en servidor propio y configurar todos los plugins.
- Semaphore, que suele ser mi opción preferida, pero como todavía no soporta Java “out of the box” es necesario bajar Maven en cada build.
- Y por último, drone.io, donde no encontré cómo solucionar el problema del settings.xml.
(Un comentario al margen: Travis tiene también una versión para repositorios privados y, gracias a un acuerdo con GitHub, la ofrecen de manera gratuita e ilimitada para estudiantes mediante el student developer pack.)
Configurando Travis
La configuración de Travis está basada en el principio de convention over configuration. Para empezar a compilar y correr nuestros tests, basta crear un archivo llamado.travis.yml e indicar en su interior en qué lenguaje está realizado nuestro proyecto, en nuestro caso Java. El primer archivo de configuración se veía así:language: java
git push de algún cambio (aunque una mejor idea sería crear una branch de prueba y hacer un pull request). Por defecto, Travis empezará a monitorear el repositorio y disparará un build por cada commit que se suba a cualquiera de sus branches, incluyendo pull requests. Una vez concluido dicho build, se encargará de notificar a GitHub el resultado, quien a su vez nos lo mostrará a nosotros como se ve en la siguiente imagen:
Con esa simple línea de configuración que le dimos, lo que se ejecuta es el default para Java, que consta de dos pasos:
mvn install -DskipTests=true, baja todas las dependencias y compila el proyecto. ¿Y para qué le pone ese flag si también queremos que corra los tests? Cuando algo anda mal, Travis diferencia entre un build errored y uno failed, donde el primer estado está asociado con un error en la instalación (no compila, no se encontró alguna dependencia) y el segundo con alguna validación que se ejecuta (normalmente un test fallido). Entonces si llegara a fallar la instalación, ni siquiera se corren los tests y sabemos con certeza que el resultado es erroredmvn test(no necesita explicación)
¡No dejen de compartir sus proyectos, ideas o experiencias en los comentarios!
