DevOps en el INSSJP y comentarios personales

Estoy intentando responder la pregunta de un gran profe que tuve en mi segundo año en la UTN.FRBA, Ing. Pablo Jejcic allá por el 2000. La pregunta fue, “cual es la visión en Argentina de DevOps?” acá va mi respuesta.
Entendiendo por DevOps al conjunto de procesos y herramientas que se centran en la integración entre los equipos de desarrollo y operaciones, rol que muchas veces toma un Arquitecto que tiene que transformar las unidades de desarrollo (componentes) en unidades de despliegue (war, dll, zip, etc) y ejecución dentro de colaboración, esta metodología fomenta el uso de la automatización, para asegurar el aprovisionamiento, despliegue y monitoreo para responder a las necesidades del negocio.
Cuando comenzamos este fantástico viaje de Gerenciar las TICs del Instituto, tuvimos grandes desafios:

• Entornos de desarrollo no homogeneos para todas las Apps
• Muchos errores durante los Deploys
• Diferentes versiones de Middleware, Configuraciones y Políticas en los Servidores
• Imposibilidad para el equipo de Operaciones de monitorear o saber si el sistema estaba funcionando o no.

Nada sencillo, parte del tiempo del equipo de Liderazgo de la Gerencia estaba rogando y verificando muchísimos detalles y con más de 80 deploys por semana, que eran un desgaste increíble, mucha tensión y marcándose con el dedo entre un equipo y otro. Algo teníamos que hacer, pero tenía que se con mucho cuidado y que todos sean parte de la solución para sumarlos al mismo barco.
Como fue más o menos el plan por aplicación:

1. Definimos una política de versionado, X.Y.Z.YYYYMMDD.N (ej. 2.1.3.20140805.1) y creamos un servidor donde el Líder de Desarrollo cargaba las unidades de despliegue por sistema y versión.
2. Armamos entornos de desarrollo (servidor) para todas las Applicaciones, y todo deploy primero tenía que funcionar en dicho entorno, Dev podría hacer deploys pero no tocar la configuración. Luego pasaba a QA, PREPRO y PROD vía Operaciones con los instructivos.
3. Separamos la configuración de la unidad deploy, para poder utilizar el Repo
4. Instalamos Jenkins y fuimos automatizando el deploy de todas las aplicaciones, donde solo se desplegaba en PROD algo ya desplegado en un entorno más bajo.
5. El equipo de desarrollo arrancó a usar un Jenkins en modo integración continua donde se ejecutan los Test y Métricas de Calidad, y que termina dejando las unidades de despliegue en el REPO.

A su vez, armamos la reunión de planificación semanal, llamada DevOps, que nació con la presentación de 10 Deploys por día de Flikr. Otro proyecto en paralelo fuimos instalando la herramienta de Gestión y Monitoreo, con Tickets y Checkeos de todo tipo, a cada aplicación le agregamos un servicio web que devolvía su estado, llamado “checksystem” y en cada deploy se verificaba su estado y obviamente el monitoreo 24x7.

¿Que estamos haciendo ahora de DevOps?
Demás está decir que este esto no termina acá, y que tenemos muchísimos proyectos relacionados con DevOps, el más interesante está relacionado con la instalación de un Orquestador de Infraestructura que nos permite automatizar el aprovisionamiento de toda la infraestructura virtualizada y despliegue automática de la configuraciones necesitadas para la misma. La herramienta que estamos usando es Puppet en conjunto con CouchDB. Esta plataforma nos permite levantar, instalar y configurar máquinas virtuales, desplegar el código fuente via Jenkins y agregar al balanceador F5 de manera automática los App Servers al cluster.
Puedo estar 2 horas de este proyecto tan interesante pero creo que alcanza para responder la pregunta, y dejo para otro momento como veo el futuro de DevOps desde mi perspectiva y la del INSSJP.

Seminario de Actualización Profesional en Gerencia Pública Informática

Hoy comenzó un seminario muy interesante en la Sadio. Y tuve la oportunidad de escuchar a quien considero el mejor CIO de la historia de la Argentina, Jorge Linskens. La verdad que el seminario me llegó de rebote, no lo tenía en el radar pero a último momento pudimos inscribirnos y estoy super contento.
El seminario consiste en brindar una serie de clases en lo referido al ambiente público, manejo de recursos humanos, contrataciones, seguridad, sistemas de la administración publica y gestión en general.
Igual considero que ya solo con la clase de hoy el seminario valió la pena, Jorge Linskens para quienes no lo conocen, aparte de haber trabajado casi 50 años en IT (eso me pareció escuchar hoy) concretó una revolución tecnológica en AFIP allá por el 2002 y varios años más, y creo que hoy todavía AFIP sigue con la inercia de esa época donde crearon un datacenter, una arquitectura de servicios de información muy interesante (declaraciones juradas, factura electrónica, volantes de pagos electrónicos, etc). Cada vez pienso en lo que armó junto a su equipo, siempre digo que en Pami estamos haciendo lo mismo, un poco después pero con la misma visión de hacer historia, y tenemos un contexto muy favorable...
Jorge comentó la importancia de ser un funcionario publico y a quien respondemos, y dentro de su inigualable experiencia puso mucho foco en tres planos:

1. Como aprovechar el capital humano, como subirlos al proyecto teniendo en cuenta el contexto (sueldos, gremios, sin premios ni castigos)
2. Como crear Arquitectura Simples y Robustas, muchos me habían dicho que era un excelente técnico, como nunca lo había escuchado me encantó saber que hay CIOs tan groso en lo técnico también.
3. Contrataciones públicas, aceptar la realidad de los tiempos y como organizarlas alineadas con la Arquitectura y como escribir pliegos para evitar litigios con los proveedores (capitulo aparte).

 Como lo dije anteriormente, ya hoy valió el seminario, va a ser dificil que los próximos profes puedan mejorar esto, dejó la vara super alta :)