A la hora de hacer el setup de Jenkins hay diversas cuestiones que resolver las cuales pueden variar dependiendo del contexto. En términos muy generales esas cuestiones se resuelven:

• operando directamente sobre Jenkins, por ejemplo para instalar plugins
• o bien operando sobre el servidor en el cual Jenkins está corriendo, por ejemplo para instalar un SDK

La importancia que se le da al primer punto es muy variable y depende de si se trata de un «Jenkins Silvestre» (Jenkins manejado por un equipo de desarrollo sin ningún tipo de soporte organizacional) o si se trata de un «Jenkins Corporativo» que es administrado por un grupo de la organización.

Pero el segundo punto, es algo central si pretendemos utilizar Jenkins para buildear. Si queremos utilizar Jenkins para buildear C#, tendremos que asegurar que el servidor donde corre Jenkins tenga el correspondiente SDK instalado (o eventualmente necesitaremos un Jenkins Slave que tenga el SDK.) Esta situación se repite para cada tecnología/lenguaje que uno pretenda buildear. Más allá de la tarea de instalar el SDK en si misma, el punto es que hay que loguearse en el servidor para llevarla a cabo. Una forma de simplificar este setup es utilizar Docker. O sea, en lugar de instalar los SDK en el servidor de Jenkins, uno instala simplemente Docker y luego utiliza un contenedor Docker que contenga el SDK que cada proyecto requiera. Al mismo tiempo esto simplifica el escenario donde tenemos proyectos con dependencias de SDK que tiene conflictos entre si.

A mi parecer esta estrategia aún no está muy difundida pero me parece que a mediado plazo se impondrá como estándar de facto. De hecho, las últimas versiones de Jenkins (las que vienen nativamente con el plugin de Pipeline 2.5 o superior) simplifican mucho este setup. Basta con tener Docker instalado en el servidor de Jenkins y declarar la imagen builder a utilizar en nuestro Jenkinsfile.

El siguiente fragmento de código muestra un job de Jenkins que utiliza una imagen de node 8.9. Lo que hace es trivial, simplemente invoca node –version y escribe el output en un archivo de texto. Lo interesante es que el archivo de texto resultante queda dentro del workspace del job, o sea: Jenkins se está encargando de «sacar» el archivo que se genera dentro del contenedor Docker.

node {

    docker.image('node:8.9-alpine').inside {

        stage('Test') {

            sh 'node --version > version.txt'

        }

    }

}