Manejo de parámetros de deployment en Jenkins

Al implementar un pipeline de deployment suele surgir la necesidad de usar algunos parámetros como ser credenciales para conexión a un server, alguna API Key para interactuar con un cloud provider, etc.

Hay varias formas de manejar esto cuando trabajamos con Jenkins. Hoy quiero compartir una forma que me parece elegante y simple a la vez.

La propuesta es utilizar el soporte de Credenciales que ofrece Jenkins. Para esto vamos a Credentials > Global > Add Credentials.

En la pantalla de agregado de Credenciales elegimos el tipo de credencial que queremos agregar. En este ejemplo voy a elegir una credencial del tipo Secret Text pues quiero guardar un simple API token.

Con esto ya hemos almacenado nuestra credencial en Jenkins. El campo ID es el que utilizaremos a posteriori para referenciar esta credencial.

La forma de usar esta credencial varia dependiendo del tipo de credencial (en este caso es Secret Text) y del “lugar” desde donde querramos accederla por ejemplo si es un FreeStyle job o un Pipeline job.

Para usar esta credencial desde un pipeline job se puede usar el siguiente snippet.

Para usar este credencial desde un FreeStyle job, primero bindeamos la credencial a una variable y luego utilizamos directamente la variable.

Un detalle no menor de esta estrategia es que cuando se ejecuta el job el valor de la credencial es enmascarado.

Servidores CI/CD: diferencias de modelos, Jenkins vs CircleCI

Servidores CI/CD: diferencias de modelos, Jenkins vs CircleCI

Jenkins es una de las herramientas de CI/CD más difundidas, posiblemente por su potencia y también por su larga historia (su primera versión es de 2005). Yo empecé a utilizarlo allá por 2008 cuando aún era Hudson. Inicialmente era un servidor de integración continua. Luego con el auge de la entrega continua se lo empezó a utilizar para hacer deployments. Esta última característica cobró más impulso a partir de la versión 2.

CircleCI es una herramienta de aparición mucho más reciente y viene a resolver el mismo problema que Jenkins pero con un modelo distinto.

En este post decidí hablar concretamente de Jenkins y Circle porque hoy en día estoy trabajando en dos proyectos, cada uno con una de estas herramientas. Pero en realidad es que en lugar de Circle podría referirme a Travis o a los Builders de Gitlab, pues conceptualmente representan el mismo modelo. Del mismo modo, en lugar de Jenkins podría hablar de Bamboo.

Veamos entonces algunas diferencias de estos dos modelos. CircleCI funciona atado a un repositorio Git (puede ser GitHub, BitBucket o algún otro). Al mismo tiempo, el funcionamiento de la herramienta está definido por un archivo (en formato yaml) donde uno define sus Jobs/Workflows. Si bien la herramienta provee una interface gráfica web, la misma es principalmente para visualización y solo permite ajustar algunos pocos settings, pero no permite la creación de Jobs. La situación es análoga al utilizar Travis o GitLab. Este modelo va muy bien con las estrategias del tipo GitOps, donde todo el pipeline de delivery se articula a partir de operaciones/eventos Git.

Por otro lado, Jenkins ofrece un modelo distinto, uno puede crear jobs asociados a distintos tipos de repositorios o incluso permite crear jobs sin asociación alguna a repositorios. Al mismo tiempo ofrece una interface de usuario web que permite manipular completamente la herramienta, de hecho, durante mucho tiempo esta era la única opción. Luego fueron apareciendo distintas opciones/plugins que posibilitaron tener un manejo similar al de Circle/Travis.

En otra dimensión de análisis podríamos decir que el modelo de Circle/Travis es en cierto modo “CI/CD as a Service”. Son herramientas muy enfocadas en CI/CD con toda una serie de cuestiones de diseño ya tomadas de antemano. De hecho en general el modelo de extensibilidad de estas herramientas es bastante limitado.

Por su parte Jenkins surgió inicialmente en modelo más On-Premises/Producto, contando desde su inicio con un modelo muy potente de extensibilidad y luego fue evolucionando incorporando características de los modelo más SaaS. La arquitectura extensible de Jenkins ha posibilitado la aparición de nuevos proyectos montados sobre Jenkins como ser JenkinsX.

