DevOps es una metodología en la industria de desarrollo de software y 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 del desarrollo de sistemas . [1] DevOps es complementario al desarrollo de software ágil ; varios aspectos de DevOps provienen de la forma de trabajo ágil .
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 los profesionales no han desarrollado una definición universal para el término "DevOps". [a] [b] [c] [d] La mayoría de las veces, 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 de ciencias de la computación de 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 confirmación de un cambio en un sistema y la puesta en producción normal del cambio, al tiempo que se garantiza 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 de cultura y herramientas. [7]
Las propuestas para combinar metodologías de desarrollo de software con conceptos de implementación y operaciones comenzaron a aparecer a finales de los años 80 y principios de los 90. [8]
Alrededor de 2007 y 2008, quienes trabajaban en las comunidades de desarrollo de software y TI expresaron su preocupación por que la separación entre las dos industrias, donde uno escribía y creaba software completamente separado de quienes lo implementaban y lo soportaban, estaba creando un nivel fatal de disfunción dentro de la industria. [9]
En 2009, se celebró en Gante (Bélgica) la primera conferencia, denominada DevOps Days . La conferencia fue fundada por el consultor, director de proyectos y practicante ágil belga Patrick Debois. [10] [11] La conferencia se ha extendido ahora a otros países. [12]
En 2012, Alanna Brown publicó por primera vez un informe llamado "Estado de DevOps" en Puppet Labs . [13] [14]
En 2014, Nicole Forsgren , Gene Kim, Jez Humble y otros publicaron el informe anual State of DevOps , en el que 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 DORA para el rendimiento (frecuencia de implementación, tiempo de espera para los cambios) y la estabilidad (tiempo medio de recuperación, tasa de fallas de cambio) se publicaron en el informe State of DevOps. [13] Sin embargo, la metodología de investigación y las métricas fueron criticadas por los expertos. [19] [20] [21] [22] En respuesta a estas críticas, el informe State of DevOps 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 que la métrica anterior ha causado. [24]
Muchas de las ideas fundamentales de las prácticas de DevOps están inspiradas en, o reflejan, otras prácticas bien conocidas como Lean y el ciclo Planificar-Hacer-Verificar-Actuar de Deming , hasta The Toyota Way y el enfoque Agile de desglosar componentes y tamaños de lotes. [25] A diferencia del enfoque prescriptivo "de arriba hacia abajo" y el marco rígido de ITIL en la década de 1990, DevOps es "de abajo hacia arriba" y flexible, habiendo sido creado por ingenieros de software para sus propias necesidades. [26]
Las motivaciones para lo que se ha convertido en DevOps moderno y varias prácticas estándar de DevOps como la compilación y prueba automatizadas, la integración continua y la entrega continua se originaron en el mundo Agile, que data (informalmente) de la década de 1990, y formalmente de 2001. Los equipos de desarrollo Agile que utilizan métodos como la programación extrema no podí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 las operaciones y las funciones de infraestructura se separó de Agile y se expandió a lo que se ha convertido en DevOps moderno. Hoy, DevOps se centra en la implementación del 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, comenzando desde artefactos de arquitectura de software , en lugar del 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, la implementación y las 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, una mejor colaboración y comunicación entre y dentro de los equipos ayuda a lograr un tiempo de comercialización más rápido , con riesgos reducidos. [30]
Mobile DevOps es un conjunto de prácticas que aplican los principios de DevOps específicamente al desarrollo de aplicaciones móviles. El 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 los requisitos muy específicos del mundo móvil.
En 2003, Google desarrolló la ingeniería de confiabilidad de sitios (SRE), un enfoque para lanzar nuevas funciones de manera continua en sistemas de alta disponibilidad a gran escala, manteniendo al mismo tiempo una experiencia de usuario final de alta calidad. [32] Si bien la SRE es anterior al desarrollo de DevOps, generalmente se las considera relacionadas entre sí. Algunos de los autores originales de la disciplina consideran que la SRE es 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 para el pensamiento lean con su enfoque en la mejora continua , kaizen , flujo y lotes pequeños. El principio de cordón andon para crear retroalimentación rápida, enjambre y resolver problemas proviene del TPS. [34] [35]
DevSecOps es una ampliación de DevOps que permite integrar las prácticas de seguridad en el enfoque de DevOps. A diferencia de un modelo de equipo de seguridad centralizado tradicional, cada equipo de entrega tiene la capacidad de tener en cuenta 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 del desarrollo, de ahí el término " desplazamiento a la izquierda ". La seguridad se prueba en tres áreas principales: estática, composición del software y dinámica.
La comprobación estática del software mediante pruebas de seguridad de aplicaciones estáticas (SAST) es una prueba de caja blanca con especial atención a la seguridad. Según el lenguaje de programación, se necesitan diferentes herramientas para realizar este análisis estático del código. Se analiza la composición del software, especialmente las bibliotecas, y se comprueba la versión de cada componente con las listas de vulnerabilidades publicadas por CERT y otros grupos de expertos. Al entregar software a los clientes, se presta especial atención a las licencias de las bibliotecas y a 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 de seguridad de aplicaciones dinámicas (DAST) o prueba de penetración. El objetivo es la detección temprana de defectos, incluidas las vulnerabilidades de inyección SQL y de secuencias de comandos entre sitios . 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 de DevOps en las empresas. [40] [41] DevOps tiene que ver tanto 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 la arquitectura de un servicio individual surja 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 generalmente se habilita mediante un repositorio de código compartido o un control de versiones. Como plantea la hipótesis del investigador de DevOps Ravi Teja Yarlagadda, "a través de DevOps, se asume que todas las funciones se pueden llevar a cabo, controlar y administrar en un lugar central utilizando un código simple". [44]
Muchas organizaciones utilizan el control de versiones para impulsar tecnologías de automatización de DevOps como máquinas virtuales , contenedorización (o virtualización a nivel de SO ) y CI/CD . El artículo "DevOps: desarrollo de una cadena de herramientas en el ámbito bancario" señala que con equipos de desarrolladores que trabajan 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 trabajar de manera eficiente, tiene que haber un sistema que ayude a los ingenieros a evitar conflictos y conservar el historial de la base de código", [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 versiones . Debido a que el control de versiones más popular es Git , el enfoque de GitOps recibió su nombre de Git . Los cambios en la configuración se pueden administrar mediante prácticas de revisión de código y se pueden revertir mediante el control de versiones. Básicamente, todos los cambios en un código se rastrean, se marcan y se puede realizar cualquier actualización al historial de manera más fácil. Como explica Red Hat , "la visibilidad de los cambios significa la capacidad de rastrear y reproducir problemas rápidamente, lo que mejora la seguridad general". [46]
{{cite journal}}
: Requiere citar revista |journal=
( ayuda ){{cite book}}
: Mantenimiento de CS1: falta la ubicación del editor ( enlace )