Categoría: opinion

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.

Sobre mi disertación de Software Delivery en la Maestría del Italiano

Ayer estuve dando una charla sobre Software Delivery en el contexto de la Maestría en Informática en Salud del Hospital Italiano. Esta maestría es relativamente nueva y resulta una oferta interesante para profesionales ya que se dicta en una modalidad semi-presencial: cursada virtual + 2 semanas de cursada presencial por año.

Según me informaron los organizadores en la audiencia de la charla hubo alrededor de 150 personas. Me resultó una experiencia interesante ya que gran parte de la audiencia venía con un background de salud y su acercamiento a la informática era principalmente en roles de gerente, product owners y hasta stakeholders. En línea con esto muchos no estaban en el día a día del desarrollo de software sino más bien en la parte de implementación/operación. Esto me llevo a «moderar» un poco la terminología técnica que suelo utilizar y utilizar algunos ejemplos más relacionados a operaciones y gestión de servicios.

Agradezco a Fernando Campos y Angel Quiroga, docentes de la maestría, que fueron quienes me invitaron a dar esta charla.

Comparto aquí los slides que utilicé.

Historia de un proyecto (no tan) ¿ágil?

En este momento estoy participando en dos proyectos, en uno tengo un rol técnico y en otro un rol más de gestión. A este segundo caso quiero referirme.

El objetivo de este proyecto es reemplazar una aplicación de escritorio con una aplicación web de manera que esta aplicación web ofrezca algunas funcionalidades adicionales. El equipo tiene varios developers y un tester. Yo me sumé al proyecto meses después del primer release (que llevó un 1 año) con el objetivo de intentar mejorar el flujo de trabajo ya que el equipo venia con algunos problemas de estimación, planificación y ejecución. Si bien el propio equipo decía estar trabajando «de forma ágil» en mi opinión no era así, pero a mi parecer esto no era un problema, ya que trabajar de forma ágil no lo veo como un fin en si mismo, sino como un medio para un fin. Desde la perspectiva del cliente el producto entregado estaba muy bien en términos de usabilidad, calidad, etc, pero el proyecto no estaba tan bien ya que el avance era lento y la fecha de fin de proyecto estaba retrasándose recurrentemente. El proyecto tenia una infrastructura de CI con muy pocos tests automatizados, pero con una importante cantidad de casos de pruebas de ejecución manual. El proceso de deployment estaba automatizado.

Lo primero que hice al sumarme al proyecto fue lo mismo de siempre: observar, preguntar y medir. Luego propuse algunos experimentos en la forma de estimar y planificar. A continuación propuse establecer una cadencia en el proceso de desarrollo, hasta ese momento el equipo hacía iteraciones de 10 días hábiles de desarrollo (coding y testing), lo cual hacía que los dias de review y planning cayeran en días variables. Ajustamos esto y establecimos los lunes (cada 2 semanas) como día de review+retro+planning. Todo esto ayudó a establecer un ritmo estable, predecible y facilitó la interacción con los usuarios. Estos cambios también fueron muy bienvenidos por el Product Owner. Antes cada cambio propuesto volvimos a medir para confirmar si se había producido una mejora concreta o no. La semana pasada acordamos establer una cadencia de release haciendo 1 release por mes.

Continuará…

Nueva edición del taller de Prácticas DevOps y Continuous Delivery

Los días 28 y 30 de mayo estaré dictando estos dos taller junto a la gente de 10 Pines. Como siempre hice algunos ajustes en el contenido:

  • Agregué un ejercicio de Kubernetes puro, que complementa el ejercicio de OpenShift que ya tenía
  • Actualicé el setup de los ejercicios de Jenkins para usar Docker como builder
  • Actualicé el material de teoríco incluyendo algunos slides con cuestiones que leí en el workbook de SRE.

Los interesados pueden encontrar más detalles en la página de 10 Pines University:

Sobre el State of Agile Report 2019

Hace un par de dias se publicó este reporte surgido de la encuesta que realiza anualmente la empresa Version One. Los resultados no me soprendieron, al contrario, me resultaron muy familiares respecto de lo que veo en mi día a día.

En el resumen ejecutivo se destacan tres puntos.

1. Scrum (y SAFE) sigue siendo el enfoque agile más popular

