Configuring Jenkins Authentication with Auth0

The procedure described here is based on Jenkins 2.7.4 but I think it should also work with other (not so distant) versions.

First of all, log into your Auth0 account.

Then create a new client application (“Clients” item in left-hand menu).

auth0_1

In  the “Create Client” dialog set the name of your client application (for example “MyJenkins“) and choose the application type “Regular Web Applications“, finally click “Create“.

auth0_2

Once the application is created, go to “Settings” and set the value of the “Allowed Callback URLs” to “http://YOUR_JENKINS_URL/securityRealm/finishLogin“. Click “Save Changes“.

auth0_4

Scroll down to the “Advanced Settings” section, click on “Endpoints“. Take the SAML Metadata URL and save the content in that URL into a file (remember this file because we will use it later when configuring Jenkins).

auth0_9

Go to the “Addons” tab and enable “SAML2” option.

auth0_5

In the Addon configuration dialog edit the settings to set the “audience” and “recipient” values to “http://%5BYOUR_JENKINS_URL%5D/securityRealm/finishLogin“.

auth0_6

Click “Save” and close de dialog. Now you should see the SAML2 option is enabled.

auth0_7

 

That’s all on Auth0 size, now let’s work on Jenkins.

To perform the following steps, you need to be logged in with a user with administrator profile. I assume the reader is already familiar with Jenkins so the instructions won’t be so detailed.

First of all we need to install the “SAML Plugin“.

auth0_8

Once the installation is ready go to “Manage Jenkins > Configure Global Security“. In the “Security Realm” pick “SAML 2.0” and in the “IdP Metadata” box paste the content of metadata file you saved on before.

Scroll down to the “Authorization” section and ensure the option “Logged-in users can do anything” is selected (authorization  is something we will work on later). Scroll down to the bottom of the page and click “Save“.

That’s all.  Close the browser [*] and the next time you try to log in you will be redirected to Auth0. Now every user enabled in your Auth0 account will be able to log into Jenkins.

In the next article I will explain how to configure authorization.

[*] at the moment of this writing there is bug in the SAML plugin that affect a logout feature https://issues.jenkins-ci.org/browse/JENKINS-37311.

Integrating .Net Build tools: MSBuild, NuGet, FxCop, StyleCop and NUnit

These days it is very common to have a continuous build process that includes: compilation, code analysis and automated tests. The way of implementing this kind of process varies depending on the technology of the project.

I have worked with Ruby, Python, Java, JavaScript, Smalltalk and some other languages and in all cases you just need to install 3 tools:

  • the runtime/sdk (like ruby, jdk, cog)
  • a package manager (like bundle, maven, pip, metacello)
  • a build tool (like rake, maven, fabric)

Any other thing you may need (linter, testing framework, etc), you can get it using the package manager and make it run as part of your build script.

But in .Net the situation is more complex. First of all everything seems to be very tight to Visual Studio (the IDE). Because of this, many people just install the Visual Studio in the build server.

Additionally to this the .Net SDK does not provide a test framework. You can use NUnit (which you will have to install manually) or you can use MSTest but to use it you need to install Visual Studio.

FxCop (the linter) comes with Visual Studio but if you don’t want Visual Studio, then you have to install it manually.

So, in order to avoid several manual tasks when setting up a new dev box and also to minimize any possible difference between dev boxes and the build server box I did the following:

  • I downloaded all the tools I wanted to use in my build process and placed them into the same directory (c:\BuildTools).
  • I wrote a build script (using MSBuild and defining my own targets). This script “glues” the invocation to all of these tools: NuGet, FxCop, StyleCop and NUnit.
  • Finally I package all these stuff in a self-extracting .zip file so all the team members can easily replicate my setup.

In order to have the build process to run continuously I also installed this package in the Jenkins build server.

buildtools-v4buildtools-layout

Jenkins: Jobs as Code

Jenkins: Jobs as Code

Una de las funcionalidades destacadas en la nueva versión de Jenkins es la posibilidad de definir los pipelines utilizando un lenguaje de dominio específico. Esto resulta muy útil cuando uno tiene que manejar una cantidad importante de jobs y al mismo tiempo facilita el control de configuración ya que permite que la definición de los jobs sea tratada como código en lo referente al almacenamiento y versionado.

Esta posibilidad de manejar los jobs como código es algo que está ahora más presente en Jenkins 2, pero la realidad es que es una funcionalidad que ya estaba disponible para las versiones anteriores de Jenkins mediante el uso de plugins y algunas otras herramientas.

En particular yo venia utilizando el Jenkins Job Builder, una herramienta de la gente de Open Stack que permite definir jobs en un archivo .yml, definiendo también relaciones “de herencia” entre los jobs. El Job build es básicamente un script python que parsea los .yml y utiliza la api de Jenkins para crear los jobs correspondientes.

Otra herramienta que provee una experiencia similar es el Job DSL Plugin. Este plugin provee la posibilidad de definir Job utilizando un DSL Groovy para la definición de Jobs. La forma de uso es: poner los scripts de definición de jobs en un repo y luego crear un job en Jenkins (típicamente llamado Seed) que monitorea el repo de scripts y que cuando detecta cambios ejecuta los scripts los cuales generan los jobs que hayamos definido.

Otras herramientas similares pero que no he probado lo suficiente son: el Build Flow Plugin y el Workflow plugin.

