# Aprendiendo: Jenkins
Buenos días, aquí iré metiendo pura mierda para que se quede persistente. **Aclaración**: en esta guía no explicaré todo el tema de infraestructuras para gestionar el firewall de la máquina donde está instalado nuestro Jenkins. Esta guía va a ser full explicar cómo montar los jobs.

[TOC]

## ¿Cómo podemos integrar con un proyecto multibranch?

### ¡Dependencias de la máquina para empezar a funcionar!

Vamos a dar por hecho que tenemos el Jenkins ya instalado en la máquina. Aún así, voy a poner lo que necesitamos para que esta guía sirva de algo:
1. [**Jenkins LTS**](https://www.jenkins.io/download/lts/macos/) (por favor lts)
2. [**Maven**](https://mkyong.com/maven/install-maven-on-mac-osx/)
3. [**Git**](https://git-scm.com/download/mac) (esta guía va a estar en local, pero normalmente tenemos un **agent** en una máquina diferente (arq. distribuida), por lo que necesita de git remoto, puede ser github/gitlab/... para poder acceder al código y gestionarlo)
4. [**SonarQube**](https://formulae.brew.sh/formula/sonarqube) (para el analisis de calidad)
5. La mejor opción de todas siempre es JFrog (de pago), pero como aquí somos unas ratas nos vamos a ir a [**Nexus Repository**](https://www.javanibble.com/how-to-install-nexus-on-macos-using-homebrew/) es más o menos lo mismo, pero sin poder subir imágenes de Docker (para subir directamente las imágenes de Docker podemos utilizar su Docker Hub; lo bueno de JFrog es que podemos subir literalmente todo lo que nos salga de los mismos huevos; aquí tenéis el repaso que le da a Nexus por ejemplo: https://jfrog.com/blog/artifactory-vs-nexus-integration-matrix/).
6. Todas las herramientas que queramos para análizar el código (análisis de calidad de integración continua).

## Integración con SCMs

Para las integraciones con SCMs remotos (esto sería el entorno real) vamos a necesitar seguir alguna guía para integrar estas dos tecnologías (en esta guía lo tendré que hacer localmente ya que mi compañía de internet no me deja abrirme al mundo). Dejo por aquí algunas guías que he encontrado que son cojonudas:
1. GitHub: https://www.blazemeter.com/blog/how-to-integrate-your-github-repository-to-your-jenkins-project
2. GitLab: https://about.gitlab.com/handbook/customer-success/demo-systems/tutorials/integrations/create-jenkins-pipeline/

## Integración con Git local

Esto no lo vais a ver por ningún sitio porque para eso nos creamos un script con todas las instrucciones (invocaciones a maven, a sonar, ...). Esta integración la necesito hacer para poder ver el uso que se hace del Jenkinsfile (es lenguaje *groovy*, no tiene mucha historia).

Lo que voy a hacer aquí va a ser emular los webhooks que proporcionar GitHub o GitLab o el SCM de turno, para hacerlo lo más realista posible (perdonen las molestias caballeros).

**ACTUALIZACIÓN**: viendo que va a ser una puta movida hacer lo que he dicho en el parrafo de arriba, se cancela toda esa vaina. Por tanto, vamos a suponer todo el rato que los hooks de nuestro SCM nos están llegando a la hora de hacer un merge o hacer un merge request... lo que sea, esto es configurable, podemos hacer que salte cualquier hook que queramos en el evento que queramos, cualquier cosa literalmente.

> Jenkins funciona en base a eventos, al fin y al cabo es una API que recibe peticiones con su metadata y según el endpoint hace una cosa u otra: un job al fin y al cabo.

---

## Crear un pipeline de integración continua

Antes de explicar cómo implementar la mítica integración continua en nuestro proyecto, necesitamos saber qué es un pipeline. Un pipeline es un ciclo de vida, donde se van a seguir una serie de pasos. Funciona de forma secuencial saltando de un stage al siguiente.

### ¿Qué elementos componen un pipeline?

Un pipeline se compone de distintas etapas (stages) secuenciales que ejecutan tareas (steps) que son lanzadas en nodos de trabajo (nodes).

> Gran parte de la información que voy a poner aquí la podéis ver en la guía oficial de [Jenkins](https://www.jenkins.io/doc/book/pipeline/syntax/).

#### Stage
Son las etapas lógicas en las que se dividen los flujos de trabajo de Jenkins. Cada stage puede estar compuesto por un conjunto de steps, y cada node puede contener un conjunto de stages.

Es una práctica recomendada dividir nuestro flujo de trabajo en etapas ya que nos ayudará a organizar nuestros pipelines en fases. Además Jenkins nos muestra los resultados de la ejecución del pipeline divido en etapas, mostrando el resultado de la ejecución de cada una de ellas con un código de colores.


#### Node
Los nodos son agrupaciones de tareas o steps que comparten un workspace. Los conjuntos de steps son añadidos a la cola de Jenkins para ser ejecutados cuando haya algún espacio libre entre los agentes de ejecución. **Los agentes de ejecución pueden ser la misma máquina del servidor maestro de Jenkins o un Jenkins en otra máquina en modo esclavo dedicado a este propósito**.

Es importante reseñar que el directorio de trabajo (workspace) es compartido por los steps del nodo, de forma que steps de un nodo pueden acceder a ficheros/directorios generados por steps de ese mismo nodo. Por el contrario un step de un nodo no puede acceder al workspace de otro nodo.

#### Step
Son las tareas ó comandos que ejecutados de forma secuencial implementan la lógica de nuestro flujo de trabajo. Por ejemplo, un comando puede ser la escritura de un mensaje en la consola echo '*Mensaje de prueba*'.

### Definición de un pipeline

La definición del pipeline la vamos a realizar en un fichero Jenkinsfile que subiremos en el directorio principal de nuestro repositorio. NOTA: Esta es la good practice, pero podemos subirlo donde queramos, siempre y cuando configuremos esta ruta en el servicio de Jenkins. Aún así y para evitar futuros errores, recomiendo basto de ponerlo en el directorio raiz para quitarnos del medio problemas de rutas relativas.

El fichero Jenkinsfile es un script basado en [**Groovy**](https://groovy-lang.org/syntax.html) que permite definir un pipeline de Jenkins.

> Se recomienda que la primera línea del script sea **#!groovy** para que los editores puedan interpretar que es un script de Groovy y lo muestren correctamente.

Un ejemplo de un pipeline sencillo (la manera deprecada) es el siguiente:

#!groovy

node {
    
   // ------------------------------------
   // -- ETAPA: Compilar
   // ------------------------------------
   stage 'Compilar'
   
   // -- Configura variables
   echo 'Configurando variables'
   def mvnHome = tool 'M3'
   env.PATH = "${mvnHome}/bin:${env.PATH}"
   echo "var mvnHome='${mvnHome}'"
   echo "var env.PATH='${env.PATH}'"
   
   // -- Descarga código desde SCM
   echo 'Descargando código de SCM'
   sh 'rm -rf *'
   checkout scm
   
   // -- Compilando
   echo 'Compilando aplicación'
   sh 'mvn clean compile'
   
   // ------------------------------------
   // -- ETAPA: Test
   // ------------------------------------
    
   stage 'Test'
   echo 'Ejecutando tests'
   try{
      sh 'mvn verify'
      step([$class: 'JUnitResultArchiver', testResults: '**/target/surefire-reports/TEST-*.xml'])
   }catch(err) {
      step([$class: 'JUnitResultArchiver', testResults: '**/target/surefire-reports/TEST-*.xml'])
      if (currentBuild.result == 'UNSTABLE')
         currentBuild.result = 'FAILURE'
      throw err
   }
   
   // ------------------------------------
   // -- ETAPA: Instalar
   // ------------------------------------
    
   stage 'Instalar'
   echo 'Instala el paquete generado en el repositorio maven'
   sh 'mvn install -Dmaven.test.skip=true'
   
   // ------------------------------------
   // -- ETAPA: Archivar
   // ------------------------------------
    
   stage 'Archivar'
   echo 'Archiva el paquete el paquete generado en Jenkins'
   step([$class: 'ArtifactArchiver', artifacts: '**/target/*.jar, **/target/*.war', fingerprint: true])
}

### Jenkins Declarative Pipeline

Decía que la manera anterior es la manera que se tenía antes para montar un pipeline. Esto es debido a que Jenkins, en 2017, añadió una herramienta para poder implementar todo el ciclo de vida, descrito anteriormente, de forma declarativa (podéis ver la noticia [aquí](https://www.jenkins.io/blog/2017/02/03/declarative-pipeline-ga/)).

> Esto no quiere decir que si queremos seguir añadiendo sintaxis en Groovy, no podamos. Podemos hacer un hibrido aunque no es recomendable.

Para empezar y definir nuestro Pipeline debemos irnos nuestro servicio [Jenkins](http://localhost:8080/) que estará desplegado en el puerto 8080 por defecto. Una vez estemos aquí tendremos varias opciones:


Depende de lo que necesitemos nos iremos a una opción u otra. En este ejemplo vamos a ver cómo se monta un Pipeline; vamos a seguir una serie de pasos como si esto fuera una receta de cocina (hay que recordar que no tenemos la integración con un SCM por lo que no es 100% real, pero nos puede dar una buena foto de cómo funciona todo):

1. Vamos a crear un nuevo item (será de tipo **Pipeline**)


2. Vamos a ver todas las opciones que nos da el propio Jenkins para poder empezar a movernos:


En estas opciones vamos a poder ver todos los triggers que pueden usarse para lanzar un pipeline. Como ya hemos dicho, no podemos integrar con un SCM remoto, por lo que necesitamos elegir la opcion:


Con esto podremos invocar la url: http://user:ropuertop@localhost:8080/job/testing/job/Integraci%C3%B3n%20continua/build?token=token?=superseguro.

> Podéis ver que esto depende del nombre que le hayáis dado a vuestro job, como del usuario que tengáis en uso, como el puerto que le hayáis dado al servicio, etc.

En resumen, con solo ese tick podemos invocar a este job siempre que queramos. Podemos integrar con nuestra propia aplicación móvil, de spring... de lo que sea, esto da bastante flexibilidad. Lo podemos restringir a un único proxy para darle más seguridad (y en este proxy hacer ya comprobaciones de lo que sea), lo que ustedes quieran señores.

3. Una vez tengamos esto, necesitamos definir el script que se lanzará cuando se invoque a este job:

    pipeline {
        agent any

        tools {
            // Install the Maven version configured as "M3" and add it to the path.
            maven "M3"
        }

        stages {
            stage('Build') {
                steps {
                    // Get some code from a GitHub repository
                    git 'https://github.com/jglick/simple-maven-project-with-tests.git'

                    // Run Maven on a Unix agent.
                    sh "mvn clean package"
                }

                post {
                    // If Maven was able to run the tests, even if some of the test
                    // failed, record the test results and archive the jar file.
                    success {
                        junit '**/target/surefire-reports/TEST-*.xml'
                        archiveArtifacts 'target/*.jar'
                    }
                }
            }
        }
    }