Hasta justo antes del año 2000, la mayoría del software era desarrollado y actualizado usando la metodología en cascada, un enfoque lineal para proyectos de desarrollo a gran escala. Los equipos de desarrollo de software  pasaban meses desarrollando grandes cantidades de código nuevo que impactaba la mayoría o la totalidad de la aplicación. Debido a que los cambios eran tan extensos, se demoraban varios meses más en integrar ese nuevo código en el código base. 

Posteriormente, los equipos de garantía de calidad (QA), seguridad y operaciones pasaban otros meses más probando el código. El resultado era meses o incluso años entre lanzamientos de software, y a menudo varios parches significativos o correcciones de errores entre lanzamientos también. Y este enfoque de "big bang" de la entrega de aplicaciones a menudo se caracterizaba por planes de implementación complejos y arriesgados, interbloqueos difíciles de programar con sistemas en sentido ascendente y descendente, y la "gran esperanza" de TI de que los requisitos empresariales no hubieran cambiado drásticamente en los meses previos a la producción.

Para acelerar el desarrollo y mejorar la calidad, los equipos de desarrollo comenzaron a adoptar metodologías de desarrollo de software ágiles, que eran iterativas en lugar de lineales y se centraban en realizar actualizaciones más pequeñas y frecuentes al código base de la aplicación. Entre ellas, las principales metodologías son la integración  y la  entrega continua o CI/CD. En CI/CD, fragmentos más pequeños de código nuevo se fusionan en el código base cada una o dos semanas y luego se integran, prueban y preparan automáticamente para su implementación en el entorno de producción. Las metodologías ágiles evolucionaron el enfoque de "big bang" en una serie de "copias más pequeñas" que también compartimentaban los riesgos.

Cuanto más eficazmente estas prácticas de desarrollo ágiles hayan acelerado el desarrollo y la entrega de software, más hicieron que las operaciones de TI más aisladas (entre ellas: el aprovisionamiento de sistemas, configuración, pruebas de aceptación, administración, monitoreo) fueran consideradas como el próximo cuello de botella en el ciclo de vida de la entrega de software. 

Así que DevOps se separó de las metodologías ágiles. Añadió nuevos procesos y herramientas que amplían la iteración continua y la automatización de CI/CD al resto del ciclo de vida de la entrega de software. E implementó una estrecha colaboración entre el desarrollo y las operaciones en cada etapa del proceso.

El ciclo de vida de DevOps (a veces denominado línea de trabajo de entrega continua, cuando se describe de forma lineal) es una serie de procesos (o "flujos de trabajo"), de desarrollo automatizados e iterativos que se ejecutan dentro de un ciclo de vida de desarrollo más grande, automatizado e iterativo diseñado para optimizar la rápida entrega de software de alta calidad. El nombre y el número de los flujos de trabajo pueden diferir dependiendo de a quién se pregunte, pero normalmente se reducen a estos seis:

• Planificación (o ideación). En este flujo de trabajo, los equipos determinan las nuevas características y funcionalidades del próximo lanzamiento, a partir de comentarios y casos de estudio de usuarios finales priorizados, así como contribuciones de todos los stakeholders internos. El objetivo en la etapa de planificación es maximizar el valor empresarial del producto creando una lista de características que, incluidas en la entrega, producen el resultado deseado que tiene valor.
• Desarrollo. Esta es la etapa de la programación, donde los desarrolladores prueban, codifican y crean características nuevas y mejoradas, basadas en comentarios de los usuarios y elementos de trabajo en la lista. La combinación de prácticas como, por ejemplo, el desarrollo controlado por pruebas (TDD), la programación en pareja y las revisiones de código por expertos, entre otras, es común. Los desarrolladores suelen utilizar sus estaciones de trabajo locales para realizar el "bucle interno" de escritura y prueba de código antes de enviarlo por la línea de trabajo de entrega continua.
• Integración (o construcción, o Integración y entrega continua (CI / CD). Como se indicó anteriormente, en este flujo de trabajo el nuevo código se integra en el código base existente, luego se prueba y se empaqueta en un ejecutable para su implementación. Las actividades de automatización comunes incluyen fusionar cambios de código en una copia "maestra", comprobar dicho código de un repositorio de código fuente y automatizar la compilación, la prueba de unidad y el empaquetado en un ejecutable. La mejor práctica es almacenar el resultado de la fase CI en un repositorio binario para la siguiente fase.
• Despliegue (normalmente llamadodespliegue continuo ). Aquí, el resultado de la compilación en tiempo de ejecución (integración) se implementa en un entorno de tiempo de ejecución, generalmente un entorno de desarrollo donde se llevan a cabo pruebas de tiempo de para la calidad, el cumplimiento y la seguridad. Si se encuentran errores o defectos, los desarrolladores tienen la oportunidad de interceptar y solucionar cualquier problema antes de que los usuarios finales los vean. Por lo general existen entornos para el desarrollo, la prueba y la producción, donde cada uno requiere etapas de calidad progresivamente "más estrictas". Una buena práctica para la implementación en un entorno de producción suele ser implementar primero para un subconjunto de usuarios finales y posteriormente para todos los usuarios una vez que se asegura la estabilidad.
• Operaciones. Si la entrega de funciones a un entorno de producción se clasifica como "Día 1",  luego, una vez que las características se ejecutan en producción, se producen las operaciones del "Día 2". La supervisión del rendimiento, el comportamiento y la disponibilidad de las características garantiza que estas sean capaces de proporcionar valor añadido a los usuarios finales. Las operaciones garantizan que las funciones funcionen sin problemas y que no haya interrupciones en el servicio, ¡asegurándose de que la red, el almacenamiento, la plataforma, la computación y la posición de seguridad estén en buen estado! Si algo sale mal, las operaciones garantizan que se identifican incidentes, se notifica al personal adecuado, se determinan los problemas y se aplican los arreglos.
• Aprendizaje o "Learning" (a veces llamado retroalimentación continua). Esta es la recopilación de comentarios de usuarios finales y clientes acerca de las características, la funcionalidad, el rendimiento y el valor empresarial para volver a la etapa de planificación y añadir tanto mejoras como nuevas características al próximo lanzamiento. Esto también incluye cualquier artículo de aprendizaje y lista de tareas de las operaciones que podría capacitar a los desarrolladores para evitar de forma proactiva cualquier incidente pasado que pueda volver a ocurrir en el futuro. Este es el punto en el que "regresamos" a la etapa de planificación y "¡mejoramos continuamente!"

Entre estos flujos de trabajo se producen otros tres flujos de trabajo continuos importantes:

Pruebas continuas:  Los ciclos de vida tradicionales de DevOps incluyen una etapa de "prueba" discreta que se produce entre la integración y la implementación. Sin embargo, DevOps ha avanzado de tal manera que ciertos elementos de la etapa de prueba pueden ocurrir en la planificación (desarrollo basado en el comportamiento), el desarrollo (pruebas de unidad, pruebas de contrato), la integración (análisis estático de código, escaneo de CVE, herramientas lint), la implementación (pruebas de humo, pruebas de penetración, pruebas de configuración), las operaciones (pruebas de fallos, pruebas de conf Las pruebas son una forma poderosa de identificar riesgos y vulnerabilidades y proporcionan una oportunidad para que la TI los acepte, mitigue o solucione.

Seguridad:  Si bien las metodologías en cascada y las implementaciones ágiles "incorporan" los flujos de trabajo de seguridad después de la entrega o la implementación, DevOps se esfuerza por incorporar la seguridad desde el principio (planificación), cuando los problemas de seguridad son más fáciles y menos costosos de abordar, y continuamente durante el resto del ciclo de desarrollo. Este enfoque de seguridad se conoce como shifting left (o "cambio hacia la izquierda", más fácil de entender observando la Figura 1). Algunas empresas han tenido menos éxito "desplazando a la izquierda" que otras, lo que ha permitido el surgimiento de DevSecOps (ver más abajo).

Conformidad regulatoria. Conformidad Regulatoria  (gestión y riesgo) también se aborda mejor al principio y durante todo el ciclo de vida del desarrollo. Las industrias reguladas a menudo tienen la obligación de proporcionar un cierto nivel de observabilidad, trazabilidad y acceso de cómo se entregan y gestionan los recursos en su entorno de operaciones de tiempo de ejecución. Esto requiere planificación, desarrollo, pruebas y aplicación de políticas en la línea de trabajo de entrega continua y en el entorno de ejecución. La auditabilidad de las medidas de conformidad es extremadamente importante para demostrar el cumplimiento normativo a los auditores externos.

Generalmente se admite que los métodos DevOps no pueden funcionar sin un compromiso con la cultura DevOps, la que se puede resumir como un enfoque organizativo y técnico diferente al desarrollo de software.

A nivel organizacional, DevOps requiere de una comunicación continua, colaboración y responsabilidad compartida entre todos los stakeholders en la entrega de software: desarrollo de software y TI,  equipos de operaciones para ciertos equipos, pero también de seguridad, cumplimiento, gestión, riesgo y línea de negocio, con el fin de innovar rápida y continuamente e incorporar calidad en el software desde el principio.

En la mayoría de los casos, la mejor manera de lograr esto es romper estos silos y reorganizarlos en equipos de DevOps autónomos y multifuncionales que pueden trabajar en proyectos de código de principio a fin, desde la planificación hasta la retroalimentación, sin hacer transferencias ni esperar la aprobación de otros equipos. En el contexto del desarrollo ágil, la responsabilidad compartida y la colaboración son la base de un enfoque compartido de productos con resultados valiosos.

A nivel técnico, DevOps requiere un compromiso con la automatización, que mantiene los proyectos en movimiento dentro y entre los flujos de trabajo, y para la retroalimentación y medición , que permitan a los equipos acelerar ciclos continuamente y mejorar la calidad y el rendimiento del software.

Las demandas de DevOps y la cultura DevOps enfatizan la importancia de las herramientas que apoyan la colaboración asíncrona, integran sin problemas los flujos de trabajo de DevOps y automatizan todo el ciclo de vida de DevOps tanto como sea posible. Las categorías de herramientas DevOps incluyen:

• Herramientas para gestión de proyectos- herramientas que permiten a los equipos crear una lista de casos de usuarios (requisitos) que forman proyectos de codificación, desglosarlos en tareas más pequeñas y realizar un seguimiento de estas hasta su finalización. Muchas admiten prácticas ágiles de gestión de proyectos, como Scrum, Lean y Kanban, que los desarrolladores ocupan con DevOps. Algunas opciones populares de código abierto incluyen GitHub Issues y Jira.
• Repositorios colaborativos de código fuente -  Entornos de codificación controlados por versiones que permiten que varios desarrolladores trabajen en la misma base de código. Los repositorios de código deben integrarse con CI/CD, pruebas y herramientas de seguridad, de modo que cuando el código esté comprometido con el repositorio, pueda avanzar automáticamente a la siguiente etapa. Algunos repositorios de código abierto son GiHub y GitLab.
• Líneas de trabajo CI/CD -herramientas que automatizan la extracción, la creación, la prueba y la implementación de código. Jenkins es la herramienta de código abierto más popular en esta categoría; muchas alternativas que antes eran de código abierto, como CircleCI, ahora disponibles solo en versiones comerciales. Cuando se trata de herramientas de implementación continua (CD), Spinnaker se extiende entre la aplicación y la infraestructura como capas de código. ArgoCD es otra opción popular de código abierto para CI/CD nativo de Kubernetes.
• Frameworks de automatización de pruebas -incluyen herramientas de software, bibliotecas y mejores prácticas para automatizar pruebas de unidad, contrato, funcionalidad, rendimiento, usabilidad, penetración y seguridad. Las mejores herramientas admiten varios lenguajes; algunos utilizan inteligencia artificial (IA) para reconfigurar automáticamente las pruebas en respuesta a los cambios en el código. ¡La extensión de las herramientas de prueba y de los marcos es amplia! Algunos marcos de automatización de pruebas de código abierto populares son Selenium, Appium, Katalon, Robot Framework y Serenity (anteriormente conocido como Thucydides).
• Herramientas de gestión de la configuración (infraestructura como código)  - estos permiten a los ingenieros de DevOps configurar y proporcionar una infraestructura completamente documentada y con versiones completas mediante la ejecución de un script. Algunas opciones de código abierto incluyen Ansible (Red Hat), Chef, Puppet y Terraform. Kubernetes realiza la misma función para aplicaciones contenedorizadas (vea "DevOps y el desarrollo nativo en la nube" más abajo).
• Herramientas de monitoreo -  ayudan a los equipos de DevOps a identificar y resolver problemas del sistema, y también recopilan y analizan datos en tiempo real para descubrir cómo los cambios en el código impactan el rendimiento de la aplicación. Algunas herramientas de supervisión de código abierto son Datadog, Nagios, Prometheus y Splunk.
• Herramientas de retroalimentación continua - herramientas que recopilan comentarios de los usuarios, ya sea a través de mapas de calor (registro de acciones de los usuarios en pantalla), encuestas o autoingreso de tickets de problemas.

Nativo en la nube es un enfoque para crear aplicaciones que aprovechen las tecnologías base de la computación en la nube. El objetivo de lo nativo de la nube es permitir el desarrollo, la implementación, la gestión y el rendimiento de aplicaciones consistentes y óptimos en entornos públicos, privados y de multinube. 

Hoy en día, generalmente las aplicaciones nativas en la nube

• Desarrollado usando microservicios - es decir, con componentes desplegables de forma independiente y acoplados libremente que tienen su propia pila autónoma y se comunican entre sí a través de API REST, transmisión de eventos o intermediarios de mensajes.
• Implementado en contenedores - unidades de código ejecutables que contienen todo el código, los tiempos de ejecución y las dependencias del sistema operativo necesarios para ejecutar la aplicación. (Para la mayoría de las organizaciones, 'contenedores' es sinónimo de contenedores de Estiba,  aunque existan otros tipos de contenedores).
• Se ejecutan (a escala) utilizando Kubernetes , una plataforma de orquestación de contenedores de código abierto para planificar y automatizar la implementación, la gestión y el escalado de aplicaciones contenedorizadas.

De muchas maneras, el desarrollo nativo en la nube y DevOps están hechos el uno para el otro. 

Por ejemplo, al desarrollar  y actualizar microservicios, es decir, la entrega iterativa de pequeñas unidades de código a una base de código pequeña, es un ajuste perfecto para los ciclos rápidos de administración y liberación de DevOps. Y sería difícil lidiar con la complejidad de una arquitectura de microservicios sin la implementación y las operaciones de DevOps. Una encuesta reciente de IBM a desarrolladores y ejecutivos de TI descubrió que el 78% de los usuarios actuales de microservicios consideran aumentar el tiempo, los recursos financieros y el esfuerzo que han invertido en la arquitectura, y es probable que el 56% de los no usuarios adopten microservicios en los próximos dos años. 

Mediante el empaquetado y la solución permanente de todas las dependencias del sistema operativo, los contenedores permiten ciclos de implementación y CI/CD rápidos, ya que toda la integración, las pruebas y la implementación se producen en el mismo entorno. Y la orquestación de Kubernetes realiza las mismas tareas de configuración continua para aplicaciones contenedorizadas como Ansible, Puppet y Chef para aplicaciones no contenedorizadas.

La mayoría de los proveedores líderes de computación en la nube, incluidos AWS, Google, Microsoft Azure e IBM Cloud, ofrecen algún tipo de solución de canalización DevOps administrada.

DevSecOps es DevOps que integra y automatiza continuamente la seguridad a lo largo del ciclo de vida de DevOps, de principio a fin, desde la planificación hasta la retroalimentación y de regreso a la planificación.

Otra manera de explicarlo es que DevSecOps es lo que DevOps debió ser desde el inicio. Pero dos de los desafíos más importantes (y por un tiempo insuperables) de la adopción de DevOps fueron la integración de la experiencia en seguridad en equipos multifuncionales (un problema cultural) y la implementación de la automatización de seguridad en el ciclo de vida de DevOps (un problema técnico). La seguridad llegó a ser percibida como el "equipo de los 'no'" y como un costoso cuello de botella en muchas prácticas de DevOps.

DevSecOps surgió como un esfuerzo específico para integrar y automatizar la seguridad como se pretendía originalmente. En DevSecOps, la seguridad es un ciudadano y stakeholder "de primera clase", junto con el desarrollo y las operaciones,  y aporta seguridad al proceso de desarrollo con un enfoque en el producto.

Vea '¿Qué es DevSecOps?' para obtener más información sobre DevSecOps  principios, beneficios y casos de uso: