DevOps
Conjunto de prácticas de desarrollo de software

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]

Definición

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]

Historia

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]

Relación con otros enfoques

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]

Ágil

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

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.

Integración y entrega continuas (CI/CD)

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]

DevOps móvil

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.

Ingeniería de confiabilidad del sitio

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]

Sistema de producción Toyota, pensamiento lean, kaizen

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, desplazando la seguridad hacia la izquierda

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]

Cambio cultural

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]

Microservicios

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]

Automatización DevOps

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]

Automatización con control de versiones

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

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]

Mejores prácticas para sistemas en la nube

Las siguientes prácticas pueden mejorar la productividad de los pipelines de DevOps , especialmente en sistemas alojados en la nube : [47] [48] [49]

  • Número de pipelines : los equipos pequeños pueden ser más productivos si cuentan con un repositorio y un pipeline. Por el contrario, las organizaciones más grandes pueden tener repositorios y pipelines separados para cada equipo o incluso repositorios y pipelines separados para cada servicio dentro de un equipo.
  • Permisos : en el contexto de los permisos relacionados con las tuberías , cumplir con el principio del mínimo privilegio puede resultar complicado debido a la naturaleza dinámica de la arquitectura . Los administradores pueden optar por permisos más permisivos e implementar controles de seguridad compensatorios para minimizar el radio de acción.

Véase también

Notas

  1. ^ Dyck et al. (2015) "Hasta donde sabemos, no existe una definición uniforme de los términos ingeniería de lanzamiento y DevOps. Como consecuencia, muchas personas utilizan sus propias definiciones o se basan en otras, lo que genera confusión sobre esos términos". [3]
  2. ^ Jabbari et al. (2016) "Los resultados de la investigación de este estudio mostraron la necesidad de una definición, ya que los estudios individuales no definen DevOps de manera consistente". [4]
  3. ^ Erich et al. (2017) "Notamos que existen varias lagunas en el estudio de DevOps: no hay consenso sobre qué conceptos cubre DevOps ni cómo se define DevOps". [5]
  4. ^ Erich et al. (2017) "Descubrimos que existe poco acuerdo sobre las características de DevOps en la literatura académica". [5]

