DevOps es una metodología en la industria del desarrollo de software y de TI. Utilizado como un conjunto de prácticas y herramientas, DevOps integra y automatiza el trabajo de desarrollo de software ( Dev ) y operaciones de TI ( Ops ) como un medio para mejorar y acortar el ciclo de vida de desarrollo de sistemas . [1] DevOps es complementario al desarrollo ágil de software ; Varios aspectos de DevOps surgieron de la forma ágil de trabajar.
La automatización es una parte importante de DevOps. Los programadores y arquitectos de software deberían utilizar " funciones de aptitud " para mantener su software bajo control. [2]
Aparte de ser una combinación multifuncional (y un acrónimo ) de los términos y conceptos de "desarrollo" y "operaciones", los académicos y profesionales no han desarrollado una definición universal para el término "DevOps". [a] [b] [c] [d] Muy a menudo, DevOps se caracteriza por principios clave: propiedad compartida, automatización del flujo de trabajo y retroalimentación rápida. Desde una perspectiva académica, Len Bass , Ingo Weber y Liming Zhu, tres investigadores en ciencias informáticas del CSIRO y el Instituto de Ingeniería de Software , sugirieron definir DevOps como "un conjunto de prácticas destinadas a reducir el tiempo entre la realización de un cambio en un sistema y el cambio se sitúa en la producción normal, garantizando al mismo tiempo una alta calidad". [6] Sin embargo, el término se utiliza en múltiples contextos. En su forma más exitosa, DevOps es una combinación de prácticas específicas, cambio cultural y herramientas. [7]
A finales de los 80 y principios de los 90 comenzaron a aparecer propuestas para combinar metodologías de desarrollo de software con conceptos de implementación y operaciones. [8]
Alrededor de 2007 y 2008, aquellos dentro de las comunidades de desarrollo de software y TI expresaron su preocupación de que la separación entre las dos industrias, donde uno escribía y creaba software completamente separado de aquellos que implementaban y respaldaban el software, estaba creando un nivel fatal de disfunción dentro de la industria. industria. [9]
En 2009, se celebró la primera conferencia denominada DevOps Days en Gante , Bélgica . La conferencia fue fundada por el consultor, director de proyectos y practicante ágil belga Patrick Debois. [10] [11] La conferencia ahora se ha extendido a otros países. [12]
En 2012, Alanna Brown en Puppet Labs publicó por primera vez un informe llamado "Estado de DevOps" . [13] [14]
A partir de 2014, Nicole Forsgren , Gene Kim, Jez Humble y otros publicaron el informe anual sobre el estado de DevOps . Afirmaron que la adopción de DevOps se estaba acelerando. [15] [16] También en 2014, Lisa Crispin y Janet Gregory escribieron el libro More Agile Testing, que contiene un capítulo sobre pruebas y DevOps. [17] [18]
En 2016, las métricas de DORA para el rendimiento (frecuencia de implementación, tiempo de entrega de cambios) y estabilidad (tiempo medio de recuperación, tasa de fallas de cambios) se publicaron en el informe Estado de DevOps. [13] Sin embargo, la metodología y las métricas de la investigación fueron criticadas por los expertos. [19] [20] [21] [22] En respuesta a estas críticas, el informe sobre el estado de DevOps de 2023 [23] publicó cambios que actualizaron la métrica de estabilidad "tiempo medio de recuperación" a "tiempo de recuperación de implementación fallida" reconociendo la confusión. la primera métrica ha causado. [24]
Muchas de las ideas fundamentales para las prácticas de DevOps están inspiradas o reflejan otras prácticas bien conocidas, como el ciclo Planificar-Hacer-Verificar-Actuar de Lean y Deming , hasta el estilo Toyota y el enfoque ágil de desglosar componentes y tamaños de lotes. [25] Contrariamente al enfoque prescriptivo "de arriba hacia abajo" y al marco rígido de ITIL en la década de 1990, DevOps es "de abajo hacia arriba" y flexible, ya que fue creado por ingenieros de software para sus propias necesidades. [26]
Las motivaciones de lo que se ha convertido en DevOps moderno y varias prácticas estándar de DevOps, como la creación y prueba automatizadas, la integración continua y la entrega continua , se originaron en el mundo ágil, que data (informalmente) de la década de 1990 y formalmente de 2001. Los equipos de desarrollo ágiles utilizan métodos como la programación extrema no podrían "satisfacer al cliente mediante la entrega temprana y continua de software valioso" [27] a menos que asumieran la responsabilidad de las operaciones y la infraestructura de sus aplicaciones, automatizando gran parte de ese trabajo. Debido a que Scrum surgió como el marco Agile dominante a principios de la década de 2000 y omitió las prácticas de ingeniería que formaban parte de muchos equipos Agile, el movimiento para automatizar operaciones y funciones de infraestructura se separó de Agile y se expandió a lo que se ha convertido en DevOps moderno. Hoy en día, DevOps se centra en la implementación de software desarrollado, ya sea que se desarrolle utilizando metodologías orientadas a Agile u otras metodologías.
ArchOps presenta una extensión para la práctica de DevOps, a partir de artefactos de arquitectura de software , en lugar de código fuente, para la implementación de operaciones. [28] ArchOps afirma que los modelos arquitectónicos son entidades de primera clase en el desarrollo, implementación y operaciones de software.
La automatización es un principio fundamental para lograr el éxito de DevOps y CI/CD es un componente crítico. [29] Además, la colaboración y la comunicación mejoradas entre y dentro de los equipos ayudan a lograr un tiempo de comercialización más rápido , con riesgos reducidos. [30]
Mobile DevOps es un conjunto de prácticas que aplica los principios de DevOps específicamente al desarrollo de aplicaciones móviles. DevOps tradicional se centra en optimizar el proceso de desarrollo de software en general, pero el desarrollo móvil tiene sus propios desafíos únicos que requieren un enfoque personalizado. [31] Mobile DevOps no es simplemente una rama de DevOps específica para el desarrollo de aplicaciones móviles, sino una extensión y reinterpretación de la filosofía DevOps debido a requisitos muy específicos del mundo móvil.
En 2003, Google desarrolló la ingeniería de confiabilidad del sitio (SRE), un enfoque para lanzar nuevas funciones continuamente en sistemas de alta disponibilidad a gran escala manteniendo al mismo tiempo una experiencia de usuario final de alta calidad. [32] Si bien SRE es anterior al desarrollo de DevOps, generalmente se los considera relacionados entre sí. Algunos de los autores originales de la disciplina consideran SRE como una implementación de DevOps. [33]
El sistema de producción de Toyota, también conocido bajo el acrónimo TPS, fue la inspiración del pensamiento lean con su enfoque en la mejora continua , kaizen , flujo y lotes pequeños. El principio del cordón andon para crear retroalimentación rápida, enjambrar y resolver problemas proviene del TPS. [34] [35]
DevSecOps es una mejora de DevOps para permitir que las prácticas de seguridad se integren en el enfoque de DevOps. A diferencia del modelo tradicional de equipo de seguridad centralizado, cada equipo de entrega está capacitado para incluir los controles de seguridad correctos en la entrega de su software. Las prácticas y pruebas de seguridad se realizan en una etapa más temprana del ciclo de vida de desarrollo, de ahí el término " desplazamiento a la izquierda ". La seguridad se prueba en tres áreas principales: estática, composición de software y dinámica.
La verificación del software de forma estática mediante pruebas de seguridad de aplicaciones estáticas (SAST) es una prueba de caja blanca con especial enfoque en la seguridad. Dependiendo del lenguaje de programación, se necesitan diferentes herramientas para realizar dicho análisis de código estático. Se analiza la composición del software, especialmente las bibliotecas, y se compara la versión de cada componente con las listas de vulnerabilidades publicadas por el CERT y otros grupos de expertos. Al entregar software a los clientes, se centra en las licencias de biblioteca y su correspondencia con la licencia del software distribuido, especialmente las licencias copyleft .
En las pruebas dinámicas, también llamadas pruebas de caja negra , el software se prueba sin conocer sus funciones internas. En DevSecOps, esta práctica puede denominarse prueba dinámica de seguridad de aplicaciones (DAST) o prueba de penetración. El objetivo es la detección temprana de defectos, incluidos los scripts entre sitios y las vulnerabilidades de inyección SQL . Los tipos de amenazas son publicados por el proyecto de seguridad de aplicaciones web abiertas , por ejemplo su TOP10, [36] y por otros organismos.
DevSecOps también se ha descrito como un cambio cultural que implica un enfoque holístico para producir software seguro mediante la integración de educación en seguridad, seguridad por diseño y automatización de la seguridad. [37]
Las iniciativas DevOps pueden crear cambios culturales en las empresas [38] al transformar la forma en que las operaciones , los desarrolladores y los evaluadores colaboran durante los procesos de desarrollo y entrega. [39] Lograr que estos grupos trabajen de manera cohesiva es un desafío crítico en la adopción empresarial de DevOps. [40] [41] DevOps tiene tanto que ver con la cultura como con la cadena de herramientas. [42]
Aunque en principio es posible practicar DevOps con cualquier estilo arquitectónico, el estilo arquitectónico de microservicios se está convirtiendo en el estándar para construir sistemas implementados continuamente. Un servicio de tamaño pequeño permite que surja la arquitectura de un servicio individual a través de una refactorización continua. [43]
También respalda la coherencia, la confiabilidad y la eficiencia dentro de la organización y, por lo general, está habilitado mediante un repositorio de código compartido o control de versiones. Como plantea la hipótesis del investigador de DevOps Ravi Teja Yarlagadda: "A través de DevOps, se supone que todas las funciones se pueden llevar a cabo, controlar y gestionar en un lugar central utilizando un código simple". [44]
Muchas organizaciones utilizan el control de versiones para impulsar las tecnologías de automatización de DevOps, como máquinas virtuales , contenedorización (o virtualización a nivel de sistema operativo ) y CI/CD . El documento "DevOps: desarrollo de una cadena de herramientas en el ámbito bancario" señala que con equipos de desarrolladores trabajando en el mismo proyecto, "todos los desarrolladores necesitan realizar cambios en la misma base de código y, a veces, editar incluso los mismos archivos. Para un trabajo eficiente, hay Tiene que ser un sistema que ayude a los ingenieros a evitar conflictos y conservar el historial del código base", [45] con el sistema de control de versiones Git y la plataforma GitHub como ejemplos.
GitOps evolucionó a partir de DevOps. El estado específico de la configuración de implementación está controlado por la versión . Debido a que el control de versiones más popular es Git , el enfoque de GitOps lleva el nombre de Git . Los cambios en la configuración se pueden gestionar mediante prácticas de revisión de código y se pueden revertir mediante el control de versiones. Básicamente, se realiza un seguimiento de todos los cambios en un código, se marcan como favoritos y se puede facilitar la realización de actualizaciones en el historial. Como explica Red Hat , "la visibilidad del cambio significa la capacidad de rastrear y reproducir problemas rápidamente, mejorando la seguridad general". [46]
{{cite journal}}: Citar diario requiere |journal=( ayuda ){{cite book}}: Mantenimiento CS1: falta el editor de la ubicación ( enlace )