Delivery Pipeline con Jenkins 2

Si bien vengo trabajando con Jenkins2 desde que se publicó el release candidate, no había echado mano a la nueva funcionalidad nativa de pipelines. Sinceramente la miré por arriba apenas instalé Jenkins2, no me convenció y decidí seguir con la combinación de plugins que venia usando con Jenkins 1.6.

El lunes pasado me actualicé a Jenkins 2.8 y decidí investigar más en profundidad la funcionalidad de pipelines nativos.  Finalmente esta mañana logré completar una primera versión de mi pipeline utilizando el nuevo soporte nativo. Al hacerlo descubrí un montón de cosas interesantes que pueden llegar a disminuir considerablemente el costo de control de configuración de Jenkins (principalmente las cuestiones versionado, actualización y backups de jobs)

jenkins2-pipeline

 

Jenkins 2 ha llegado

Así es, Jenkins 2 finalmente está aquí. Según se cuenta en el sitio oficial los puntos destacados de esta nueva versión mayor (major release) son:

  • Soporte nativo para delivery pipelines
  • Mejoras de usabilidad
  • Completa compatibilidad con versiones anteriores

Tuve la oportunidad de verificarlos cuando pasé uno de mis proyectos a la versión pre-release que Jenkins publicó hace un tiempo. Adicionalmente a esto noté:

  • “Independencia” de Maven, lo pongo entre comillas porque no estoy seguro que el término apropiado sea independencia. Lo que noté es que en la versión anterior, al crear un nuevo job existía la opción “proyecto Maven”, cosa que ya no existe. Creo que inicialmente esto tenía sentido pues Jenkins había surgido en el mundo Java, pero en los últimos años creo que ha transcendido ampliamente el mundo Java y se ha convertido en la herramienta de-facto para integración continua.
  • Integración con Gradle para la definición de los pipelines, los cual tiene mucho sentido ya que Gradle es una herramienta que se posiciona como herramienta de build genérica capaz de buildear proyectos en distintos lenguajes.
  • Se removió el soporte nativo para repositorios CVS, quedándo nativamente soporte solo para Git y Subversion.

Más allá de estos puntos, un detalle que me llamó positivamente la atención fue que como parte del proceso de instalación, se ofrece instalar un conjunto de plugins que son los más comunmente utilizados por la comunidad.

A partir de esta nueva versión de Jenkins y de algunas charlas que he tenido con mi equipo actual de proyecto he decido empezar a trabajar en la preparación de un curso de Jenkins para dictar en Julio o Agosto.

Blue Green Deployment

En las últimas 2 semanas me encontré explicando la técnica de despliegue Blue/Green más de 5 veces. Cuando tomé conciencia de ello decidí hacer un video explicativo de modo de poder utilizarlo también en mis clases. Espero resulte de utilidad.

Un caso robusto de integración contínua en Java

En el proyecto en el que he estado trabajando los últimos meses tenemos montado un proceso de integración continua bastante completo en mi opinión, comparto aquí algunos detalles. Se trata de un proyecto Java, basado en Spring, Hibernate, Camel y algunos otros frameworks. A nivel de herramientas tenemos quality checks con PMD, pruebas unitarias y de aceptación con JUnit y pruebas de aceptación y carga con JMeter. Como herramienta de build usamos Maven, como servidor de integración continua usamos Jenkins y el código lo tenemos en Git (gitlab). Al mismo tiempo tenemos un ambiente de tests en la nube donde desplegamos nuestra aplicación periódicamente. También tenemos un ambiente de prueba en las oficinas del cliente, donde desplegamos nuestra aplicación al final de cada iteración. En el jenkins tenemos varios jobs:

  • integración continua: monitorea el branch develop y ante cada cambio compila, ejecuta las pruebas de JUnit (unitarias y de integración)
  • quality-check: se ejecuta a continuación del job de integración continua y caso_java_jenkins_2básicamente ejecuta análisis de código (pmd)
  • integración continua de branches: en algunos casos creamos feature-branches, para lo cual seguimos una convención de nombres y este job se encarga de ejecutar integración continua sobre estos branches. En general procuramos que estos branches no vivan más de 3 días.
  • inicialización: es el job que dispara el build pipeline, y como tal comienza por inicializar el ambiente de test. Se ejecuta periódicamente (varias veces al dia siempre que haya cambios en el repositorio)
  • deploy: son dos jobs que se encargan de desplegar las dos aplicaciones que forman parte de nuestro sistema.
  • pruebas de aceptación: ejecuta las pruebas de aceptación (codeadas con jmeter) luego de cada despliegue
  • pruebas de carga: ejecuta un conjunto de pruebas de carga. Este job lo ejecutamos manualmente al menos una vez por iteración para asegurarnos que los cambios realizados no haya impactado en la performance del sistema
  • generador de release: este job lo ejecutamos manualmente al final de cada iteración para generar un nuevo release lo cual implica: taggear el repo, generar y publicar los artefactos (wars y jars) y actualizar la versión en los archivos del proyecto (pom.xml)
  • generador de instalable: este job toma  los artefactos generados por el job de generación de release y los empaqueta junto con un grupo de scripts que luego se utilizarán para instalar  el sistema en los ambientes del cliente.

caso_java_jenkins