No me sorprende y en un punto me parece esperable ya que más allá de las bondades de Scrum, es el enfoque ágil con mayor marketing: Scrum Alliance, Scrum.Org, Certified Scrum zaraza, etc

2. La cultura organizacional es el mayor impedimento para adopción y escalamiento de agile

Me parece esperable considerando que agile es un mindset, una forma de hacer las cosas e incluso un forma de pararse frente a los problemas y desafios

3. DevOps es cada vez más relevante

Tengo la sospecha que esto se debe a que mucha de la gente que trabaja con Scrum, hace en realidad un Flaccid Scrum, o sea, solo aplican la parte de gestión de Agile. Pero en un punto toman conciencia que sin prácticas técnicas varias «promesas de Agile» no son posibles. Pero como ya se gastaron todo el presupuesto de Agile en tomar los curso de «Certified Scrum/Agile XXXX» ahora necesitan otro buzzword para conseguir presupuesto y ahí está DevOps al alcance de la mano.

El problema no está en la estimación

Recurrentemente escucho equipos decir que tienen problemas con la estimación, pero cuando tengo la oportunidad de trabajar con ellos durante un par de iteraciones queda en evidencia que la estimación es solo una pequeña parte del problema. El problema grueso suele estar en la ejecución.

Describo el caso típico: un equipo estima que en una iteración completará una cantidad N de ítems. Al finalizar la iteración resulta que completa Z ítems siendo Z bastante menos que N. Instantáneamente se cree que el equipo estima mal.

Entonces me sumo a la dinámica de trabajo del equipo durante una iteración participando de sus Planning, Review, Retros y Dailies. Una vez más el equipo compromete N ítems pero completa Z ítems (N>>Z), pero adicionalmente a eso detecto las siguientes situaciones que ocurrieron durante la iteración:

  • Se trabajaron a pedido del cliente otros ítems que no eran parte del plan inicial de la iteración
  • También se invirtió esfuerzo en arreglar el servidor de tests que dejó de funcionar debido a un update no planificado
  • Parte del equipo tuvo que participar de una reunión con otro equipo que planea reutilzar algunos de los componentes desarrollados por este equipo
  • Un miembro del equipo enfermó y estuvo en cama 2 días sin poder trabajar.

Todas estas cuestiones fueron realizadas sin modicar el plan/compromiso de la iteración y tampoco fueron registradas en ningún lado. De haberse registrado, la lectura de la iteración sería:

  • Se comprometieron N items
  • De los N items comprometidos se completaron Z (siendo Z menor a N)
  • Adicionalmente se completaron otros A items que no estaban planificados
  • Muchas veces A + Z es mayor o igual a N

El haber trabajado en items nos planificados y no haber gestionado correctamente su inclusión nos indica que hay un claro problema de ejecución.

Luego de haber visto recurremente esta situación he decidido armar un taller de planificación adaptativa y seguimiento de proyectos para intentar ayudar a los equipos con problemas de estimación, planificación y ejecución.

Sobre la formación de gente de Infraestructura / Operaciones / SysAdmins / DevOps / SRE / CloudOps y otros

Recientemente recibí una consulta de un lector de mi blog contandome que estaba comenzando a trabajar como junior en cuestiones de infraestructura y me hacía una consulta sobre escalabilidad. Esa consulta, sumada otras tantas de similar índole que suelo recibir, me llevó a escribir este post.

Algunas aclaraciones preliminares de mi punto de vista:

  • En términos muy generales cuando hablo de «gente de infraestructura», me refiero a las personas que configuran/administran recursos tales como servidores, redes, cluster, sistemas operativos, etc. Tradicionalmente estas personas se las ha calificado con el término SysAdmins y en el mundo Microsoft se los llamaba en una época ITPros
  • Con el auge de los movimientos de DevOps y Reliability Engineering, y la nube en general, algunos SysAdmin se han «reconvertido» (¿o simplemente renombrado?) como DevOps Engineers, Site Reliability Engineers o Cloud Engineers. Las diferencias entre estos diversos títulos no está completamente clara y para lo que hace a este artículo me voy a referir a todos ellos en forma genérica e intercambiable.
  • Voy a centrarme en particular en el rol del SysAdmin que tiene que interactuar con equipos de desarrollo.

