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.