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]
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. [2]
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. [3]
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. [4] [5] La conferencia ahora se ha extendido a otros países. [6]
En 2012, Alanna Brown en Puppet Labs publicó por primera vez un informe llamado "Estado de DevOps" . [7] [8]
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. [9] [10] También en 2014, Lisa Crispin y Janet Gregory escribieron el libro More Agile Testing, que contiene un capítulo sobre pruebas y DevOps. [11] [12]
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. [7] Sin embargo, la metodología y las métricas de la investigación fueron criticadas por los expertos. [13] [14] [15] [16]
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 The Toyota Way y el enfoque ágil de descomponer componentes y tamaños de lotes. [17] 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. [18]
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" [19] 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 ágil dominante a principios de la década de 2000 y omitió las prácticas de ingeniería que formaban parte de muchos equipos ágiles, 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. [20] 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. [21] 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. [22]
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. [23] Si bien SRE es anterior al desarrollo de DevOps, generalmente se los considera relacionados entre sí.
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 cable andon para crear retroalimentación rápida, enjambrar y resolver problemas proviene del TPS. [24] [25]
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.
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, [26] 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. [27]
Las iniciativas DevOps pueden crear cambios culturales en las empresas [28] al transformar la forma en que las operaciones , los desarrolladores y los evaluadores colaboran durante los procesos de desarrollo y entrega. [29] Lograr que estos grupos trabajen de manera cohesiva es un desafío crítico en la adopción empresarial de DevOps. [30] [31] DevOps tiene tanto que ver con la cultura como con la cadena de herramientas. [32]
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. [33]
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". [34]
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", [35] 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". [36]