Bien, considerando entonces el contexto actual me parece que todo SysAdmin que trabaje con un equipo de desarrollo de software (ya sea como parte del equipo o bien como proveedor de servicios al equipo) debe entender de desarrollo de software, más aún, creo que debería tener experiencia en desarrollo, al menos un par de años como programador. De hecho en el libro de SRE se dice que para el rol de SRE Google suele buscar ingenieros de software.

Por otro lado siempre he tenido la sensación de que no abunda el material de estudio para formar SysAdmins. O sea, hay mucho material sobre productos pero poco sobre cuestiones más conceptuales de diseño, patrones, procesos. En este sentido creo que las publicaciones de SRE de Google son un gran aporte.

Continuará…

Sobre el WICC 2019

La semana pasada estuve participando del Workshop de Investigadores en Ciencias de la Computación WICC 2019 que se realizó en la Universidad Nacional de San Juan. Fue mi primera participación en este congreso organizado por la Red de Universidades Nacionales con carreras de Informática. Esta conferencia tiene como objetivo promover el intercambio y la difusión de temas entre investigadores del área. En términos generales, el congreso consta de 2 actividades:

  • por un lado la exposición de póster presentados por los distintos investigadores. Luego de un par de horas de exposición donde los asistentes recorren la muestra, hay mesas de charla/intercambio organizadas por área temática
  • por otro lado está la reunión de RedUnci donde se presentan y discuten distintas iniciativas llevada a cabo por la red.

Más allá de estas dos cuestiones hay un acta de apertura, un acto de cierre, una cena de camaradería y alguna conferencia magistral.

Yo particularmente estuve presentando un poster sobre nuestro proyecto de investigación Procesos y Prácticas Ágiles en el Desarrollo de Software.

Taller Online de Docker & Kubernetes: segunda edición completa

La semana pasada completamos la segunda edición de este taller. A diferencia de la primera edición, el flujo de los encuentros fue un poco más «trabado», pues hubo mucha charla. O sea, hubo un par de participantes muy entusiastas con muchas inquietudes que generaron preguntas, idas y vueltas. Esto esto estuvo muy bueno en cierto sentido pero al mismo tiempo generó que algunas de las explicaciones tuvieran menos profundidad o que incluso no llegaramos a hacer algún ejercicio. Al mismo tiempo hubo otros participantes que apenas hablaron. No se si una dinámica así (de mucha idea y vuelta) es mejor o no, pero definitivamente es algo a repensar y moderar para una siguiente edición.

Más allá de este detalle, el resultado del taller fue muy positivo. Estoy completamente convencido de este formato de curso y seguramente lo estaré utilizando en futuros cursos sobre nuevas temáticas.

Guía de Unit Testing – parte 1

Cada vez que empiezo a trabajar con un nuevo equipo, tarde o temprano teminamos hablando de pruebas unitarias. Al mismo tiempo es un tema que dicto en mis materias de Ingeniería de Software. Pero dado que no he encontrado un material que cubra el tema de una forma que me resulte 100% convincente, he decidido escribir esta guía. Aquí va la primera parte.

Las pruebas unitarias son una pieza fundamental para controlar la calidad del software que desarrollamos. A diferencia de lo que ocurre con otros tipos de pruebas, en el caso de la pruebas unitarias hay un concenso absoluto en que las mismas son responsabilidad del desarrollador.

Entre los beneficios que nos proveen las pruebas unitarias se cuentan:

  • Ayudan a encontrar problemas rápidamente, ya que por su naturaleza operan sobre una porción puntual y acotada de código
  • Actúan como un mecanismo de seguridad a la hora de hacer modificaciones en el código, facilitando así el desarrollo iterativo
  • Son en cierto modo documentación ejecutable lo cual a la largo plazo facilita la evolución del código

Estando entonces convencidos que queremos hacer pruebas unitarias, comencemos por dejar en claro que NO es una prueba unitaria. Según Michael Feather a test is not a unit test if:

  • It talks to the database
  • It communicates across the network
  • It touches the file system
  • It can’t run at the same time as any of your other unit tests
  • You have to do special things to your environment (such as editing config files) to run it.

En términos más generales una prueba unitaria prueba un elemento en forma aislada, siendo ese elemento típicamente un objeto o un método.

Continuará…