¡Hemos regresado con nuestra saga DevOps! #excentiaDevOps vuelve un mes después tras el primer artículo, en el que se sentaron las bases y definimos qué es DevOps. Hoy, nos metemos de lleno en la terminología propia de esta filosofía. Todas las corrientes tienen su argot y lenguajes y… ¡DevOps no iba a ser menos! Así que si ya dominas el élfico, parsel, dothraki y klingon, es hora de ponerse con la integración continua, la automatización, el despliegue continuo… Lo que todavía no tenemos es un nombre para toda esta terminología… ¿Nos ayudas a buscarle uno? Propón tus ideas usando el hashtag #excentiaDevOps y, ¡no olvides mencionar a excentia! A nosotros se nos han ocurrido varios… “contdev”, “infinite”… No somos muy originales, hay cosas que se nos dan mejor…
Antes de empezar nuestro diccionario “contdev” – español, es clave recordar qué es DevOps. Recuerda que usar determinadas herramientas, hacer un curso, o tener en tu título de trabajo la palabra DevOps no significa que efectivamente “sigas DevOps”. El concepto es más profundo – tratamos de cambiar la cultura de trabajo de toda una generación. DevOps es una filosofía y el primer paso para adoptarla es estar dispuesto a romper esquemas mentales y ser flexible ante las nuevas tecnologías y cambios en la gestión de procesos.
Igual que no afirmarías que sabes de fútbol sino sabes que es un fuera de juego, un linier, el VAR, etc., tampoco puedes saber qué es DevOps si no sabes que significan todas estas palabras:
La automatización es quizás el elemento más importante en la filosofía DevOps. Sin automatización, DevOps no tendría sentido. Con la llegada de nuevas tecnologías y herramientas que permiten la automatización del despliegue, del testing, de la comunicación…, se ha conseguido no solo que el software llegue más rápido, es decir una reducción considerable del time-to-market, sino un cambio en el método de trabajo de los desarrolladores de software. La automatización ha de ser entendida como un habilitador que permite a los equipos trabajar de forma continua sin paralizar la producción cuando el despliegue tenga que ser llevado a cabo. Introduce agilidad en el desarrollo de software y además permite detectar errores más fácilmente, ya que conocemos dónde se encuentra cada versión en cualquier momento.
Según Amazon Web Services, la integración continua es una práctica de desarrollo de software mediante la cual los desarrolladores combinan los cambios en el código en un repositorio central de forma periódica, tras lo cual se ejecutan versiones y pruebas automáticas. La integración continua se refiere en su mayoría a la fase de creación o integración del proceso de publicación de software y conlleva un componente de automatización y un componente cultural – parece que la integración continua haya sido diseñada para la filosofía DevOps, pero no nos engañemos, aunque imprescindible en el lenguaje DevOps, la integración continua no es su sinónimo. DevOps conlleva más cosas, es un conjunto infinito de factores que se repiten en el que la integración continua forma parte de su ser. Los objetivos clave de la integración continua consisten en encontrar y arreglar errores con mayor rapidez, mejorar la calidad del software y reducir el tiempo que se tarda en validar y publicar nuevas actualizaciones de software.
Uno de los errores más frecuentes y que la cultura DevOps trata de aclarar, es la diferencia entre el despliegue y la entrega continua. A priori parecen lo mismo, pero os podéis imaginar que eso no es así.
La entrega continua implica una serie de prácticas diseñadas para asegurar que el código puede ser rápida y seguramente desplegado. Mediante testing automatizado (cómo no), la entrega continua se asegura de que la aplicación y el servicio funcionan como se espera.
Por tanto, el despliegue continuo es el paso siguiente a la entrega continua. Una vez se ha asegurado la entrega es momento de desplegarla.
Así pues, mientras que el despliegue continuo no es quizás lo mejor para todas las empresas, especialmente para aquellas que deban cumplir con requisitos legales, la entrega continua es un requisito indispensable en la cultura DevOps.
En esta práctica se han centrado muchos esfuerzos por parte de los seguidores de DevOps. Muchos lo consideran el eje central del movimiento y el resultado del primer esfuerzo por lograr mayor cooperación entre departamentos. Se trata de mantener el control sobre lo que realmente importa en la producción y operación del producto. Monitorizar es necesario para conseguir una implantación exitosa de la filosofía DevOps. De hecho, precisamente DevOps trata de romper la falta de comunicación y feedback una vez se han puesto en producción los cambios por parte del equipo de operaciones. La monitorización ha de ser transversal y debe llegar al departamento de desarrollo y no quedarse en el de operaciones. Es el clásico silo informativo que complica la calidad del producto final y que DevOps trata de eliminar.
En relación con el punto anterior, de nada serviría la monitorización si no es comunicada adecuadamente. Así es como surge ChatOps. Comunicación continua y constante entre los equipos, no que un mismo equipo lo haga todo, no a falta de información y sí a documentar y compartir. De ChatOps hablaremos en profundidad en próximas entregas de #excentiaDevOps pero como en cualquier relación… ¡la comunicación es clave!
El objetivo final, la guinda del pastel, el sueño DevOps. La calidad de software se ve extremadamente favorecida si aplicamos una filosofía DevOps en la elaboración e implantación del código. Es el mayor argumento y beneficio: incremento de la calidad de tu producto más una mejorada velocidad de llegada al mercado hacen que DevOps haya tenido tantísimo éxito y que aún le quede mucha guerra por dar.
Muchos son los conceptos que faltan por definir, y mucho más lo que nos queda por contarte acerca del movimiento DevOps. La saga #excentiaDevOps continuará en 2018 y estaremos encantados de recibir propuestas y contaros todo aquello que os resulte interesante. Así que no lo dudes y ¡envíanos tus ideas!.