En este artículo, aprenderemos sobre DevOps y cómo se diferencia de la metodología Agile. También cubriremos algunas herramientas populares de DevOps y sus roles en el ciclo de vida de DevOps.
Aprenderás
- ¿Qué son Docker, Kubernetes y Azure DevOps?
- ¿Qué es DevOps y por qué lo necesitamos?
- ¿En qué se diferencia DevOps de Agile?
- ¿Cuáles son algunas herramientas importantes de DevOps?
- ¿Cómo ayuda Docker a DevOps?
- ¿Cómo ayuda Kubernetes a DevOps?
- ¿Cómo ayuda Azure DevOps a DevOps?
- ¿Qué es la Integración Continua y la Entrega Continua (CI/CD)?
- ¿Qué es la Infraestructura como Código?
- ¿Cómo ayudan Terraform y Ansible a DevOps?
Docker
Docker es una herramienta de software de código abierto que se utiliza para construir, probar y desplegar aplicaciones en contenedores. ¿Qué es la Contenerización, por cierto? La Contenerización es el concepto de agrupar todas las bibliotecas y archivos junto con el código de la aplicación en una única unidad llamada “Contenedor” para que pueda ejecutarse en cualquier infraestructura.
Kubernetes
Kubernetes es un sistema de orquestación de contenedores que gestiona aplicaciones y servicios contenerizados. Se encarga de las tareas realizadas en el entorno contenerizado, como escalado, implementación, equilibrio de carga, etc. Kubernetes es portátil, eficiente y rentable, y ofrece características como integraciones de sistemas, soporte basado en API, etc.
Azure DevOps
Azure DevOps es un producto de Microsoft que proporciona una amplia gama de herramientas y funciones que hacen que el proceso de desarrollo y implementación de software sea más rápido y organizado. Ofrece un conjunto de procesos que permite a los desarrolladores de software, gerentes de proyecto y otros colaboradores trabajar juntos para desarrollar software. Puede agregarse a los editores o IDE existentes para permitir que el equipo trabaje de manera efectiva en proyectos de todos los tamaños.
Comencemos con un caso de uso simple.
Cursos gratuitos – Aprende en 10 pasos
¿Qué es DevOps?
Como ocurre con la mayoría de los términos de moda en el desarrollo de software, no hay una definición aceptada para DevOps.
Las definiciones varían desde simples, como la que se muestra a continuación, hasta complejas, que pueden abarcar toda una página de un libro.
DevOps es la combinación de filosofías culturales, prácticas y herramientas que incrementa la capacidad de una organización para entregar aplicaciones y servicios a alta velocidad — Amazon Web Services (AWS)
En lugar de intentar definir DevOps, entendamos cómo evolucionó el desarrollo de software hacia DevOps.
Modelo en Cascada
El Modelo en Cascada es una metodología que sigue un enfoque estructurado. Consta de seis fases: Requerimientos, Diseño, Implementación, Pruebas, Despliegue y Mantenimiento. Cada fase se basa en la finalización de la anterior. Avanza a través de estas etapas sin volver a procesos anteriores, lo que lo convierte en un proceso lineal.
Las primeras décadas del desarrollo de software se centraron en el modelo en cascada, y abordaba el desarrollo de software de la misma manera que abordarías la construcción de un proyecto inmobiliario, por ejemplo, construir un puente.
Desarrollarías el software en múltiples fases que pueden durar desde unas semanas hasta unos meses.
En la mayoría de los proyectos en cascada, pasarían meses antes de que la empresa vea una versión funcional de una aplicación.
Elementos Clave para Construir un Gran Software
Durante décadas trabajando en el modelo en cascada, entendemos algunos elementos clave en el desarrollo de software de calidad:
- Comunicación
- Feedback
- Automatización
Importancia de la Comunicación
La comunicación entre las personas es esencial para el éxito de un proyecto de software.
En el modelo en cascada, intentamos mejorar la comunicación preparando documentos de 1000 páginas sobre Requisitos, Diseño, Arquitectura e Implementación.
Pero, con el tiempo, descubrimos que:
- La mejor manera de mejorar la comunicación dentro de un equipo es reunirlos. Y tener una variedad de habilidades en el mismo equipo.
- Los equipos multifuncionales —con una amplia gama de habilidades— funcionan muy bien.
Importancia de la Retroalimentación Temprana
Obtener retroalimentación rápidamente es importante. Construir un buen software se trata de obtener retroalimentación rápida.
- ¿Estamos construyendo una aplicación que cumpla con las expectativas del negocio?
- ¿Tendrá tu aplicación problemas si se despliega en producción?
No quieres saberlo después de unos meses. Quieres descubrirlo lo antes posible porque cuanto antes encontremos un problema, más fácil será solucionarlo.
Descubrimos que los mejores equipos de software están estructurados para permitir una retroalimentación rápida.
Importancia de la Automatización
La automatización es fundamental. El desarrollo de software implica una amplia gama de actividades. Hacer las cosas manualmente es lento y propenso a errores. Entendemos que es esencial buscar siempre oportunidades para introducir la automatización.
Habiendo entendido los elementos clave para desarrollar un gran software, veamos cómo evolucionamos hacia Agile y DevOps.
Evolución hacia Agile
Agile es un enfoque que enfatiza el progreso incremental, la retroalimentación frecuente y la capacidad de responder a los requisitos cambiantes a lo largo del ciclo de desarrollo. Agile promueve equipos multifuncionales que trabajan en ciclos cortos de desarrollo, lo cual fomenta la mejora continua y entrega valor a los usuarios finales rápidamente. Fue el primer paso en la evolución hacia la implementación de nuestros aprendizajes con una comunicación mejorada entre equipos, obteniendo retroalimentación e introduciendo automatización.
Agile unió a los equipos de negocios y desarrollo en un solo equipo, que trabaja para construir un gran software en pequeñas iteraciones llamadas Sprints.
En lugar de pasar semanas o meses en cada fase de desarrollo, Agile se enfoca en llevar pequeños requisitos llamados historias de usuario a través del ciclo de desarrollo en unos pocos días, a veces incluso en el mismo día.
¿Cómo Mejoró Agile la Comunicación entre Equipos?
Agile unió a los equipos de negocios y desarrollo.
- Los negocios son responsables de definir qué construir. ¿Cuáles son los requisitos?
- El desarrollo es responsable de construir un producto que cumpla con los requisitos. El desarrollo incluye a todos los involucrados en el diseño, codificación, pruebas y empaquetado de su software.
En Agile, un representante del negocio, llamado Product Owner, está siempre presente con el equipo, y el equipo entiende claramente los objetivos del negocio.
Cuando el equipo de desarrollo no entiende los requisitos y va por el camino equivocado, el Product Owner les ayuda a corregir el rumbo y mantenerse en el camino correcto.
Resultado: El producto final que construye el equipo es algo que el negocio desea.
Otro factor importante es que los equipos ágiles tienen habilidades multifuncionales: habilidades de codificación (frontend, API y bases de datos), habilidades de prueba y habilidades empresariales. Esto mejora la comunicación entre las personas que tienen que trabajar juntas para construir un gran software.
Ágil y Automatización
¿En qué áreas de automatización se centran los equipos ágiles?
Los productos de software pueden tener una variedad de defectos:
- Los defectos funcionales significan que el producto no funciona como se espera.
- Los defectos técnicos dificultan el mantenimiento del software. Por ejemplo, problemas de calidad de código.
En general, los equipos ágiles se centran en utilizar la automatización para encontrar defectos técnicos y funcionales lo antes posible.
Los equipos ágiles también se centran extensamente en la calidad del código. Se utilizan herramientas como SONAR para evaluar la calidad del código de las aplicaciones.
¿Es suficiente si tienes grandes pruebas de automatización y excelentes controles de calidad de código? La clave es ejecutar estos procesos con frecuencia. Los equipos ágiles enfatizan la Integración Continua, donde los commits al control de versiones desencadenan una serie de acciones. Esto incluye la ejecución de Pruebas Unitarias, Pruebas de Automatización y Controles de Calidad de Código, todos integrados de manera fluida en un Pipeline de Integración Continua. Jenkins, una herramienta CI/CD ampliamente adoptada durante la era ágil temprana, desempeñó un papel crucial en la orquestación de estos procesos automatizados.
¿Cómo Promovió Ágil el Feedback Inmediato?
El factor más importante es que un negocio no necesita esperar meses para ver el producto final. Al final de cada sprint, el producto se presenta a todos los interesados, incluidos los equipos de arquitectura y de negocio. Se toma en cuenta todo el feedback al priorizar historias de usuario para el siguiente sprint. Resultado: el producto final que construye el equipo es algo que el negocio desea.
Otro factor importante que permite el feedback inmediato es la integración continua. Digamos que hago un commit de código en el control de versiones. En 30 minutos, recibo feedback si mi código causa un fallo en una prueba unitaria o en una prueba de integración. Obtendré feedback si mi código no cumple con los estándares de calidad de código o si no tiene suficiente cobertura de código en las pruebas unitarias.
¿Fue exitoso Ágil? Sí. Sin duda. Al centrarse en mejorar la comunicación entre los equipos de negocio y de desarrollo, y en encontrar una variedad de defectos tempranamente, Ágil llevó el desarrollo de software al siguiente nivel.
Tuve una experiencia maravillosa trabajando con algunos equipos increíbles utilizando Agile. La ingeniería de software, que para mí representa todos los esfuerzos en la construcción de software desde los requisitos hasta llevar aplicaciones a producción por primera vez, fue tan placentera como programar.
¿Pero se detiene la evolución? No.
Emergieron nuevos desafíos.
Evolución de las arquitecturas de microservicios.
Comenzamos a movernos hacia una arquitectura de microservicios, y empezamos a construir varias pequeñas APIs en lugar de construir grandes aplicaciones monolíticas.
¿Cuál era el nuevo desafío?
Las operaciones se volvieron más importantes. En lugar de hacer un lanzamiento monolítico al mes, se están haciendo cientos de pequeños lanzamientos de microservicios cada semana. Depurar problemas entre microservicios y obtener visibilidad sobre lo que está sucediendo con los microservicios se volvió importante.
Era hora de una nueva palabra de moda en el desarrollo de software. DevOps.
Emergencia de DevOps.
¿Cuál fue el enfoque de DevOps?
El enfoque de DevOps era mejorar la comunicación entre los equipos de desarrollo y de operaciones.
- ¿Cómo hacemos que los despliegues sean más fáciles?
- ¿Cómo hacemos que el trabajo que realiza el equipo de operaciones sea más visible para el equipo de desarrollo?
¿Cómo mejoró DevOps la comunicación entre los equipos?
DevOps acercó a los equipos de operaciones a los equipos de desarrollo.
- En empresas más maduras, los equipos de desarrollo y operaciones trabajaban como un solo equipo. Comenzaron a compartir objetivos comunes y ambos equipos empezaron a comprender los desafíos que enfrentaba el otro equipo.
- En las empresas, en las primeras etapas de la evolución de DevOps, un representante del equipo de operaciones puede participar en los sprints, reuniones diarias y retrospectivas.
¿En qué áreas de automatización se enfocan los equipos de DevOps?
Además de las áreas de enfoque de Agile, como Integración Continua y automatización de pruebas, los equipos de DevOps se centraban en ayudar a automatizar varias actividades del equipo de operaciones, como aprovisionamiento de servidores, configuración de software en servidores, despliegue de aplicaciones y monitoreo de entornos de producción. Algunos términos clave son despliegue continuo, entrega continua e infraestructura como código.
El despliegue continuo se trata de desplegar continuamente una nueva versión de software en entornos de prueba. En organizaciones aún más maduras como Google y Facebook, la entrega continua ayuda a desplegar continuamente software en producción, tal vez cientos de despliegues de producción por día.
La infraestructura como código consiste en tratar tu infraestructura de la misma forma que tratas tu código de aplicación. Creas tu infraestructura, servidores, balanceadores de carga y base de datos, de manera automatizada utilizando configuración. Deberías controlar la versión de tu infraestructura para poder rastrear los cambios en la infraestructura a lo largo del tiempo.
¿Cómo promovió DevOps la retroalimentación inmediata?
DevOps reúne a los equipos de operaciones y desarrollo. Al ser parte del mismo equipo, todo el equipo comprende los desafíos asociados con las operaciones y el desarrollo.
- Cualquier problema operativo recibe una rápida atención de los desarrolladores.
- Cualquier desafío al llevar el software en vivo recibe la atención temprana del equipo de operaciones.
DevOps fomenta la integración continua, la entrega continua y la infraestructura como código.
- Gracias a la entrega continua, si realizo un cambio de código o de configuración que pueda romper una prueba o un entorno de puesta en escena, lo sabría en unas pocas horas.
- Gracias a la Infraestructura como Código, los desarrolladores pueden autoaprovisionar entornos, implementar código y encontrar problemas por sí mismos sin ayuda del equipo de operaciones.
Veo Agile y DevOps como dos fases que nos ayudan a mejorar la forma en que construimos un gran software. No compiten entre sí, pero juntos nos ayudan a construir productos de software increíbles.
En mi opinión, el objetivo de Agile y DevOps juntos es hacer cosas que:
- Promuevan la comunicación y la retroalimentación entre los equipos de negocio, desarrollo y operaciones
- Alivien los puntos de dolor con la automatización.
Una Historia de DevOps
Aquí tienes un ejemplo de historia:
- Tú eres el desarrollador estrella en un equipo, y necesitas hacer una corrección rápida.
- Accedes a un repositorio de GitHub.
- Clonas rápidamente el proyecto.
- Creas rápidamente tu entorno local.
- Realizas un cambio. Lo pruebas. Actualizas las pruebas unitarias y de automatización.
- Lo confirmas.
- Recibes un correo electrónico diciendo que se implementó en QA.
- Se ejecutan automáticamente algunas pruebas de integración.
- Tu equipo de QA recibe un correo electrónico solicitando aprobación. Realizan una prueba manual y aprueban.
- Tu código está en producción en pocos minutos.
- Puede que pienses que este es un escenario ideal. Pero, ¿sabías que esto es lo que está sucediendo en empresas innovadoras como Netflix, Amazon y Google día tras día?
Esta es la historia de DevOps.
DevOps = Desarrollo + Operaciones
DevOps es una evolución natural del desarrollo de software. DevOps NO ES SOLO una herramienta, un marco de trabajo o simplemente automatización. Es una combinación de todos estos elementos.
DevOps se centra en las personas, los procesos y los productos. La parte de personas en DevOps trata sobre la cultura y la creación de una mentalidad excelente: una cultura que promueve la comunicación abierta y valora la retroalimentación rápida, una cultura que valora el software de alta calidad.
Agile ayudó a cerrar la brecha entre los equipos de negocios y de desarrollo. Los equipos de desarrollo entendieron las prioridades del negocio y trabajaron con el negocio para entregar las historias que proporcionaban más valor primero; sin embargo, los equipos de desarrollo y operaciones no estaban alineados.
Tenían objetivos diferentes.
- El objetivo del equipo de desarrollo es llevar tantas nuevas funciones a producción como sea posible.
- El objetivo del equipo de operaciones era mantener el entorno de producción lo más estable posible.
Como puedes ver, si llevar las cosas a producción es difícil, el desarrollo y las operaciones no están alineados.
DevOps tiene como objetivo alinear los equipos de desarrollo y operaciones con objetivos compartidos.
El equipo de desarrollo trabaja con el equipo de operaciones para entender y resolver los desafíos operativos. El equipo de operaciones forma parte del equipo scrum y comprende las características en desarrollo.
¿Cómo podemos hacer esto posible? ¡Rompe la barrera entre desarrollo y operaciones!
Uniendo Desarrollo y Operaciones
Opción 1
En empresas de DevOps maduras, desarrollo y operaciones trabajan como parte del mismo equipo scrum y comparten las responsabilidades del otro.
Opción 2
Sin embargo, si te encuentras en las primeras etapas de la evolución de DevOps, ¿cómo puedes lograr que desarrollo y operaciones tengan objetivos comunes y trabajen juntos?
Aquí hay algunas cosas que puedes hacer:
- Haz que el equipo de desarrollo comparta algunas de las responsabilidades del equipo de operaciones. Por ejemplo, el equipo de desarrollo puede asumir la responsabilidad de los nuevos lanzamientos durante la primera semana después del despliegue en producción. Esto ayuda al equipo de desarrollo a entender los desafíos que enfrenta operaciones al llevar nuevos lanzamientos a la práctica y les ayuda a unirse y encontrar mejores soluciones.
- Otra cosa que puedes hacer es involucrar a un representante del equipo de operaciones en las actividades scrum. Involúcralos en las reuniones diarias y las retrospectivas.
- Lo siguiente que puedes hacer es hacer más visibles los desafíos que enfrenta el equipo de Operaciones para el equipo de Desarrollo. Cuando enfrentes cualquier desafío en operaciones, haz que los equipos de desarrollo sean parte de los equipos que trabajan en soluciones.
De cualquier manera que lo enfoques, encuentra formas de romper la barrera y reunir al equipo de desarrollo y al equipo de operaciones.
Otra opción interesante surge gracias a la automatización. Al utilizar Infraestructura como Código y habilitar la autoaprovisionamiento para los desarrolladores, puedes crear un lenguaje común que los equipos de operaciones y desarrollo comprendan: el código.
Un Caso de Uso de DevOps
Considera la imagen a continuación:
Esta imagen muestra dos flujos de trabajo simples
- Infraestructura como Código utilizando Terraform y Azure DevOps para aprovisionar clústeres de Kubernetes.
- Despliegue Continuo de microservicios utilizando Azure DevOps para construir y desplegar imágenes de Docker para microservicios en clústeres de Kubernetes.
¿Suena complicado?
Desglosemos esto y tratemos de entenderlo.
Comencemos con el #2 — Despliegue Continuo primero.
#2: Despliegue Continuo de DevOps con Azure DevOps y Jenkins
¿Cuál es el uso de tener grandes pruebas y controles de calidad de código si no los ejecutas con frecuencia?
¿Cuál es el uso de la automatización de despliegue si no despliegas software con suficiente frecuencia?
Tan pronto como un desarrollador comitea código en el sistema de control de versiones, se ejecutan los siguientes pasos:
- Pruebas Unitarias
- Controles de Calidad de Código
- Pruebas de Integración
- Empaquetado de aplicaciones — Construcción de una versión desplegable de la aplicación. Herramientas — Maven, Gradle, Docker
- Despliegue de aplicaciones — Poner en vivo nuevas aplicaciones o nuevas versiones de la aplicación
- Un correo electrónico al equipo de pruebas para probar la aplicación
Tan pronto como haya aprobación del equipo de pruebas, la aplicación se despliega inmediatamente al siguiente entorno.
Esto se llama despliegue continuo. Si despliegas continuamente hasta producción, se llama entrega continua.
Las herramientas de CI/CD más populares son Azure DevOps y Jenkins.
#1: Infraestructura de DevOps como Código con Terraform
Anteriormente, solíamos crear entornos y desplegar aplicaciones manualmente.
Cada vez que creas un servidor, esto debe hacerse manualmente.
- La versión del software necesita ser actualizada
- Los parches de seguridad deben ser instalados manualmente
Lo haces manualmente, y los siguientes son los resultados:
- Alta probabilidad de errores
- Los entornos de replicación son difíciles
Infraestructura como Código
Infraestructura como Código — tratar la infraestructura de la misma manera que el código de la aplicación.
Aquí hay algunas cosas importantes para entender con Infraestructura como Código:
- El equipo de infraestructura se enfoca en trabajo de valor añadido (en lugar de trabajo rutinario)
- Menos errores y rápida recuperación de fallos
- Los servidores son consistentes (evita la deriva de configuración)
Las herramientas de IaC más populares son Ansible y Terraform.
Normalmente estos son los pasos en IaC:
- Provisión de Servidores (habilitada por la Nube) desde una plantilla
- Instalar software
- Configurar software
Provisionamiento de Servidores
Normalmente, se utilizan herramientas de aprovisionamiento para aprovisionar servidores y preparar el nuevo servidor con capacidades de red. Las herramientas de aprovisionamiento más populares son Cloud Formation y Terraform.
Usando Terraform, puedes aprovisionar servidores y el resto de tu infraestructura, como balanceadores de carga, bases de datos, configuración de red, etc. Puedes crear servidores utilizando imágenes pre-creadas creadas con herramientas como Packer y AMI (Amazon Machine Image).
Gestión de Configuración
Las herramientas de gestión de configuración se utilizan para:
- Instalar software
- Configurar software
Las herramientas populares de gestión de configuración son Chef, Puppet, Ansible y SaltStack. Estas están diseñadas para instalar y gestionar software en servidores existentes.
Rol de Docker y Kubernetes en DevOps
En el mundo de microservicios, algunos microservicios pueden estar construidos con Java, otros con Python y otros con JavaScript.
Diferentes microservicios tendrán diferentes formas de construir aplicaciones e implementarlas en servidores. Esto dificulta el trabajo del equipo de operaciones. ¿Cómo podemos tener una forma similar de implementar múltiples tipos de aplicaciones? Entren en juego los contenedores y Docker.
Usando Docker, puedes construir imágenes de microservicios, independientemente de su lenguaje. Puedes ejecutar estas imágenes de la misma manera en cualquier infraestructura. Esto simplifica las operaciones.
Kubernetes mejora esto al ayudar a orquestar diferentes tipos de contenedores y desplegarlos en clústeres.
Kubernetes también proporciona:
- Descubrimiento de servicios
- Balanceo de carga
- Configuración centralizada
Docker y Kubernetes hacen que DevOps sea fácil.
Métricas importantes de DevOps
A continuación, algunas métricas importantes de DevOps que puedes seguir y mejorar con el tiempo.
- Frecuencia de despliegue — ¿Con qué frecuencia se despliegan aplicaciones en producción?
- Tiempo de llegada al mercado — ¿Cuánto tiempo necesitas para llevar una característica desde la codificación a producción?
- Tasa de fallos de nuevas versiones — ¿Cuántas de tus versiones fallan?
- Tiempo de liderazgo para correcciones — ¿Cuánto tiempo necesitas para hacer una corrección en producción y lanzarla a producción?
- Tiempo medio de recuperación — ¿Cuánto tiempo tardas en recuperar tu entorno de producción de un problema importante?
Mejores prácticas de DevOps
Gestión de proyectos ágil
La gestión de proyectos ágil es un enfoque iterativo para desarrollar aplicaciones de software. A través de esta práctica, los equipos pueden mejorar la velocidad de desarrollo y responder bien a las diversas necesidades de los clientes. La metodología ágil es diferente del método tradicional de Cascada, en el cual existían largos ciclos de lanzamiento. Ágil utiliza los marcos Scrum y Kanban para entregar el software según las necesidades del cliente.
Utilizando el conjunto adecuado de herramientas
Los desarrolladores de software y los administradores de sistemas necesitan seleccionar y usar el conjunto adecuado de herramientas de DevOps en cada etapa del ciclo de vida de DevOps para construir aplicaciones de alto valor.
A continuación se presentan algunos ejemplos de herramientas que los ingenieros de DevOps, administradores de sistemas y otras partes interesadas pueden utilizar:
- Herramientas como Jira pueden ayudar al equipo a segregar tareas en piezas más pequeñas y manejables, lo que ayuda a aumentar la productividad del equipo.
- Herramientas como Jenkins y Bitbucket pueden ayudarte a automatizar los flujos de código desde la fase de pruebas hasta la implementación.
- Herramientas como Slack, GetFeedback, etc. pueden ayudar a los equipos de DevOps a integrar herramientas de chat con plataformas de encuestas para recopilar y revisar comentarios en tiempo real.
Integración Continua/Entrega Continua
La Integración Continua (CI) y la Entrega Continua (CD) son prácticas modernas de desarrollo de software que ayudan a las organizaciones a enviar software de manera rápida y efectiva. Con CI, los desarrolladores comprometen continuamente el código de la aplicación en un repositorio compartido varias veces. Con CD, el código se entrega a producción rápida y fácilmente. CD también garantiza que la integración se realice sin retrasos ni fallos.
Integración de Seguridad
La seguridad es una parte importante del proceso de desarrollo de software. En el mundo actual, donde los delitos cibernéticos y los incidentes de violación de datos están en aumento, las organizaciones están reconociendo la importancia de integrar la seguridad en sus sistemas. En el pasado, la seguridad generalmente se consideraba en las últimas fases del ciclo de vida del desarrollo de software, pero con la llegada de DevSecOps, la seguridad se está considerando e integrando desde el primer día del desarrollo de la aplicación.
Observabilidad
La observabilidad es importante al desarrollar aplicaciones complejas que utilizan arquitecturas de microservicios y en la nube. La observabilidad ayuda a los equipos de DevOps a entender la compleja estructura de diferentes aplicaciones (microservicios, aplicaciones en la nube, etc.) y ayuda a abordar las necesidades futuras del entorno. La observabilidad de Kubernetes y Splunk son algunas de las mejores plataformas de observabilidad.
Señales de madurez de DevOps
¿Cómo se mide la madurez de tus implementaciones de DevOps?
- El tiempo transcurrido desde el proceso de desarrollo hasta el despliegue debe ser en general satisfactorio
- Determinar la frecuencia de los nuevos despliegues de código
- El Tiempo Medio de Recuperación (MTTR) de un incidente o evento inesperado debe ser lo más bajo posible
- Los despliegues exitosos deben superar a los despliegues fallidos.
- Liberaciones más rápidas y fiables deberían generar un alto Retorno de la Inversión (ROI).
Mejores Prácticas de Transformación DevOps
- El respaldo de la dirección es crítico
- Implica costos iniciales
- Establecer COEs para ayudar a los equipos
- Elegir la aplicación y equipo adecuados
- Comenzar de manera pequeña
- Compartir aprendizajes (boletines informativos, comunicación, COEs)
- Animar a las personas con mentalidad de exploración y automatización
- Reconocer a los equipos de DevOps
Source:
https://dzone.com/articles/devops-tutorial-devops-with-docker-kubernetes-and