Sobre las Certificaciones DevOps

Sobre las Certificaciones DevOps

El tema certificaciones en el mundo IT siempre ha generado polémicas. Recuerdo que en mis primeros años de universidad estaban muy de moda las certificaciones de Sun, Oracle y Cisco.

Tiempo después se pusieron de moda las certificaciones de Agile. En particular la certificación de Scrum Master se ha vuelto muy popular (y muy debatida).

El año pasado se popularizó una ola de certificaciones de “Agile a Escala” con temas tales como SAFe, LeSS y Nexus.

Ahora me parece que estamos en una nueva ola de certificaciones. En los últimos 10 días recibí dos consultas concretas sobre certificaciones DevOps. Para sorpresa de algunos efectivamente existen certificaciones DevOps, listo algunas aquí:

Yo personalmente no tengo ninguna certificación, ni tampoco ofrezco certificaciones por los los cursos que dicto.

test && commit || revert

Esta es una idea experimental de la cual Kent Beck comenzó a hablar hace un par de meses. La primera vez que escuché al respecto me sonó raro. Ya llevo varias semanas dándole vueltas y me sigue resultado raro pero el hecho de haber estado probándolo me permitió reflexionar sobre mi flujo de trabajo al programar.

Más aún, he estado trabajando en un mini-taller exploratorio de TCR para compartir esta idea y poder destilarla en conjunto con otros practicantes. Voy a aprovechar el Open Space que se realizará en Buenos Aires en el contexto de la semana de la agilidad, los interesados traigan sus notebooks, git y ganas de codear.

No más .dlls en Git: infraestructura de desarrollo .Net

Una y otra vez me encuentro con equipos de desarrollo trabajando con tecnología .Net que guardan .dlls (librerías/packages) en repositorios de código fuente. Esto fue una práctica común en una época (lejana) y que yo mismo utilicé en algún momento. Pero desde la aparición de NuGet la gestión de librerías en en mundo .Net tomó un camino distinto.

Cuando uno tiene una dependencia de una librería a nivel binario, simplemente declara la dependencia en un archivo package.json y la herramienta NuGet se encarga de buscarlo en el repositorio binario y descargarlo. NuGet por default busca las librerías/paquetes en https://www.nuget.org/. Sin embargo hay dos casos donde seguramente no encontremos la librería en este repositorio:

  • Si estamos usando librerías de terceros, puede que por algún motivo esos terceros no hayan publicado el correspondiente paquete en nuget.org y dependiendo del tipo de licencia del paquete puede que no tengamos derecho a publicarlo nosotros mismos en un repositorio abierto.
  • Por otro lado es muy común hoy en día con el auge de los microservicios que uno tenga librerías propias que utilice en diversos proyectos de la organización y a menos que nuestros proyectos sean open source, es poco probable que querramos publicar esas librerías en nuget.org

Entonces, para estos dos casos la estrategia a seguir es utilizar un repositorio privado de binarios ya sea on-prem (instalando por ejemplo un Nexus) o utilizando algún servicio en la nube (como por ejemplo myget).

Si ponemos todo esto en contexto, una arquitectura de desarrollo de referencia podría incluir:

  • Un servidor de repositorios de código fuente, por ejemplo alguna implementación de Git como GitHub, GitLab o BitBucket.
  • Un servidor de CI/CD como Jenkins o TeamCity
  • Un servidor de repositorios de binarios NuGet como Nexus, MyGet o Artifactory

Simplificando el setup de Jenkins con Docker

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'
}
}
}

Taller Online de Docker & Kubernetes: resultado de la primera edición

La semana pasada completé la primera edición de este taller. Participaron 8 personas, porque si bien hubo alrededor de 30 interesados, decidí limitar la cantidad de participantes pues no estaba seguro de como funcionaría la herramienta de conferencia. Por suerte funcionó bien.

El taller consistió en 4 sesiones online de entre 1 y 2 horas cada una. Estimar la duración de la sesiones es lo que más me costó, en parte por ser un contenido nuevo y en parte por ser una dinámica nueva.

La evaluación de los participantes fue muy positiva:

  • Evaluación general del taller: muy bueno 50% , excelente 50%
  • Evaluación de los encuentros online: muy bueno 66%, excelente 30%
  • ¿Recomendarías este taller a un colega? Definitivamente si 100%

Por otro lado las respuestas de feedback libre fueron también muy positivas. A partir de estos resultados y dado el interés que hay en la temática, en breve estaré anunciado la fecha de la próxima edición. Los interesados pueden pre-registrarse aquí y los contactaré cuando tenga los detalles de la nueva siguiente edición.

Les comparto una foto de mi “estudio de transmisión”. Al centro mi computadora primaria con una segunda pantalla conectada a la izquierda. La pantalla de la computadora la utilizo para pasar las diapositivas y mostrar las herramienta mientras que la pantalla extendida la utilizo para la conferencia y el chat con los participantes. Del lado derecho, mi computadora secundaria como plan B en caso de que por algún motivo mi computadora primaria deje de funcionar. Junto al teclado mi cuaderno de anotaciones. Finalmente en el banquito de madera, un infaltable: el mate.