Referencias

  1. ^ Courtemanche, Meredith; Mell, Emily; Gills, Alexander S. "¿Qué es DevOps? La guía definitiva". TechTarget . Consultado el 22 de enero de 2023 .
  2. ^ Fundamentos de la arquitectura de software: un enfoque de ingeniería . O'Reilly Media. 2020. ISBN 978-1492043454.
  3. ^ Dyck, Andrej; Penners, Ralf; Lichter, Horst (19 de mayo de 2015). "Hacia definiciones para ingeniería de versiones y DevOps". 2015 IEEE/ACM 3rd International Workshop on Release Engineering . IEEE . p. 3. doi :10.1109/RELENG.2015.10. ISBN 978-1-4673-7070-7.S2CID 4659735  .
  4. ^ Jabbari, Ramtin; bin Ali, Nauman; Petersen, Kai; Tanveer, Binish (mayo de 2016). "¿Qué es DevOps?: un estudio de mapeo sistemático sobre definiciones y prácticas". Actas del taller científico de 2016 . Association for Computing Machinery .
  5. ^ ab Erich, FMA; Amrit, C.; Daneva, M. (junio de 2017). "Un estudio cualitativo del uso de DevOps en la práctica" (PDF) . Journal of Software: Evolution and Process . 29 (6): e1885. doi :10.1002/smr.1885. S2CID  35914007.
  6. ^ Bass, Len; Weber, Ingo; Zhu, Liming (2015). DevOps: la perspectiva de un arquitecto de software . Addison-Wesley. ISBN 978-0134049847.
  7. ^ Muñoz, Mirna; Negrete Rodríguez, Mario (abril de 2021). “Una guía para implementar o reforzar un enfoque DevOps en las organizaciones: Un caso de estudio”. {{cite journal}}: Requiere citar revista |journal=( ayuda )
  8. ^ Chapman, M., Gatti, N: Un modelo de ciclo de vida de servicio, Actas de TINA '93, págs. I-205–I-215, septiembre de 1993.
  9. ^ Atlassian. «Historia de DevOps». Atlassian . Consultado el 23 de febrero de 2023 .
  10. ^ Mezak, Steve (25 de enero de 2018). "Los orígenes de DevOps: ¿qué hay en un nombre?". devops.com . Consultado el 6 de mayo de 2019 .
  11. ^ Debois, Patrick (9 de octubre de 2008). "Agile 2008 Toronto". Just Enough Documented Information . Consultado el 12 de marzo de 2015 .
  12. ^ Debois, Patrick. "DevOps Days". DevOps Days . Consultado el 31 de marzo de 2011 .
  13. ^ por Alana Brown; Nicole Forsgren; Jez Humble; Nigel Kersten; Gene Kim (2016). "Informe sobre el estado de DevOps en 2016" (PDF) . Puppet Labs, DORA (DevOps Research . Consultado el 24 de abril de 2024 .
  14. ^ "Títere - Alanna Brown". Puppet Labs . Consultado el 27 de abril de 2019 .
  15. ^ Nicole Forsgren; Gene Kim; Nigel Kersten; Jez Humble (2014). "Informe sobre el estado de DevOps en 2014" (PDF) . Puppet Labs, IT Revolution Press y ThoughtWorks . Consultado el 24 de abril de 2024 .
  16. ^ "Informe sobre el estado de DevOps en 2015" (PDF) . Puppet Labs, Pwc, IT Revolution Press. 2015. Consultado el 24 de abril de 2024 .
  17. ^ "Más pruebas ágiles" (PDF) . Octubre de 2014. Consultado el 6 de mayo de 2019 .
  18. ^ Crispin, Lisa; Gregory, Janet (octubre de 2014). Más pruebas ágiles. Addison-Wesley. ISBN 9780133749571. Recuperado el 6 de mayo de 2019 .
  19. ^ Turner, Graham (20 de noviembre de 2023). "Informe: los ingenieros de software enfrentan reacciones negativas por denunciar irregularidades". DIGIT . Consultado el 5 de enero de 2024 .
  20. ^ Saran, Cliff. "Los ingenieros de software se preocupan por hablar abiertamente - Computer Weekly". ComputerWeekly.com . Consultado el 5 de enero de 2024 .
  21. ^ "El 75% de los ingenieros de software sufrieron represalias la última vez que denunciaron una irregularidad - ETHRWorldSEA". ETHRWorld.com .
  22. ^ Cummins, Holly. "Holly Cummins en X". X.com . Consultado el 5 de enero de 2024 .
  23. ^ DeBellis, Derek; Lewis, Amanda; Villalba, Daniella; Farley, Dave. "Informe sobre el estado de DevOps en 2023". Investigación y evaluación de DevOps en Google Cloud . Consultado el 24 de abril de 2024 .
  24. ^ DeBellis, Derek; Harvey, Nathan. "Informe sobre el estado de DevOps en 2023: la cultura lo es todo". Blog de Google Cloud . Consultado el 24 de abril de 2024 .
  25. ^ Klein, Brandon Thorin (1 de mayo de 2021). "DevOps: una comprensión concisa de la filosofía y la ciencia de DevOps". Osti.gov . doi :10.2172/1785164. OSTI  1785164. S2CID  236606284.
  26. ^ "La historia y evolución de DevOps | Tom Geraghty". 5 de julio de 2020. Consultado el 29 de noviembre de 2020 .
  27. ^ "Principios detrás del Manifiesto Ágil". agilemanifesto.org . Consultado el 6 de diciembre de 2020 .
  28. ^ Castellanos, Camilo; Correal, Dario (15 de septiembre de 2018). "Ejecución de modelos arquitectónicos para análisis de big data". Arquitectura de software . Apuntes de clase en informática. Vol. 11048. págs. 364–371. doi :10.1007/978-3-030-00761-4_24. ISBN 978-3-030-00760-7.
  29. ^ Humble, Jez; Farley, David (2011). Entrega continua: lanzamientos de software confiables mediante automatización de la creación, prueba e implementación . Pearson Education Inc. ISBN 978-0-321-60191-9.
  30. ^ Chen, Lianping (2015). "Entrega continua: enormes beneficios, pero también desafíos". IEEE Software . 32 (2): 50–54. doi :10.1109/MS.2015.27. S2CID  1241241.
  31. ^ Tak, Rohin; Modi, Jhalak (2018). Mobile DevOps: Ofrezca integración e implementación continuas dentro de sus aplicaciones móviles . Packt Publishing. págs. 12–18. ISBN 9781788296243.
  32. ^ Beyer, Betsy; Jones, Chris; Petoff, Jennifer; Murphy, Niall Richard (abril de 2016). Ingeniería de confiabilidad del sitio . O'Reilly Media. ISBN 978-1-4919-2909-4.
  33. ↑ Dave Harrison (9 de octubre de 2018). «Entrevista con Betsy Beyer y Stephen Thorne de Google» . Consultado el 24 de julio de 2024 .
  34. ^ Analizando el ADN de DevOps, Brent Aaron Reed, Willy Schaub, 14 de noviembre de 2018.
  35. ^ Gene Kim; Patrick Debois; John Willis; Jezz Humble (2016). Manual de DevOps: Cómo crear agilidad, confiabilidad y seguridad de clase mundial en organizaciones tecnológicas .
  36. ^ "TOP10 de OWASP". Archivado desde el original el 8 de junio de 2023. Consultado el 8 de junio de 2023 .
  37. ^ Wilson, Glenn (diciembre de 2020).'DevSecOps: una guía para líderes sobre cómo producir software seguro con flujo de trabajo, retroalimentación y mejora continua'. Repensar la prensa. ISBN 978-1781335024.
  38. ^ Análisis de tecnologías emergentes: DevOps es un cambio cultural, no una tecnología (informe). Gartner.
  39. ^ Loukides, Mike (7 de junio de 2012). "¿Qué es DevOps?". O'Reilly Media .
  40. ^ "Gartner IT Glossary – devops". Gartner . Consultado el 30 de octubre de 2015 .
  41. ^ Jones, Stephen; Noppen, Joost; Lettice, Fiona (21 de julio de 2016). Actas del 2.º taller internacional sobre DevOps con conciencia de calidad - QUDOS 2016 (PDF) . págs. 7-11. doi :10.1145/2945408.2945410. ISBN . 9781450344111.S2CID 515140  .
  42. ^ Mandi Walls (25 de septiembre de 2015). "Construyendo una cultura DevOps". O'Reilly.
  43. ^ Chen, Lianping; Ali Babar, Muhammad (2014). "Conferencia IEEE/IFIP 2014 sobre arquitectura de software". La 11.ª Conferencia de trabajo IEEE/IFIP sobre arquitectura de software (WICSA 2014) . IEEE. págs. 195–204. doi :10.1109/WICSA.2014.45. ISBN 978-1-4799-3412-6.
  44. ^ Teja Yarlagadda, Ravi (9 de marzo de 2021). "DevOps y sus prácticas". SSRN  3798877.
  45. ^ Morisio, Maurizio (16 de abril de 2021). DevOps: desarrollo de una cadena de herramientas en el ámbito bancario. Politecnico di Torino (tesis laureada) . Consultado el 16 de agosto de 2021 .
  46. ^ "¿Qué es GitOps?". www.redhat.com . Consultado el 30 de marzo de 2023 .
  47. ^ Arquitecturas sin servidor en AWS . Manning. ISBN 978-1617295423.
  48. ^ Entrega continua de pipeline como código con Jenkins, Kubernetes y Terraform . Manning. ISBN 9781638350378.
  49. ^ Entrega continua de versiones de software confiables mediante automatización de la creación, prueba e implementación . ISBN 9780321670229.

Lectura adicional

  • Davis, Jennifer; Daniels, Ryn (30 de mayo de 2016). DevOps eficaz: creación de una cultura de colaboración, afinidad y herramientas a escala . Sebastopol, CA: O'Reilly. ISBN 9781491926437.OCLC 951434424  .
  • Kim, Gene; Debois, Patrick; Willis, John; Humble, Jez; Allspaw, John (7 de octubre de 2015). Manual de DevOps: cómo crear agilidad, confiabilidad y seguridad de clase mundial en organizaciones tecnológicas (primera edición). Portland, OR. ISBN 9781942788003.OCLC 907166314  .{{cite book}}: Mantenimiento de CS1: falta la ubicación del editor ( enlace )
  • Forsgren, Nicole; Humble, Jez; Kim, Gene (27 de marzo de 2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (Primera edición). IT Revolution Press. ISBN 9781942788331.
Obtenido de "https://es.wikipedia.org/w/index.php?title=DevOps&oldid=1257910385#DevSecOps,_desplazando_la_seguridad_hacia_la_izquierda"