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.

Encuesta de Sueldos IT

Encuesta de Sueldos IT

Hace unos días me llegó un mail de la gente de SysArmy con la invitación para completar la encuesta de sueldos que hacen en conjunto con Openqube.

Esta encuesta se hace dos veces por año lo cual me parece una muy buena iniciativa (aquí están los resultados de la segunda edición de 2018).

Complementariamente a la encuesta, la plataforma Openqube es un sitio que recolecta y sumariza información sobre empresas del sector informático, una fuente excelente para consultar a la hora de evaluar cambios de trabajo.

Libro: Agile Software Requirements

Por estos dias estoy leyendo el libro Agile Software Requirements, de Dean Leffingwell, un libro que compré el año pasado pero que en aquel momento leí apenas algunos capítulos. El libro pertenece a la serie Agile Software Development de Addison-Wesley cuyos editores son Alistair Cockburn y Jim Highsmith. La edición física es excelente, es un libro tapa dura con un formato de página muy ameno a la lectura.

El autor, Dean Leffingwell, ha cobrado cierta popularidad en los últimos años por ser el creador de SAFe, uno de los enfoques de escalamiento de Agile más difundidos en la actualidad. Sin embargo yo ya conocía a Leffingwell por un libro anterior que escribió a fines de los 90′: Managing Software Requirements: A Unified Approach.

El libro propone un enfoque ágil para el manejo de requerimientos a distintos niveles: empresa, programa y equipo. En cierto modo el enfoque propuesto es como una precuela de SAFe (digo esto sin conocer demasiado de SAFe). Aunque aún no terminé de leerlo, me parece que el enfoque propuesto es muy completo sobre todo teniendo presente que inicialmente el foco de los métodos ágiles estaba a nivel de equipo. Me parece importante destacar que el libro no se queda solo en el tema de requerimientos, sino que también tiene capítulos enteros dedicados a temas como arquitectura, planificación y testing entre otros.

Cómo mejoré mis estimaciones

Las estimaciones son un desafió cotidiano para muchos equipos de desarrollo de software pero curiosamente hay mucho material y de larga data sobre este tema. Sin embargo cada vez que me cruzo con equipos y personas que tienen dificultades para hacer estimaciones precisas, les pregunto si estudiaron el tema y la respuesta que suelo obtener es: no. Es como que mucha gente se resigna a que sus estimaciones sean muy imprecisas o esperan que mágicamente sus estimaciones mejoren.

Más allá del comportamiento de “la gente” hay que destacar un punto ¿que es lo que nos enseñan en la universidad sobre estimación? En mi caso tuve 1 clase sobre estimación y fue 100% teórica. Lo único que saqué de esa clases fue una lista de nombres de métodos de estimación, pero sin siquiera entender seriamente las diferencias entre ellos. Más aún, nunca en toda la carrera tuve un ejercicio específico de estimación.

Obviamente con esa formación escasa, yo también tuve dificultades con las estimaciones, pero en un momento decidí estudiar el tema seriamente y eso me ayudó mucho. Estudié diversos métodos de estimación y los puse en práctica. Conté puntos de función, utilicé software de estimación (como Construx Estimate), CoCoMo, Planning Pocker, Dephi (y sus variantes), estudié probabilidad, estadística y otras N yerbas relacionadas. Y hasta escribí un capítulo de un libro sobre estimaciones. Hoy en día estoy muy conforme con mis estimación ya que tengo un desvió menor al 10%.

Analicemos la cuestión un momento. El problema parece ser que uno estima que algo llevará tiempo TE y se pone a hacerlo y termina llevando TR, siendo TR >> TE. Ojo si fuera TR << TE, la estimación también sería “mala”. Lo que uno pretende es que TE ~ TR ¿hasta que punto es aceptable la diferencia entre TE y TR? Dependen del contexto y del objetivo de la estimación. Pero eso será tema de un futuro artículo, ahora voy a referirme a cuestiones más generales.

A mi parecer en la gran mayoría de los casos la situación es que el tiempo real es bastante mayor al tiempo inicialmente estimado (TR >> TE), pero en mucho casos el problema no está en la estimación sino en la ejecución. Muchas veces no nos dedicamos de lleno a la tarea sino que mientras hacemos la tarea seguimos viendo twitter, o contestando mail, o leyendo whatsapp. También es común que aparezca alguna otra tarea imprevista de mayor prioridad y entonces dejamos colgada la tarea X. Este “task switching” es extremadamente perjudicial y termina impactando en el tiempo real que nos lleva la tarea sobre todo si no llevamos un registro de las interrupciones.

Más allá de la precisión de la estimación, gran parte del problema radica en la ejecución.

¿Cómo podemos hacer entonces para mejorar la ejecución? Para mi aquí hay dos puntos claves:

  • Llevar registro de las tareas, los tiempos y las interrupciones para tener números concretos que nos muestren como es la realidad
  • Planificar el trabajo en pequeños incrementos, procurando que en principio ninguna tarea exceda un par de horas de trabajo.

Planificar el trabajo en pequeños incrementos ayuda a disminuir las interrupciones y mejorar la ejecución

Volviendo al tema concreto de la estimación, algo concreto que suelo hacer es combinar diversas técnicas de estimación, pero eso será parte de otro artículo.

Continuará…

Balance 2018 y Plan 2019

En 2018 tuve la oportunidad de trabajar con empresas amigas como 10Pines, Grupo Esfera y Auth0. Participé de 7 conferencias. Publiqué 2 papers formales y 79 artículos en este blog. Mi dedicación industria / academia fue ~ 63 / 37.

Distribución de dedicación Industria vs Academia

Dentro del ámbito industrial estuve haciendo básicamente 4 tipos de tareas:

  • Proyectos de automatización, me sumo a un equipo para hacer tareas de automatización, o sea, soy parte de un equipo y trabajo en una dinámica de proyecto.
  • Training/capacitación, esto incluye tanto cursos, como tareas de generación de contenidos y afines
  • Proyectos de mentoring, me sumo a un equipo en el contexto de un proyecto para ayudarlos a mejorar algunos aspectos de su dinámica de trabajo.
  • Consultoría, son trabajos bien puntuales, de un par de sesiones donde opino, asesoro, ayudo a pensar, etc

Más del 60% de mi tiempo estuvo dedicado a proyectos de automatización, tanto de pruebas como de infraestructura/deployment, dos cuestiones que suelen ir de la mano. Uno de los principales beneficios que se esperan al automatizar es ganar velocidad, por ello si se automatiza la infraestructura y deployments, se termina también automatizando las pruebas para que la ganancia en velocidad venga acompañada de estabilidad/calidad y viceversa. Por otro lado, el ~25% de mi tiempo en la industria estuvo dedicado a training/capacitación en el ámbito privado, básicamente dictado de cursos, talleres, generación de contenido, etc. (esto no incluye mi trabajo en la universidad). Cabe aclarar que estos números surgen de mi registro de facturación y la forma bajo la cual son contratados mis servicios, pero suele ocurrir que muchas veces me contratan con un fin y luego termino haciendo algunas otras cosas. Un ejemplo clásico es que me contratan para un trabajo de consultoría y luego como parte de ese servicio termino dictando algún training.

Distribución de tiempo dedicado a la industria según tipo de tarea

Para 2019 estimo que seguiré en una situación global similar. Creo que seguiré trabajando fuertemente en temas de automatización ya que veo un importante crecimiento en el uso de Docker/Kubernetes, una temática en la que he acumulado bastante experiencia. En el ámbito académico tengo la intención de completar mi especialización en Tecnología Informática Aplicada a Educación y por otro lado es muy posible que también esté trabajando en la definición del plan de estudios de la Licenciatura en Informática de UNTreF.

Videos & Screencast sobre Desarrollo de Software

Hace un par de años comencé a hacer videos con el contenido de mis clases. Con el correr del tiempo fui probando distintas herramientas, plataformas y formatos. Finalmente me incliné por Camtasia como herramienta de grabación & edición, YouTube como plataforma de publicación y screencast como formato de video.

Aprovechando el recreo de fiestas de fin de año, estuve acomodando mis videos en YouTube y moviendo videos que tenia publicados en otras plataformas. A partir de esto tengo en este momento un canal de YouTube con diversas listas de reproducción que agrupan videos con temas tales como: DevOps, UML, Git e Ingeniería de Software entre otros.

Espero les resulten útiles.