¿Qué es DevOps?

Si has llegado hasta aquí es porque seguramente has oído hablar de DevOps y quieres saber más.

Voy a explicarte bien de qué se trata. Para ello haremos un poco de historia y explicaré los problemas que han ido surgiendo en el mundo del desarrollo. Después, resumiremos los objetivos que tienen que cumplirse en los equipos buenos de desarrollo y cómo DevOps nos puede ayudar a lograrlo.

El problema

Al principio, los departamentos de informática de las empresas eran como en la siguiente foto:

Al señor de la foto lo llamaremos Billy, y es el encargado de hacer funcionar el ordenador gigante que tiene detrás. A Billy de vez en cuando, los dueños de la empresa le piden que programe la máquina para que haga algunos cálculos que por aquella época parecían complejos. Y él lo hace. ¿Que funciona todo perfecto? La gloria es para Billy. ¿Que algo no ha ido bien? Billy y sólo Billy se encarga de arreglarlo.

Durante un tiempo esto funcionó. Las empresas cubrían sus necesidades de IT así y no hacía falta nada más.

Pero conforme fue pasando el tiempo, la cosa se fue complicando. Los departamentos de informática pasaron de contar sólo con una o con muy pocas personas a muchas más y de forma progresiva, se fueron creando subdepartamentos. El de desarrollo, el de sistemas, el de testing o de pruebas, etcétera…

Cada departamento se comportaba como una unidad independiente. O debería decir se comporta, porque aún hoy sigue ocurriendo. En un entorno así, los equipos de desarrollo crean las aplicaciones que una vez finalizadas, se ejecutan en una serie de servidores. Esos servidores son mantenidos y supervisados por los equipos de sistemas. En algunos equipos hay personas encargadas de hacer el testing de las aplicaciones, y en otros ni eso.

Parece la forma lógica de funcionar, pero conforme el número de aplicaciones en las empresas fue creciendo, se hicieron evidentes algunos problemas como estos:

• Los equipos trabajan de forma aislada: Para que una aplicación funcione, hace falta como hemos dicho antes, que esté bien desarrollada y que los servidores en los que se ejecuta funcionen bien y estén siempre activos. Parecería lógico pensar que los equipos de desarrollo y de sistemas, por lo tanto, deben trabajar de forma muy fluída. Sin embargo esto muchas veces no es así. A menudo estos equipos piensan que la culpa de que algo no funcione es del otro departamento y no hay buena comunicación entre ellos.
• Las subidas a producción son lentas: Un desarrollador no puede muchas veces subir sus cambios a producción directamente, sino que por seguridad, tiene que comunicar los cambios que quiere hacer al equipo de sistemas, que se encarga de aplicarlos. A eso hay que añadirle que las pruebas de los cambios realizados se hacen manualmente, de manera que acaba habiendo menos subidas a producción, que se traduce en menos valor entregado. Y es que no está de más recordar que el software vale muy poco cuando está en el ordenador del programador, lo que sí tiene valor es tener software funcionando y utilizado por los usuarios finales, y eso pasa sólo cuando lo hemos subido a producción.
• Hay muchos errores: Hemos visto que las pruebas se hacen a mano, por lo tanto por personas. Y las personas cometemos errores. Más tarde o más temprano, pero los cometemos. Y eso cuando se hacen las pruebas, porque a veces por las prisas o por los cambios continuos de requisitos, ni siquiera se hacen.
• No se controla la calidad del software: O funciona o no funciona, y esa es la única métrica que se tiene en cuenta. Si funciona se entiende que todo está bien. Pero lo cierto es que no es así. Podemos tener software funcionando pero que esté a punto de dar muchos problemas, o que sea muy difícil de mantener porque esté lleno de parches.

Si todos esos problemas ya eran importantes, ahora y en el futuro lo serán mucho más. Y es que ahora aunque no lo parezca estamos en la siguiente etapa. No es ya que la cantidad de aplicaciones haya aumentado aún más, que por supuesto que sí. Sino que hablamos de que muchas compañías están sumergidas en procesos de transformación digital. Y eso significa que su negocio depende directamente del software.

Y eso es algo que ocurre incluso con compañías que aparentemente no tienen nada que ver con el mundo de la informática.

Pondré un ejemplo: En los 90, si querías ver una película en casa ibas al vídeoclub, la alquilabas y posteriormente la devolvías. El videoclub podía tener algún programa de gestión para saber si alguien no había devuelto una película, para controlar la facturación, etcétera, pero si ese programa no funcionaba, tú podías alquilar la película igual porque sólo tenías que cogerla de una estantería. Hoy el mayor vídeoclub que se nos viene a la cabeza es Netflix, y si el software que te permite elegir lo que quieres ver, o el que sirve el contenido en streaming deja de funcionar, no podrían prestarte servicio.

Ese es sólo un ejemplo de los muchos que podríamos poner pero en resumen, el software es cada vez más importante, y hay que saber gestionarlo bien.

La solución

Llegados a este punto debemos preguntarnos, ¿cómo podemos resolver todos esos problemas?

Recapitulando un poco tendríamos que conseguir lo siguiente:

• Hacer que los distintos departamentos de IT de la compañía dejen de estar aislados o incluso enemistados, especialmente desarrollo, sistemas y testing
• Hacer que todo el código fuente de las aplicaciones esté siempre disponible en un único repositorio común
• Reducir el número de errores en nuestras aplicaciones
• Conseguir que los distintos entornos sean idénticos para que no haya problemas al hacer los despliegues
• Conseguir que el software construído sea de buena calidad, evitando errores de ejecución, y además haciendo que sea fácil de mantener
• Reducir el tiempo dedicado a probar el software en el largo plazo y evitar que las pruebas se hagan manualmente

Bien, pues podemos conseguir todo eso con DevOps. Por eso vale tanto la pena invertir en DevOps y transformar tus equipos o tu forma de trabajar, si estás solo.

Y ahora contestando directamente a la pregunta:

¿Qué es DevOps? DevOps es una filosofía que pretende eliminar las barreras existentes entre los distintos departamentos facilitando la colaboración entre ellos. Para ello se utilizan una serie de técnicas y herramientas.

Si hablamos de técnicas podríamos mencionar:

• Infrastructure as Code: Antes, para configurar un servidor, normalmente consultabas los pasos a seguir en un documento que había creado alguien o tú mismo, y manualmente ejecutabas los pasos para dejarlo configurado correctamente. Ese proceso es lento y sujeto a errores por lo que no es muy recomendable. Con Infrastructure as Code conseguiremos crear toda nuesra infraestructura mediante scripts que a su vez podrán estar versionados en nuestro sistema de control de versiones preferido.
• Integración continua / Entrega continua: Comentaba más arriba que sólo el software subido a producción está aportando auténtico valor. La Integración continua (CI) y la Entrega continua (CD), nos permiten conseguir esto. Mediante unos workflows automatizados, podremos aumentar el número de subidas a producción entregando valor continuamente.
• Testing: El testing de aplicaciones se podría resumir en: Haz que tus aplicaciones se prueben solas y te informen si hay algún error. Ya puedes imaginar el ahorro de tiempo que eso supone y la tranquilidad que te dará.
• Continuous code inspection: La técnica Continuous code inspection nos permite revisar continuamente la calidad de nuestro software. De este modo, podemos ir corrigiendo los distintos problemas que vayan surgiendo de la inspección mientras vamos desarrollando, en lugar de dejarlo todo para el final y ver que ya es demasiado tarde.

Ahora que hemos visto el conjunto de técnicas que conformarían la filosofía DevOps, podemos comentar cuáles serían las herramientas adecuadas para cada una de ellas.

Hay muchas opciones y combinaciones disponibles pero ahora explicaré, utilizando las herramientas que aprenderías en el curso, qué hace cada una, qué puntos resuelve y con qué técnica se relaciona:

• Git: Con Git podremos tener el código fuente de todo nuestro software versionado y unificado en todo momento. De esa manera, todos los desarrolladores pueden acceder a la última versión del software disponible y compartir su trabajo. Además, gracias a Git podremos definir flujos de trabajo que nos permitirán determinar qué ramas son las que están listas para pasar a producción y cuáles no.
• Docker: Con Docker podremos hacer que nuestro software se ejecute en entornos exactamente iguales en todos los servidores, desde el entorno de producción, hasta el equipo de cada desarrollador. Podremos crear scripts que crearán nuestra infraestructura rápidamente y sin necesidad de hacerlo manualmente. Si estás familiarizado con la orquestación de máquinas virtuales, podríamos decir que es algo muy parecido, pero que consume mucho menos recursos del sistema y que es más eficiente. Con Docker haremos la parte de Infrastructure as Code.
• Gradle: Gradle es una solución de empaquetado de aplicaciones que nos permite automatizar una parte del despliegue de las mismas. Nos ayudará con la integración continua y la entrega continua.
• Junit y katalon: Con JUnit y katalon podremos hacer que las aplicaciones se prueben solas (testing). Cada vez que incorporemos un cambio sabremos si siguen funcionando o si algo se ha roto. Con JUnit crearemos tests unitarios y con Katalon tests de aceptación. Considero que esos dos tipos de tests son los más importantes, aunque no sean los únicos.
• Jenkins: Con Jenkins podremos obtener la última versión de nuestro software, determinar si las pruebas han pasado y lo que debe ocurrir sobre si han pasado o no. Normalmente, si han pasado y si por lo tanto entendemos que nuestro software sigue funcionando, subiremos los cambios a producción mientras que si por el contrario han fallado, podremos decidir tambien qué se hace. Será el componente principal que nos ayudará a tener un entorno de integración continua y entrega continua.
• SonarQube: Con SonarQube podremos revisar la calidad del código, comprobando aspectos tan importantes como la cantidad de código repetido, no utilizado, el código spaghetti o la complejidad ciclomática. Es la pieza que nos permitirá hacer Continuous code inspection.

Gracias por llegar hasta aquí. Espero que esta información te haya sido útil. Si tienes cualquier duda ponte en contacto conmigo y lo comentamos.

¡Hasta pronto!