Personalmente me siendo muy a gusto trabajando con Jenkins, creo que es un producto muy versátil y lo he utilizado para algunas cosillas más allá de CI/CD. Al mismo tiempo que creo en un contexto organizacional Jenkins ofrece varias características y posibilidades de extensibilidad no presentes en el otro modelo. Entre las bondades de Jenkins podría nombrar la integración con muchísimas herramientas, las capacidades de templating, slicing configuration y la posibilidad de generar plugins en caso que uno lo necesite (lo he hecho y no pareció complicado). Sin embargo y a pesar de mi gusto por Jenkins, creo que la característica de Pipeline as Code (jenkinsfile) no está lo suficientemente lograda. Perdón, creo que la funcionalidad está bien, pero personalmente me siento más a gusto utilizando un set de plugins tradicionales (como JobDSL, el JobBuilder y BuildPipeline) que usando los Jenkinsfile.

HOY: Patrones de Infraestructura para Continuous Delivery

Esta tarde a partir de las 18.50 estaré en la oficinas de RyanAir Madrid, exponiendo sobre esta temática.

De paso, voy a aprovechar el contacto con la comunidad ágil de Madrid para hacer difusión de algunos libros “Made in Argentina”. Voy a estar sorteando entre los participantes algunos ejemplares de “Construcción de Software, una mirada ágil” y “Experiencias ágiles, relatos de experiencias del uso de métodos ágiles en Argentina”.

Si están por Madrid y quieren sumarse, la entrada es gratis pero es necesario registrarse aquí.

Talleres segundo semestre 2017: DevOps, Continuous Delivery y Git

Para esta segunda mitad del año tengo planificado dictar los siguientes talleres:

  • Taller de Git, el martes 29 de Agosto, de 14 a 18 hs. en SADIO.
  • Taller de Continuous Delivery y Prácticas DevOps,  es un taller de 8 horas que dictaré el 15 de Septiembre en Kleer@Montevideo y el 3 de Octubre en Kleer@Argentina. El siguiente video explica brevemente el contenido del taller.

 

Notas del Meetup sobre Patrones de Infraestructura para Continuous Delivery

Si bien había más de 100 inscriptos la cantidad de participantes fue alrededor de 30, lo cual es está dentro de los parámetros esperados para los Meetup gratuitos de Agiles@Baires. La mayoría de los asistentes eran desarrolladores (~80%) y el resto se repartía entre gente de operaciones/sysadmins y gente de gestión. La audiencia estuvo muy participativa, hubo varias consultas e incluso algunos participantes hicieron aportes desde su propia experiencia.

A mi gusto la sesión fluyó muy bien, sobre todo considerando que fue la primera vez que la hice. Fueron alrededor de 80 minutos de exposición, con algunas preguntas intercaladas, y otros 20 minutos dedicados exclusivamente a consultas. De cara a la presentación en Agile, voy a tener que hacer varios ajustes y practicar un poco más, ya que el límite de tiempo que tengo es de 75 minutos y al mismo tiempo al ser una sesión en inglés es posible que no tenga tanta soltura en la oratoria.

Agradezco a todos los participantes por el feedback y les dejo aquí los slides utilizados.

 

Meetup Agiles@BAires: Infrastructure Patterns for Continuous Delivery

El próximo jueves 20 de Julio en el Meetup de Agiles Argentina estaré dando esta sesión. El título está en inglés porque la sesión la preparé originalmente para darla en la conferencia Agile 2017 y darla ahora en Buenos Aires me sirve en cierto modo como un ensayo.

Comparto algunos datos de esta sesión que pueden resultar de interés para la audiencia:

  • Formato: charla tradicional, basada en diapositivas, condimentada con algunas actividades interactivas.
  • Duración: ~80 minutos
  • Audiencia: gente de perfil técnico sin ningún conocimiento previo en particular
  • Palabras clave: continuous-delivery, devops, automation, infrastructure as code

La sesión está estructurada en 2 bloques:

  • un primer bloque introductorio donde repasamos algunos conceptos básicos de continuous delivery/devops
  • un segundo bloque dedicado a presentación de diversos patrones entre los que se incluyen: incremental environments, automation layers, multi-versioning y split pipeline entre otros.

La cita es en la Facultad de Ingeniería de la UBA (Paseo Colón 850), en el aula 403 a partir de las 19 horas (puntual). Obviamente es totalmente gratis pero por favor los interesados registrarse en la página del Meetup.

Mis sesiones en Agile 2017

En agosto estaré participando por primera vez en la conferencia Agile donde estaré presentando dos sesiones:

Ambas sesiones están inspiradas en las experiencias y lecciones aprendidas que he recolectado en los últimos años. Ambas sesiones son en formato presentación con una duración de 75 minutos (con espacio de preguntas incluido).

A modo de ensayo, estaré dando la segunda de estas sesiones el próximo Jueves 20 de Julio en el contexto del Meetup de Ágiles Argentina. La cita es en la Facultad de Ingeniería de la UBA a las 19 horas (aula a confirmar).