Popurrí de Jenkins

Cuando empecé mi carrera como desarrollador web ya en el mundo real, sabía muy poco sobre todo lo que el proceso de crear software conlleva. Todo era nuevo. Lo único que sabía era HTML, CSS, algo de JavaScript y algo de PHP.

En esos primeros años aprendí demasiado. Conocí Git, Rails, RSpec, Capistrano, Bash, Drupal, Linode, etc, etc. Si bien descubrí nuevas herramientas y tecnologías, me faltaban procesos.

Era una empresa pequeña y tratar de implementar procesos era complicado por la dinámica de todo para ya, era para ayer. Además que mi jefe también era algo desorganizado.

Sin embargo, habían algunos procesos implementados de los cuales aprendí mucho, por ejemplo desplegar solamente si las pruebas automatizadas están 100% bien. Lo hacíamos medianamente manual.

La suite de pruebas la corríamos con RSpec o en su momento con Cucumber y luego el despliegue lo hacíamos con Capistrano.

Las versiones iniciales de Capistrano eran un dolor para configurarlas pero una vez lista, funcionaba casi que sin molestar.

Mi Primer Script

Fue haciendo una migración de sitios web hechos en Drupal donde hice mi primer script de despliegue. En realidad lo que hacía era tomar unos archivos, previamente cargados en el servidor y mediante unos comandos, moverlos a donde correspondía y hacer una serie de tareas necesarias.

No era gran cosa, no era lo mejor que había pero me sentí muy orgulloso porque automaticé un procesos muy tedioso para mí.

Sabía que el proceso de despliegue podría ser mejor y fue cuando descubrí la integración continua y el despliegue continuo.

Jenkins a la carga

Fue con Jenkins que tuve mi primera experiencia de CI y CD. Fue un momento emocionante porque era un tema nuevo, era el encargado y tenía este asunto pendiente en mi carrera.

A continuación comparto enlaces y puntos que aprendí/entendí de configurar Jenkins para aplicaciones Rails o AngularJS(en este caso).

Instalación y Configuración

La instalación es bastante simple y consiste de unos cuantos comandos a ejecutar.

Un detalle es que para poder ingresar la primera vez, hay que tomar un valor que está en un archivo en la carpeta /var/lib/jenkins/secrets/initialAdminPassword.

Un prerequisito es contar con Java en el sistema operativo donde se instale Jenkins. Para instalar Java seguí esta guía. Dependiendo de tu sistema operativo, puede que ya lo tengas instalado.

En aquel entonces me guié de estos artículos:

• How To Install and Use Jenkins on Ubuntu 14.04 LTS
  • En este mismo se indican los pasos para la configuración inicial
• También es bueno seguir las guías oficiales para ver que los comandos estén al día.

Para poder ingresar a la consola de Jenkins en el navegador, hay que configurar un virtual host con el web server que se haya instalado en el servidor. He sido fan de Nginx desde hace ya varios años y para este caso comparto uno para este web server.

upstream app_server {
  server 127.0.0.1:8080 fail_timeout=0;
}

server {
  listen 80;
  listen [::]:80 default ipv6only=on;
  server_name ci.yourcompany.com;

  location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;        
    proxy_set_header Host $http_host;
    proxy_redirect off;

    if (!-f $request_filename) {
      proxy_pass http://app_server;
      break;
    }
  }
}

Puedes ver la configuración aquí y acá.

Algunos Plugins

Como la gracia de usar Jenkins es tomar los commits, correr las pruebas y hacer un despliegue bajo ciertas reglas, para cumplicar el primer paso toca establecer un puente entre nuestro servicio de hospedaje de código, en este caso GitHub, y Jenkins.

Afortunadamente la Wiki de Jenkins tiene instrucciones al respecto.

Para esta configuración lo ideal es generar un personal token con los permisos para que Jenkins pueda leer el respositorio y hacer lo necesario con este.

El token debe tener el scope admin:org_hook

Jenkins y Rails

Algo que hay que tener claro desde el inicio es que Jenkins, y en general todo CI, necesita todo lo que normalmente uses para ejecutar tu aplicación en desarrollo:

• RVM
• Ruby
• Bundler
• Una base de datos: PostgreSQL o MySQL
• NodeJS
• etc

¿Por qué? Porque para verificar que todo esté en orden Jenkins(y cualquier servicio CI) necesita correr los comandos:

$ bundle install
$ rails db:migrate
$ rspec spec --fail-fast

Normalmente, esos comandos irían en un build step cuando se configura un proyecto en Jenkins y son el fundamento de la integración continua. Si alguno de esos pasos falla, el CI deberá avisarte, mostrarte el error y tú como desarrollador tomar medidas, corregir, subir al repo y esperar de nuevo al CI.

En este artículo hay una guía para usar Jenkins para que luego de que todo pase bien, haga un despliegue con Capistrano. Es útil pero no me gusta ya que configurar Capistrano tiene su toque de complejidad.

Usando Jenkins

Bueno, ahora los truquitos.

Reiniciar Jenkins

Puede que ocurra que un proceso de build haga que la máquina se bloquee, o por alguna razón, Jenkins falle y deje de funcionar. Para resolver eso que mejor que una reiniciada, pero ¿cómo se hace? Pues así:

• Desde el mismo navegador (jenkins_url)/safeRestart: reinicia y permite que cualquier trabajo en proceso sea completado
• Desde el navegador (jenkins_url)/restart: reinicia forzadamente sin esperar que los trabajos en curso finalicen
• También usando sudo service jenkins restart

Logs de Jenkins

Cuando hay errores sobre Jenkins y no necesariamente sobre un build, una forma de obtener más información al respecto es viendo los logs. Estos, normalmente, deberían estar en la ruta /var/log/jenkins

Mantener y Descartar builds

Otra configuración importante es aquella que permite indicar el número de builds a mantener y la que determina los builds a descartar.

Por defecto, Jenkins mantiene un registro de todos los builds que se ejecuten. Así se puede tener un historial de un determinado proyecto y otra forma de debuggear cuando las cosas vayan mal.

Sin embargo, mantener todos los builds incurre en un gasto de espacio de disco duro del servidor y eventualmente Jenkins no tendrá espacio para escribir y dejara de trabajar.

De un determinado proyecto se puede ver donde están los builds en la ruta /var/lib/jenkins/jobs/[PROJECT-NAME]/builds/

—

Y así terminar este popurrí de links de Jenkins. Si bien es una herramienta buena y útil tiene el detalle que implementarla en un proyecto implica tener que mantenerla, actualizarla y arreglarla cuando haya problemas.

Muy similar a un CMS 😀

Para quienes no les gusta tanta configuración pueden usar otros servicios como Circle CI, Semaphore, Travis, Codeship o incluso Bitbucket Pipelines si estás en Bitbucket, o proximamente con los GitHub Actions.