Mi experiencia con DevOps

Cuando se desarrolla software, el tiempo entre que una funcionalidad es concebida hasta que esta llega a entregar valor real a un usuario, es bastante superior al tiempo que demora esta funcionalidad en ser construida, esto se debe principalmente a la poca integración que existe entre los equipos de desarrollo (quienes crean el software) y Operaciones (Quienes despliegan el software y lo mantienen funcionando).

Con la intención de reducir este tiempo nace el movimiento de DevOps que propone mejorar esta integración, promoviendo una serie de prácticas para lograr este objetivo. Como DevOps es un movimiento no hay una lista formal de cuales son las prácticas que se promueven, listaré y explicare brevemente algunas de esas prácticas aquí, simplemente para hacernos una idea de que se trata esto:

Integración continua: Consiste en automatizar el proceso de integración del código, usando un software que realiza tareas como: revisión de normas, compilación y tests unitarios.

Entrega continua: A la integración continua se le agregan los pasos de ejecutar pruebas de aceptación y generar el release final.

Despliegue Continuo: Incluye las anteriores y se agrega la fase de paso a producción automático.

Kanban: Método para gestionar el trabajo en el que se crean tareas, que van pasando por etapas hasta que están terminadas y entregan valor al cliente, permite limitar el trabajo en curso y tener una visión completa del avance del proyecto.

Testing Automatizado (Pruebas de Aceptación): Se refiere específicamente a pruebas de aceptación (que se hacen sobre el sistema funcionando), que pueden ser automatizadas con el fin de acelerar el proceso de entrega.

Testing Automatizado (Pruebas Unitarias): Se refiere a las pruebas que se hacen para probar que el código se comporte como se espera, sin probar todo el sistema solo cada parte de él.

Revisión de pares: Práctica que indica que el código debe ser revisado por otros desarrolladores del mismo equipo.

Mejora continua (Katas de mejora, retrospectiva): Prácticas que establecen una serie de pasos que indican cómo se debe abordar la mejora continua.

Además de estas prácticas también se dice que DevOps no es solo una serie de prácticas sino que también es una cultura del equipo la cual debe promover: enfocarse en el valor al negocio, enfatizar la confianza entre los miembros equipo, la innovación constante, la comunicación, la responsabilidad compartida y otros aspectos absolutamente deseables en cualquier cultura de equipo

Mi experiencia

DevOps al igual que muchas “nuevas ideas” luego de que surgen y tienen un impacto positivo, se venden muy bien y las ideas originales quedan relegadas entre una abrumadora dosis de publicidad que en general te indica que si adoptas estas ideas tu empresa crecerá y que si no las adoptas fracasarás. Con esto en mente quiero dar una visión desde mi experiencia, que transcurre en un contexto específico y que le puede ayudar a alguien que esté en un contexto parecido.

Contexto: He trabajado en 2 empresas de desarrollo de software y ambas se han implementado prácticas de DevOps con la idea de mejorar el proceso productivo, El ser una empresa de desarrollo hace a veces imposible implementar todas las prácticas, por ejemplo el Despliegue Continuo (instalar en producción con un proceso automático), no se puede hacer ya que muchas veces el cliente es dueño de dicho proceso de instalación. Por otro lado también suceden algunas cosas buenas, en general en una empresa de desarrollo de software todo el que trabaja está familiarizado con metodologías de desarrollo ( principalmente desarrollo ágil) y la capacidad técnica de los equipos suele ser mejor, y si la empresa no es tan grande la comunicación entre las áreas de desarrollo y operaciones es bastante fluida.

Cultura: En relación a la cultura, creo que es muy difícil en una empresa que está estructurada jerárquicamente implementar ideas como las de la responsabilidad compartida, o la alta confianza. Y esta dificultad hace que el objetivo final muchas veces no sea alcanzado ya que el tiempo que se ahorra es consumido en las etapas de revisión manual o en cuellos de botella que se producen porque solo algunos elegidos tienen permisos para modificar el flujo de automatización. Por otro lado el fomentar la comunicación, la experimentación, y la automatización, es fácil ya que a mi parecer esto es lo que naturalmente quieren las personas que trabajan en una empresa de desarrollo, en este sentido las reuniones diarias y las de retrospectiva ayudan a incentivar estas ideas.

Integración continua, Entrega continua , Despliegue Continuo: Estas prácticas tienen un impacto muy positivo donde las he visto implementadas, sin embargo también tienen un costo, que es la mantención de la infraestructura de hardware y software que soporta estos procesos automatizados, ysi no se asignan los recursos suficientes para mantener esta infraestructura, se puede perder mucho tiempo en problemas técnicos, lo que me ha tocado ver tiene que ver con problemas de performance de la maquinas (lentitud en la instalación), problemas en la plataforma de contenedores (cuelgues de docker), problemas de accesos entre máquinas y problemas con los scripts de automatización. Considerando esto, creo que es importante entender que para que el flujo automatizado funcione bien no basta con instalar un servidor de integración continua, y hacer un script de automatización para cada proyecto, sino que además se debe mantener esta plataforma o contratar un servicio que la mantenga.

Kanban: Esto que se implementa más por el desarrollo ágil que por devOps, sirve bastante para organizar las tareas, y lo que he visto es que la técnica en sí misma no limita el trabajo en curso, como se pretende pero da visibilidad de este y permite tomar las acciones correctivas necesarias.

Testing Automatizado: Construir pruebas lleva tiempo, tiempo que se agrega a los proyectos, creo que las promesas que hablan de reducción de tiempo de desarrollo construyendo pruebas automatizadas simplemente son falsas, creo que el beneficio se ve a largo plazo en el proceso de mantención.

Revisión de pares: Creo que es una excelente práctica, las personas al revisar, además de intentar encontrar problemas, entienden el código del otro, lo que hace que sea más fácil el intercambio de funciones, además me ha tocado ver que es fácil que en estas revisiones se descubran errores relacionados con prácticas de programación, lo que hace que el equipo en general vaya adoptando mejores prácticas.

Mejora continua: En general he visto siempre un impacto positivo en el ánimo del equipo al realizar reuniones al finalizar los proyectos para intentar mejorar, por otro lado también he visto que aunque de cada proyecto se aprende algo no siempre es fácil implementar las acciones de mejora, se necesita voluntad de todo el equipo para tomar estas acciones, si no se tiene esta voluntad, la mejora continua se convierte en un montón de buenas intenciones que nunca se implementan.

Se puede buscar mucho material de DevOps en internet hay libros, y grandes empresas que promueven sus beneficios (que generalmente venden un software asociado), en la práctica me ha tocado ver que los beneficios existen, sin embargo una empresa no se transforma de un dia para otro y muchas veces el proceso de cambio hace que simplemente no hayan beneficios en un principio.

Esta es mi visión que se basa en mis conocimientos, y mi experiencia en el tema, no pretende ser “la verdad” solo la comparto para que aquellos que no han adoptado las prácticas tengan una idea de la experiencia de otro y aquellos que sí las han adoptado puedan empatizar o estar en desacuerdo con esta experiencia.