La histórica conferencia de 2009 de John Allspaw y Paul Hammond
The (short) History of DevOps
El legendario origen del movimiento DevOps

En la conferencia Agile 2008 Toronto, Yhens Wasna y Patrick Debois introdujeron el término en su charla sobre “Infraestructura Ágil”.​ A partir de 2009, el término DevOps se ha promocionado constantemente y se ha incorporado a un uso más general a través de una serie de “devopsdays”,6 que comenzaron en Bélgica y ahora también se han extendido a otros países.7

El término DevOps ha sido utilizado en múltiples contextos diferentes.

Una definición propuesta por Bass, Weber y Zhu es:

DevOps es un conjunto de prácticas destinadas a reducir el tiempo entre el compromiso de un cambio en una aplicación y el cambio que se coloca en la producción normal, al tiempo que garantiza una alta calidad.9

Fuente: https://es.wikipedia.org/wiki/DevOps

Hilo de Twitter: Here are some major milestones of the DevOps movement:

• 2009: John Allspaw (@allspaw) and Paul Hammond (@ph) give their famous presentation “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” https://youtu.be/LdOe18KhtT4
• 2009: Patrick Debois (@patrickdebois) famously missed Velocity where “10+ Deploys Per Day” was delivered, and organized the first-ever @devopsdays in Ghent. He also coined #DevOps as a shortened hashtag.
• 2013: Puppet Labs (@puppetize) and IT Revolution Press (@ITRevBooks) released the first State of DevOps Report. #stateofdevops
• 2014: 1st ever DevOps Enterprise Summit (#DOES14) where well-known, large organizations get on stage to talk about their technology transformations. @jasonacox @cdavisafc @dominicad @damonedwards @chawklady @botchagalupe @FletcherJofanon @jonsmart @Ben_Grinnell @jgallimore
• 2016: The DevOps Handbook is published (the first section is included in 5th Anniversary Edition of The Phoenix Project). @realgenekim @botchagalupe @patrickdebois @jezhumble
• Massive companies begin declaring the importance of technology. Like @Target. @hmickman @RossClanton
• And @Nationwide. cc: @carmendeardo
• And @Nike. @chawklady @annebradley
• And @Comcast.
• The #data that DevOps works speaks for itself – Accelerate won the @ShingoPrize Publication award in 2019. Congrats to @nicolefv, @jezhumble and @realgenekim. @JAChavner
• This is just a small slice of the impact that DevOps and The Phoenix Project have made.
• Oh yeah, and while The Phoenix Project addresses the Ops side of the story, we’ve just released The #UnicornProject by @realgenekim which covers the #Dev side and landed on the @WSJ bestsellers list. Check it out here: https://itrevolution.com/the-unicorn-project/
• Since 2013, The Phoenix Project has sold over 500,000 copies, and is constantly given by consultants as gifts to clients, by managers as training to employees, and by co-workers to peers as an example of a new way of working.
• The Phoenix Project has been translated into 11 other languages
• “Parts Unlimited” has become the ultimate fictitious company used across the industry.
• A live, multi-day simulation by @gamingpaul is run by companies like @Ranger4ltd, @theitilexperts, @Xebia, @itsmacademy, @IILGlobal, @centric, @DevoteamNL, and more.
• Fanfiction has sprouted up, including this org chart for Parts Unlimited: https://twitter.com/MattThatITGuy/status/730170546139189253/photo/1
• Children are being raised (properly) on the principles in the book
• It has inspired a multitude of summaries, reading guides, and look-alike books on Amazon (all of which are unauthorized, so please refrain from buying them).
• Widespread readership of The Phoenix Project has been growing steadily, much like the interest in DevOps itself (maybe not THAT rapidly—whoa).

Sobre la novela “The Phoenix Project”: https://www.javiergarzas.com/2016/06/la-historia-del-proyecto-phoenix-devops-agilidad-salvar-proyecto-fracaso.html

The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. (1st ed.)
The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. (2nd ed, nov 2021)
Phoenix Project: A Novel about It, Devops, and Helping Your Business Win
The Unicorn Project: A Novel about Developers, Digital Disruption, and Thriving in the Age of Data

DevOps y Agile: diferencias y similitudes entre estas metodologías de desarrollo de software, becas-santander.com
Las metodologías ágiles y DevOps: ¿amigos o enemigos? , atlassian.com
DevOps frente al método ágil, microsoft.com
The rise of the DevOps mindset, stackoverflow.blog
What is the difference between continuous integration, continuous delivery and DevOps?, stackoverflow.com
How is DevOps related to Agile?, devops.stackexchange.com

There's no such a thing as a 'DevOps Team'

Best DevOps tools
DevOps and PaaS
What is DevOps
The Rise of DevOps

Daniel Jimenez nos presenta las técnicas de desarrollo de software que han nacido y evolucionado en el corazón de Silicon Valley durante los últimos 10 años y que todo buen desarrollador actual debe dominar. Conceptos como DevOps, la integración y el despliegue continuos, automatización, fallo-temprano, desarrollo dirigido por pruebas, son la base del desarrollo moderno de software.

https://t3chfest.uc3m.es/2018/programa/como-se-desarrolla-software-en-siglo-xxi/

La computación “sin servidores” representa uno de los mayores hitos del cloud computing. Amazon, Google y Microsoft ya ofrecen estos servicios a cualquier desarrollador en un irresistible formato pay as you go. Exponer servicios web al mundo a través de funciones nunca ha sido más sencillo. Problemas como el balanceo de carga, la disponibilidad de los servidores, la configuración del sistema operativo o el aprovisionamiento de unidades de cómputo adicionales pasan a formar parte de las responsabilidades del proveedor. Manejar el éxito está al alcance de cualquier desarrollador.

OpenFaaS es un proyecto open source que ofrece la posibilidad de alojar estas funciones sobre infraestructura propia. Basado en los principios de Docker y Kubernetes, OpenFaaS se posiciona como la alternativa libre para desarrollar, alojar y exponer soluciones serverless sin importar el lenguaje en el que hayan sido desarrolladas.

https://t3chfest.uc3m.es/2018/programa/serverless-con-aws-lambda-openfaas/

In recent years, the use and abuse of container systems has become widespread. Among those, Docker is the knight in shining armor that comes to the rescue of many. Its name is now part of the Buzzword Hall of Fame, filling up piles of both CVs and job descriptions. And, still, most people don’t quite get what containers are, Docker or otherwise, Linux or Windows. In this talk we will explain what Linux containers are made of: chroot jails, cgroups, namespaces, capabilities… through a live command line example you will be able to run yourself!

https://t3chfest.uc3m.es/2018/programa/docker-without-docker-containers-behind-the-scenes/

Las bases de datos orientadas a analíticas (OLAP) son cada vez mas usadas en entornos Big Data para calcular analíticas. Dentro de ellas las BBDD orientadas a columnas cada vez son mas comunes. Las implementaciones comerciales mas famosas son PaaS como Amazon Redshift o Google BigQuery. Dentro del mundo open source también existen alternativas. Mis favoritas son Druid y sobre todo Clickhouse.

En la charla daré una introducción a las bases de datos orientadas a columnas y a Clickhouse en particular. La charla tendrá bastante componente practico. Usaré Docker para tener una instancia de Clickhouse y otra de otra BD con datos cargados para comparar el performance de alguna query. Si hay tiempo tambien usare algún Visualization Dashboard (Superset, Redash, etc) para pintar alguna gráfica.

https://t3chfest.uc3m.es/2018/programa/clickhouse-una-base-datos-orientada-columnas/

En esta charla hablaré del panorama actual de los microservicios, de dónde venimos y a dónde vamos (contenedores y orquestación incluídos). Todo ello para componer un contexto donde podamos ubicar el concepto de service mesh y entender cuándo nos puede aportar valor. Además, hablaré de las diferentes tecnologías que han surgido en torno a este concepto, como por ejemplo los microservicios de Netflix o Istio.

https://t3chfest.uc3m.es/2018/programa/service-mesh-vitamina-microservicios/

Digital transformation is the new hype. The concept that everyone uses and few ones define. However, one issue is not debatable, digital transformation is here to stay and we, as computer engineers, will have to deal with it. This talk will give an overview of digital transformation and digital business terminology. The final purpose is to allow attendees to develop common ground to bridge the differences with other digital professionals.

https://t3chfest.uc3m.es/2017/programa/25terms-every-computer-engineer-should-know-about-digital-transformation/

Ya hace un tiempo que las arquitecturas basadas en microservicios se han extendido y ahora parece que si no trabajas en una no estás a la última, pero no es oro todo lo que reluce y hay muchas piedras ocultas en el camino esperando a que te des de bruces con ellas.

En esta charla te contaremos a través de nuestros propios “fails” la historia de como se ha estado migrando una arquitectura monolítica a una nueva arquitectura basada en microservicios, qué lenguajes de programación y qué herramientas nos han resultado útiles para el desarrollo en el día a día así como las decisiones y cambios de planes que hemos tenido que ir tomando por el camino para sobrevivir a los imprevistos.

https://t3chfest.uc3m.es/2017/programa/microservicios/

¿Has soñado alguna vez con diseñar y construir las máquinas, servicios, redes, almacenamiento y demás elementos de tu datacenter como si estuvieras escribiendo un programa informático? ¿Y si con ese código no solo tuvieras todo perfectamente documentado sino que además pudieras desplegar toda la infraestructura de forma automatizada en minutos? ¡Deja de soñarlo! Gracias a Azure Resource Manager esto es una realidad y Avanade te enseña en directo cómo.

https://t3chfest.uc3m.es/2017/programa/datacenter-pendrive-gracias-infraestructura-codigo-microsoft-azure/

(Traducción automática del artículo DevOps de Wikipedia en lengua inglesa.

Al artículo se le hacen una serie de críticas interesantes en la sección de debate:

This article is a joke, right from the very first poorly written paragraph. DevOps is culture, period. Whomever wrote it is totally confused about the difference between Agile and DevOps, particularly when DevOps as a practice can and is widely used in both Agile and Waterfall environments. It should be completely rewritten by someone who knows what they are talking about. Flybd5 (talk) 11:48, 26 September 2019 (UTC)

Containers Will Not Fix Your Broken Culture (and Other Hard Truths). Complex socio-technical systems are hard; film at 11.

This does not make sense and needs to be reviewed with a close reading of the source. A change in thinking is cultural change.

The article is in IT management speak, and needs to define terms to meet the needs of the general wikipedia audience.

The article is missing the business facilitation aspects of DevOps from which all the technical aspects, such as CICD, stem. For example; managing the four types of work, the 'three ways' of collaboration, and DevOps' basis in manufacturing and team function study. To state that the article is locked or beyond criticism is not rational. Regardless of which elements of this have worked their way into agile methodologies, (of which there are almost countless varieties), I cannot see how a person can understand DevOps without the underlying principles explained.

Even as a software developer, I don't understand what the section wants to explain about DevOps as a job title. It is clearly a topic worth mentioning but I don't see how the article answers the question what such job title represents. — Preceding unsigned comment added by 2A01:CB05:4AE:F500:1091:75DE:9C49:FBF6 (talk) 07:23, 2 March 2018 (UTC)

I completely agree. I'm looking for jobs in the software development field and see the title 'DevOps' all the time, and after reading this page i am still completely clueless as to what it means. Grimdark (talk) 16:03, 21 March 2019 (UTC)

The section about the job title is in response to the people who say “DevOps is culture, period.” (see above) This would be fine if it were 2009 and you hung out at the Ghent DevOps Days. In 2020, the battle has been lost! DevOps is both about tools and culture and is a widespread job title: https://www.indeed.com/jobs?q=devops For people who want to fight an unwinnable battle, then contact each hiring manager for each current DevOps job posting and correct them.Sp00nfeeder (talk) 05:50, 9 January 2020 (UTC)

Fuente: https://en.wikipedia.org/wiki/DevOps

DevOps es un conjunto de prácticas que combina el desarrollo de software ( Dev ) y las operaciones de TI ( Ops ). Su objetivo es acortar el ciclo de vida del desarrollo de sistemas y proporcionar una entrega continua con software de alta calidad. DevOps es complementario con el desarrollo de software ágil ; varios aspectos de DevOps provienen de la metodología Agile.

Aparte de ser una combinación multifuncional 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”. 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 en ciencias de la computación del CSIRO y el Software Engineering Institute— sugirieron definir DevOps como “un conjunto de prácticas destinadas a reducir el tiempo entre realizar un cambio en un sistema y el cambio se coloca en la producción normal, garantizando al mismo tiempo una alta calidad ”.

Sin embargo, el término se usa 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.

En 1993, el Consorcio de Arquitectura de Redes de Información de Telecomunicaciones ( TINA-C ) definió un Modelo de Ciclo de Vida de Servicio que combinaba el desarrollo de software con las operaciones de servicios (de telecomunicaciones). [7] Algunos dicen que DevOps surgió en parte como una reacción al enfoque proscriptivo “de arriba hacia abajo” de ITIL en la década de 1990. DevOps, como un enfoque “de abajo hacia arriba”, ganó fuerza y ​​persistió porque fue creado por ingenieros de software para ingenieros de software, y es una práctica flexible en lugar de un marco rígido.

En 2014, Lisa Crispin y Janet Gregory escribieron el libro More Agile Testing, que contiene un capítulo sobre pruebas y DevOps.

La taxonomía de DevOps se perfeccionó y se puso a disposición del público en 2021 mediante el lanzamiento de un documento técnico titulado “ DevOps: una comprensión concisa de la filosofía y la ciencia de DevOps ”. [9] La taxonomía DevOps consta de Filosofía y Ciencia , sus respectivas ramas ( Epistemología y Ontología ; Social y Aplicada ) y subdominios ( Creencia , Conocimiento y Verdad ; Sociología , Psicología , Economía e Ingeniería.) con las instancias proporcionadas ( Agile , Quality Assurance , Lean ; Culture Transformation , Faster Time to Market y Automation ).

Dado que DevOps está destinado a ser un modo de trabajo multifuncional, quienes practican la metodología utilizan diferentes conjuntos de herramientas, denominadas “ cadenas de herramientas ”, en lugar de una sola. [10] Se espera que estas cadenas de herramientas encajen en una o más de las siguientes categorías, lo que refleja aspectos clave del proceso de desarrollo y entrega.

1. Codificación: desarrollo y revisión de código, herramientas de gestión de código fuente , combinación de código.
2. Construcción: herramientas de integración continua , estado de la construcción.
3. Pruebas: herramientas de prueba continua que brindan retroalimentación rápida y oportuna sobre los riesgos comerciales.
4. Empaquetado: repositorio de artefactos , preparación previa a la implementación de la aplicación.
5. Liberación: gestión de cambios, aprobaciones de versiones , automatización de versiones .
6. Configuración: configuración y gestión de la infraestructura , infraestructura como herramientas de código .
7. Supervisión: supervisión del rendimiento de las aplicaciones , experiencia del usuario final.

Muchas de las ideas fundamentales para las prácticas de DevOps se inspiran o reflejan en otras prácticas bien conocidas, como el ciclo Planificar-Hacer-Verificar-Actuar de Lean y Deming , hasta The Toyota Way y el enfoque Agile de desglosar componentes y tamaños de lotes.

Las motivaciones de lo que se ha convertido en DevOps moderno y varias prácticas de DevOps estándar, como la compilación y prueba automatizadas, la integración continua y la entrega continua, se originaron en el mundo Agile, que data (informalmente) a la década de 1990 y formalmente a 2001. Equipos de desarrollo ágiles que utilizan métodos como Extreme Programming no podrían “satisfacer al cliente mediante la entrega temprana y continua de software valioso” [11] a menos que subsumieran las responsabilidades de operaciones / infraestructura asociadas con sus aplicaciones, muchas de las cuales automatizaron. Porque Scrumsurgió 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 funciones de operaciones / 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 a través de 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. [12] 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 fundamental.

CI / CD se compone de integración continua (CI) y entrega continua (CD) o implementación continua (CD). Usados ​​juntos, los tres procesos automatizan la construcción, las pruebas y la implementación para que los equipos de DevOps puedan enviar cambios de código de manera más rápida y confiable. Cuando se hace referencia a CI / CD, el “CD” al que se hace referencia suele ser entrega continua, no implementación continua. La entrega continua y otros procesos de CI / CD se enfocan en automatizar las tareas de entrega de software , mientras que DevOps también se enfoca en el cambio organizacional para respaldar una gran colaboración entre las muchas funciones involucradas. Ambos comparten un trasfondo común en métodos ágiles y pensamiento esbelto., priorizando cambios pequeños y frecuentes con valor enfocado al cliente final. Esto garantiza dos cosas: el software siempre está en un estado de liberación durante todo su ciclo de vida, lo que hace que sea más barato y menos riesgoso entregar el software.

Además, la colaboración y la comunicación mejoradas entre y dentro de los equipos ayuda a lograr un tiempo de comercialización más rápido , con riesgos reducidos.

La aplicación de entrega continua y DevOps al análisis de datos se ha denominado DataOps. DataOps busca integrar la ingeniería de datos, la integración de datos, la calidad de los datos, la seguridad de los datos y la privacidad de los datos con las operaciones. Aplica principios de DevOps, Agile Development y el control de procesos estadísticos , utilizados en la fabricación ajustada , para mejorar el tiempo de ciclo de extracción de valor de la analítica de datos.

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 mientras se mantiene la experiencia del usuario final de alta calidad. [16] Si bien SRE es anterior al desarrollo de DevOps, generalmente se considera que están relacionados entre sí.

DevSecOps es un aumento de DevOps para permitir que las prácticas de seguridad se integren en el enfoque de DevOps. El modelo tradicional de equipo de seguridad centralizado debe adoptar un modelo federado que permita a cada equipo de entrega la capacidad de tener en cuenta los controles de seguridad correctos en sus prácticas de DevOps. Cambiar la seguridad a la izquierda es un enfoque de la seguridad del software mediante el cual las prácticas y las pruebas de seguridad se realizan en una etapa más temprana del ciclo de vida del desarrollo.

BizOps se contrasta con DevOps debido a su enfoque más integrado. Si bien DevOps se centra más en el desarrollo de software y TI, BizOps integra la tecnología en las decisiones organizativas diarias y las operaciones comerciales.

Las iniciativas de DevOps pueden crear cambios culturales en las empresas [17] al transformar la forma en que las operaciones , los desarrolladores y los evaluadores colaboran durante los procesos de desarrollo y entrega. [1] Lograr que estos grupos funcionen de manera coherente es un desafío crítico en la adopción de DevOps empresarial. [18] [19] DevOps tiene que ver tanto con la cultura como con la cadena de herramientas.

La cultura organizacional es un fuerte predictor del desempeño organizacional y de TI. Las prácticas culturales como el flujo de información, la colaboración, las responsabilidades compartidas, el aprendizaje de las fallas y las nuevas ideas son fundamentales para DevOps. La formación de equipos y otras actividades de participación de los empleados se utilizan a menudo para crear un entorno que fomente esta comunicación y el cambio cultural dentro de una organización. DevOps como enfoque de servicio permite a los desarrolladores y equipos de operaciones tomar un mayor control de sus aplicaciones e infraestructura sin obstaculizar la velocidad. También transfiere la responsabilidad de ser dueño de un problema al equipo de desarrollo, lo que los hace mucho más cuidadosos en su paso.

El Informe del estado de DevOps de 2015 descubrió que las siete medidas principales con la correlación más fuerte con la cultura organizacional son:

1. Inversión organizativa
2. Experiencia y eficacia de los jefes de equipo
3. Entrega continua
4. La capacidad de diferentes disciplinas (desarrollo, operaciones y seguridad de la información) para lograr resultados beneficiosos para todos.
5. Desempeño organizacional
6. Dolor de despliegue
7. Prácticas de gestión ajustada

Las empresas con lanzamientos muy frecuentes pueden requerir conocimientos sobre DevOps. [ cita requerida ] Por ejemplo, la empresa que opera el sitio web de alojamiento de imágenes Flickr desarrolló un enfoque DevOps para respaldar diez implementaciones al día. Los ciclos de implementación diarios serían mucho más altos en las organizaciones que producen aplicaciones multifunción o de enfoque múltiple. [ cita requerida ] La implementación diaria se conoce como implementación continua

Para practicar DevOps de manera efectiva, las aplicaciones de software deben cumplir con un conjunto de requisitos arquitectónicamente significativos (ASR), tales como: implementabilidad, modificabilidad, capacidad de prueba y capacidad de monitoreo.

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. El servicio de tamaño pequeño permite que surja la arquitectura de un servicio individual a través de una refactorización continua.

La automatización es un principio clave para acelerar con DevOps [22] , que acelera la implementación de DevOps y reduce los conflictos entre equipos [Cornell University 1] . También es compatible con la coherencia, la confiabilidad y la eficiencia dentro de la organización y, por lo general, se habilita mediante un repositorio de código compartido o control de versiones. Como hipotetiza el investigador de DevOps, Ravi Teja Yarlagadda, “A través de DevOps, se asume que todas las funciones pueden llevarse a cabo, controlarse y administrarse en un lugar central utilizando un código simple”.

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 documento DevOps: desarrollo de una cadena de herramientas en el dominio bancario señala que con equipos de desarrolladores que trabajan en el mismo proyecto, “todos los desarrolladores deben realizar cambios en la misma base de código y, a veces, editar incluso los mismos archivos. Para un trabajo eficiente, es necesario ser un sistema que ayude a los ingenieros a evitar conflictos y retener el historial de la base de código ”, [24] con el sistema de control de versiones Git y la plataforma GitHub como ejemplos.

Dado que DevOps abarca todas las partes del desarrollo de aplicaciones, los equipos confían en diferentes herramientas de automatización de DevOps para agilizar el trabajo en las diferentes etapas de creación y entrega de software. Este proceso de extremo a extremo se denomina ciclo de vida de desarrollo de sistemas o software DevOps (SDLC) y, a menudo, se divide en cuatro “pasos” o “fases” distintos: Idea, Construcción, Envío y Aprendizaje.

1. Idea

Los equipos recopilan los requisitos y comentarios de la aplicación, el alcance de los recursos y luego determinan los cronogramas del proyecto. Herramientas de automatización que se utilizan habitualmente: Seguimiento y planificación de la gestión de proyectos.

2. Construir

Los desarrolladores comienzan a crear el código de la aplicación o a introducir cambios en una base de código preexistente, luego lo revisan, prueban y preparan para la implementación. Herramientas de automatización que se utilizan habitualmente: control de versiones, entornos de desarrollo integrados (IDE) y CI / CD.

3. Entregar

Los equipos de operaciones de TI implementan cambios de código en un entorno de producción, haciendo que el software esté disponible públicamente para clientes y usuarios. Herramientas de automatización que se utilizan normalmente: CI / CD para canalizaciones de implementación y administradores de paquetes.

4. Aprender

Los equipos de operaciones analizan el rendimiento del software en busca de estabilidad y tiempo de actividad, recopilan comentarios de los clientes y colaboran con los desarrolladores para realizar mejoras adicionales. Herramientas de automatización que se utilizan habitualmente: Observabilidad y supervisión para medir el rendimiento y el impacto del código.

Las prácticas de DevOps y sus dependencias incluyen una red de dependencia que conecta los beneficios potenciales a una cadena ordenada de prácticas. Usando esta red, las organizaciones pueden elegir un camino que les permita alcanzar sus objetivos.

La adopción de DevOps está impulsada por muchos factores, que incluyen:

1. Uso de procesos y métodos de desarrollo ágiles y de otro tipo ;
2. Demanda de una mayor tasa de lanzamientos de producción, por parte de las partes interesadas de la aplicación y la unidad de negocio ;
3. Amplia disponibilidad de infraestructura virtualizada y en la nube , de proveedores internos y externos;
4. Mayor uso de herramientas de gestión de configuración y automatización del centro de datos ;
5. Mayor enfoque en la automatización de pruebas y los métodos de integración continua ;
6. Una masa crítica de mejores prácticas disponibles públicamente.