El fenómeno JavaScript

Si bien JavaScript tiene unos cuantos años, desde el auge de la web 2.0 su popularidad ha ido constantemente en ascenso. En los últimos años han aparecido diversas herramientas y frameworks que permitieron a JavaScript ir más allá de los navegadores web.

Como efecto colateral, ya no importa si uno se consideraba programador Java, C# o Ruby, hoy por hoy todo el mundo debe tener cierto manejo de JavaScript.

Personalmente nunca me gustó JavaScript pero a pesar de eso no dudo en usarlo cuando creo que es la opción apropiada para una determinada solución. Eso me llevo a trabajar con jQuery y Node.js.

Recuerdo que hace dos o tres años, mientras que en el mundo JavaScript empezaban a surgir diversos frameworks y herramientas, en el mundo de los Sysadmins empezaban a popularizarse herramientas de automatización de infraestructura. Justamente en el aquel momento me encontré en un contexto en el que tuve que elegir trabajar como desarrollador FrontEnd con JavaScript o bien tomar un rol de SysAdmin/DevOp y meterme con las herramientas de automatización. Precisamente fue esta última opción la que elegí. Creo que profesionalmente aquella fue una elección muy acertada pues el manejo de herramientas de automatización me permitió participar en diversos proyectos muy interesante. Pero hace un par de meses me rendí, siendo consciente que ya no es posible escapar de la marea JavaScript me puse a aprender AngularJS y agregué a mi backlog Meteor y React.

 

Cursos en la previa de Agiles 2015

Como de costumbre en la previa de Agiles 2015 habrá un conjunto de cursos organizados de forma independiente. En ese contexto estaré dictando en Montevideo mi Taller de Continuous Delivery y Prueba automatizada.

El términos generales el taller está divido en 2 partes. La primera enfocada en los conceptos centrales de la práctica de Continuous Delivery y un conjunto de técnicas y herramientas para su implementación que incluyen Jenkins, Puppet y Docker. La segunda se enfoca en la automatización de pruebas, lo cual constituye un punto fundamental en toda estrategia de Continuous Delivery. En esta segunda parte veremos herramientas tales como JUnit, Cucumber-JVM y FitNesse. Si bien el taller tiene una base conceptual independiente de toda tecnología, la parte práctica de automatización de pruebas se realiza con Java.

Los detalles de logística e inscripción están disponibles en la página de Evolución Ágil.

Prácticas DevOps: 3 repos por proyecto

Desde que empecé a trabajar fuerte con prácticas de DevOps, hace unos 2 o 3 años que todos mis proyectos tienen al menos 3 repositorios.

El primer repositorio es el que almacena el código fuente de la aplicación. En realidad dependiendo de la complejidad del proyecto, puede que haya más de un repositorio para el código fuente.

El segundo repositorio es el almacena la configuración de la aplicación. Este repositorio tiene típicamente un 1 branch por ambiente. Hay que destacar que estoy branches nunca se mezclan, sino que evolución a la par. Cuando la aplicación requiere de un nuevo parámetro de configuración, el mismo debe ser agregado simultáneamente a cada uno de los branches con el valor correspondiente para el ambiente asociado.

Finalmente el tercer repositorio es el que contiene los scripts de deploy. Dependiendo de la infraestructura del proyecto puede que sean simplemente scripts de bash, ansible, puppet o similar.

Se viene WISIT 2015

Este sábado 19 de septiembre se llevará a cabo la jornada principal del Workshop de Ingeniería en Sistemas y Tecnologías de la Información, WISIT 2015 organizado por la gente de Proyecto Uqbar. Esta tercera edición tendrá su jornada principal en las instalaciones de la Universidad Nacional de Quilmes. Hablo de jornada principal, pues ya hubo algunas actividades que realizaron la semana pasada en instalaciones de Universidad de Buenos Aires.

El programa completo de la jornada incluye varias propuesta muy atractivas con cuestiones de Big Data, Devops, lenguajes de programación y Agile. Respecto de esto último tengo el honor de haber sido invitado a participar de un panel de discusión sobre metodologías ágiles bajo la consigna «Presente y futuro de las metodologías ágiles«.

Como de costumbre la entrada es gratuita pero hay que registrarse aquí.

En mi opinión es una jornada para no perderse.

wisit15

Capas de automatización

Este último año y medio he estado trabajando intensamente en cuestiones de automatización de pipelines e infraestructura en general, usando principalmente Jenkins, Puppet y herramientas afines.

En particular, estos últimos meses he trabajado en la automatización de despliegues de un producto software bastante complejo. La complejidad en este caso está dada por la gran cantidad de componentes de código e infraestructura involucrados: varias bases de datos relacionales, bus de servicios, sistema de colas, servidor de aplicaciones, servidor web, dispositivos móviles, etc. Al mismo tiempo el producto tiene un requerimiento de correr sobre distintos sabores de infraestructura (Oracle, IBM, OpenSource), lo cual requiere que cada ambiente (desarrollo, test, etc) tenga también varios sabores.

Para la generación de estos ambientes y el deploy de la solución a cada uno de ellos diseñamos una arquitectura de automatización/deploy de 3 capas la cual describo brevemente a continuación.

Capa 1: Sistema operativo

El primer paso es levantar los servidores con el sistema operativo correspondiente (para el caso mencionado CentOS y Oracle Linux) y realizar algunos ajustes de base sobre el mismo (configuración de red, usuarios, etc). En general esto se hace utilizando la API de la plataforma de virtualización y algunos scripts de base. Puntualmente en el mencionado caso usamos el Hypervisor de VMWare y Puppet.

Capa 2: Software de base

Ya con el sistema operativo instalado y servidor 100% funcional hay que instalar software de base: motor de base de datos, el service bus, el web server, etc. Cada uno de estos componentes hay que instalarlos y configurarlos acorde a seteos específicos de la solución. En el caso mencionado esto lo hicimos usando scripts Ansible que se disparan desde RunDeck

Capa 3: Aplicación

Lo último que resta es instalar la solución en cuestión, lo cual implica crear los schemas de base datos, desplegar las aplicaciones en los servidores/contenedores web, desplegar los flujos en el bus de servicios, etc. En el caso en cuestión esto lo tenemos implementado con simples bash scripts que lanzamos desde Jenkins.

La implementación de esta solución en este caso puntual requirió del trabajo de distintas áreas de la organización: gente de infraestructura (capa 1), gente de operaciones (capa2), gente del grupo de producto (capa3) y obviamente hubo también un cierto esfuerzo de coordinación de todos ellos.

Hay algunas cuestiones de la implementación de este caso que aún hoy no me convencen (como usar Puppet Y Ansible al mismo tiempo, hubiera preferido usar sólo 1 de ellos) y que son consecuencia de decisiones tomadas por los distintas áreas de la organización. Más allá de las herramientas particulares, creo que el esquema general de esta solución es replicable en otros contextos usando incluso otras herramientas, es por ello que decidí compartir estas líneas.

capas_automatizacion