Apropiando DevOps

DevOps es un ENFOQUE, una propuesta para organizaciones de IT, sobre la manera de atender un requerimiento de mejora, una corrección de errores, una nueva característica, un nuevo módulo de un producto o un producto completamente nuevo, y cómo llevarlo a Producción cuanto antes basado en un esquema de “lotes de funcionalidades” o pequeñas piezas de valor para el cliente, de tal manera que este perciba nuevas características o mejoras, pueda utilizarlas y a su vez, proveer retroalimentación sobre lo que se puede mejorar tan pronto como sea posible.

Hasta ahora hemos identificado 3 puntos para mejora continua en este enfoque:

1. Mejorar el PRODUCTO que se está entregando
2. Mejorar el ENTORNO, es decir, la eficiencia de todo el ambiente de producción, de la infraestructura sobre la que se entrega esta funcionalidad
3. Finalmente la más importante acorde al contexto de esta nota. Mejora del PROCESO sobre el cual se está realizando la liberación de la funcionalidad, ya que al final del día, el objetivo de DevOps es hacer el proceso más eficiente, reducir los gastos generales y reducir el trabajo redundante.

Si vemos resultados de encuestas de muchas organizaciones IT, encontramos que la mayoría de ellas reportan altos sobrecostos en el reproceso de sus desarrolladores, incluso llegando en algunos casos llegando hasta el 50%. Así las cosas, si DevOps nos ayuda a recuperar entre un 5% a 10% va a ser de mucho valor apropiar este enfoque.

Cómo funciona DevOps:

Primero que todo veamos donde se puede originar el requerimiento: Este puede nacer en un problema de producción, en un ticket o error reportado por el cliente, por investigaciones del área de I+D+i, de las necesidades del mercado identificadas por el área comercial o de mercadeo de la industria, por nuevas legislaciones del estado que deben ser cumplidas… etc. Cualquiera de estas fuentes de requerimientos pueden hacer modificar el software.

Esta petición debe ser recibida por una “oficina de proyecto” (PMO), donde se prioriza y decide cómo y cuándo se debe atender. Puede ser en un reléase inmediato, o en un reléase posterior acompañado de otras funcionalidades próximas a ser liberadas, etc. Esta oficina decide también los recursos y esfuerzos a dedicarle. Acá se analiza si esto requiere un Ingeniero de requisitos, arquitecto, personal de gestión de cambio y analistas de negocio que ayuden en el diseño de tal forma que se determine si se requiere una nueva arquitectura o solo ajustes a la actual, si se modulariza o se libera por fases, etc.

Así entonces, este requerimiento se entrega a distintos grupos de trabajo de desarrollo, de testing de integración, testers de aceptación de usuario, personal de infraestructura, tester de pruebas no funcionales, ingenieros de producción, todos ellos trabajando en estrecha colaboración para lograr entregar oportunamente esta nueva funcionalidad o nueva capacidad del aplicativo.

Lo que busca DevOps es REDUCIR LOS CUELLOS DE BOTELLA entre estos distintos grupos de trabajo.

Es importante tener claridad sobre los distintos artefactos y tareas que los miembros de equipo deben realizar cuando están trabajando en el desarrollo de la funcionalidad, indistinto si se utiliza una metodología de desarrollo en cascada o ágil (dividida en Sprint´s e iteraciones).

• Los artefactos: Estos van evolucionando cambiando su estado convirtiéndose en otro artefacto. Como por ejemplo, el requerimiento se convierte en el diseño, el diseño a código, el código a binario.

• Los estados de las transiciones de ambiente: Que van desde los ambientes de desarrollo a los ambientes de prueba o de control de calidad, y posteriormente a los ambientes de producción cuando va a ser desplegada la funcionalidad a liberar.

• Los scripts de prueba : Se transforman en resultados de las pruebas, los resultados en defectos (si los hay), y así sucesivamente.

Piense por un momento en los desarrolladores haciendo todas esas transiciones para lograr la evolución de la idea a producto… Hay que lograr que los desarrolladores se dediquen a lo que saber hacer muy bien, dar vida a nuevas facilidades para los usuarios y oportunidades de negocio a través de sus líneas de código y no a crear o actualizar información de soporte.

Si usted y yo estamos de acuerdo, es esto lo que le aporta valor al negocio, pero… pueden hacerlo sin gestionar la evolución de artefactos, instalación de los ambientes (Desarrollo, Pruebas, Preproducción, producción) y scripts de prueba?… Qué tal automatizar el mayor número de esas tareas? .

Una Fábrica de tecnología o un área IT de una compañía de cualquier sector comúnmente se enfrenta a situaciones que quiere resolver para entregar valor de forma ágil y reducir el Time to Market.

• Incertidumbre : que hace que las personas trabajen en temas que no necesitan y se enteran mucho más tarde de lo que si necesitan saber.

• Reprocesos : un ejemplo muy común de reproceso es los problemas con la INTEGRACION, ya que estos aparecen mucho más tarde ya que la actividad de pruebas de integración solo se hacen casi al final del ciclo de vida del desarrollo. Porqué entonces no hacerlas un poco antes para ir encontrando cuanto antes cualquier error de integración y evitar así reproceso ?

• Tiempos de espera en la gestión de ambientes: Cuando los desarrolladores y tester tienen que esperar a que el personal de infraestructura les proporcione los ambientes de desarrollo o que el personal de pruebas tenga que esperar a que los datos para pruebas sean actualizados ya que algunos de estos ambientes son compartidos.

• Disponibilidad de ambientes de testing : Otro caso de cuello de botella es cuando se tienen problemas con las pruebas de integración debido a que los diferentes servicios y aplicaciones requeridos no están disponibles cuando se necesitan.

Muchas tareas de las anteriores no solo pueden, sino que deben ser automatizadas.

Finalmente, hay varias características para el uso de DevOps, como son Entrega Continua (Continuos Delivery), acompañamiento de la infraestructura (infrastructure escort), Plan de Continuidad del Negocio (Continuous Business Planning), Desarrollo colaborativo (Collaborative Software Development). No importa cual utilizar, lo importante es tratar de determinar cuál le produce un mejor ROI (Return of Investment) de tal manera que incremente la colaboración y eficiencia del proceso de desarrollo de software, de tal forma que los desarrolladores se concentren en su trabajo y en lo que es importante para la generación de valor al negocio.

Juan Carlos  A. Vitta J.
Director Ejecutivo alltic.
Especialista en Sistemas Gerenciales  de Ingeniería
co.linkedin.com/in/jcvitta