DevOps acelera la entrega de software de alta calidad combinando y automatizando el trabajo de los equipos de desarrollo de software y de operaciones de TI.

Por definición, DevOps describe un proceso de desarrollo de software y un cambio de cultura de la organización que acelera la entrega de software de alta calidad mediante la automatización y la integración de las tareas de los equipos de desarrollo y operaciones de TI, dos grupos que tradicionalmente operan por separado o en silos.

En la práctica, los mejores procesos y culturas de DevOps no se limitan al desarrollo y las operaciones, e incorporan entradas de todas las partes interesadas de la aplicación (como diseño de plataforma e infraestructura, seguridad, conformidad, gobierno, gestión de riesgos, línea de negocio, usuarios finales y clientes) en el ciclo de vida de desarrollo de software. 

DevOps representa el estado actual de la evolución de los ciclos de entrega de software en los últimos 20 años, desde releases de código gigantes en toda la aplicación cada varios meses o incluso años, hasta una característica iterativa más pequeña o actualizaciones funcionales publicadas cada día o varias veces al día.

En última instancia, DevOps intenta satisfacer la demanda cada vez mayor de los usuarios de software de características nuevas, frecuentes e innovadoras, y de rendimiento y disponibilidad sin interrupciones.

Hasta justo antes del año 2000, la mayoría del software se desarrollaba y actualizaba utilizando la metodología de cascada, un enfoque lineal para proyectos de desarrollo a gran escala. Los equipos de desarrollo de software dedicaban meses a desarrollar grandes cuerpos de código nuevo que se aplicaba a gran parte o a toda la aplicación. Como los cambios eran tan extensos, tenían que dedicar varios meses más a integrar ese nuevo código en la base de código. 

A continuación, los equipos de control de calidad (QA), seguridad y operaciones dedicaban aún más meses a probar el código. El resultado eran meses o incluso años entre releases de software, y a menudo también varios parches significativos o arreglos de errores entre releases. Este enfoque de "big bang" aplicado a la entrega de características a menudo se caracterizaba por planes de despliegue complejos y arriesgados, engranajes difíciles de programar de sistemas en sentido ascendente y descendente, y la "gran esperanza" de TI de que los requisitos empresariales no cambiarían drásticamente en los meses previos a la entrada en producción.

Para acelerar el desarrollo y mejorar la calidad, los equipos de desarrollo empezaron a adoptar metodologías de desarrollo de software ágiles, que son iterativas en lugar de lineales y se centran en realizar actualizaciones más pequeñas y frecuentes en la base de código de aplicación. Las más importantes de estas metodologías son la integración continua y la entrega continua o CI/CD. En CI/CD, los fragmentos más pequeños de código nuevo se fusionan en la base de código cada una o dos semanas y, a continuación, se integran, se prueban y se preparan automáticamente para el despliegue en el entorno de producción. La metodología ágil cambió el enfoque de "big bang" a una serie de "instantáneas más pequeñas" que también compartimentaban los riesgos.

Cuanto mejor aceleraban el desarrollo y la entrega de software estas prácticas de desarrollo ágiles, más exponían las operaciones de TI que continuaban en silos (suministro del sistema, configuración, pruebas de aceptación, gestión, supervisión) como el siguiente cuello de botella del ciclo de vida de entrega de software. 

DevOps creció gracias a una metodología ágil. Ha añadido 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 entrega de software. También implementó una estrecha colaboración entre los equipos de desarrollo y operaciones en cada paso del proceso.

El ciclo de vida de DevOps (también denominado conducto de entrega continua, cuando se describe de forma lineal) es una serie de procesos de desarrollo automatizados e iterativos, o flujos de trabajo, que se ejecutan en un ciclo de vida de desarrollo más grande, automatizado e iterativo, diseñado para optimizar la entrega rápida de software de alta calidad. El nombre y el número de los flujos de trabajo pueden variar 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 definen las nuevas características y la funcionalidad en el próximo release, a partir de estudios de casos y comentarios de usuario final priorizados, así como entradas de todas las partes interesadas internas. El objetivo en la etapa de planificación es maximizar el valor de negocio del producto generando un backlog de características que cuando se entregan producen un resultado deseado de valor añadido.
  
  
• Desarrollo. Este es el paso de programación, donde los desarrolladores prueban, codifican y crean características nuevas y mejoradas, basadas en casos de usuario y elementos de trabajo de los procesos pendientes. Es común una combinación de prácticas como, por ejemplo, el desarrollo controlado por pruebas (TDD), la programación de pares y las revisiones de código de igual, entre otras. 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 el canal de entrega continua.
  
  
• Integración (o compilación, o integración continua y entrega continua [CI/CD]). Como se ha indicado anteriormente, en este flujo de trabajo, el nuevo código se integra en la base de código existente y después se prueba y empaqueta en un ejecutable para el despliegue. Las actividades de automatización comunes incluyen la fusión de cambios de código en una copia "maestra", la comprobación del código de un repositorio de código fuente, y la automatización de la compilación, la prueba de unidad y el empaquetado en un ejecutable. La mejor práctica es almacenar la salida de la fase CI en un repositorio binario para la siguiente fase.
  
  
• Despliegue (normalmente denominado despliegue continuo). Aquí la salida de compilación de tiempo de ejecución (desde la integración) se despliega en un entorno de ejecución, normalmente un entorno de desarrollo donde se ejecutan pruebas de tiempo de ejecución relacionadas con la calidad, la conformidad y la seguridad. Si se encuentran errores o defectos, los desarrolladores tienen la oportunidad de interceptar y remediar cualquier problema antes de que los usuarios finales los vean. Normalmente, existen entornos para el desarrollo, la prueba y la producción, donde cada entorno requiere puertas de calidad progresivamente "más estrictas". Una práctica recomendada para el despliegue en un entorno de producción suele ser realizar el despliegue primero en un subconjunto de usuarios finales y, finalmente, en todos los usuarios una vez establecida la estabilidad.
  
  
• Operaciones. Si entregar las características a un entorno de producción se caracteriza como "Día 1", 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 puedan proporcionar un valor añadido a los usuarios finales. El flujo de trabajo Operaciones garantiza que las características se ejecuten sin problemas y que no haya interrupciones en el servicio; para ello, verifica que los estados de red, almacenamiento, plataforma, cálculo y seguridad sean todos correctos. Si algo no es correcto, el flujo de trabajo Operaciones se encarga de que se identifiquen las incidencias, se avise al personal adecuado, se determinen los problemas y se apliquen los arreglos.
  
  
• Aprendizaje (también denominado Comentarios continuos). Es la recopilación de comentarios de usuarios finales y clientes sobre características, funcionalidad, rendimiento y valor de negocio, para volver a la planificación de las mejoras y las características del próximo release. También incluirá cualquier elemento de aprendizaje y backlog de las actividades de operaciones que permita a los desarrolladores evitar de forma proactiva cualquier incidente pasado, para que no vuelva a producirse en el futuro. Este es el punto en el que se produce la "vuelta cíclica" a la fase de planificación para "continuar con la mejora".

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

Pruebas continuas: los ciclos de vida de DevOps clásicos incluyen una fase de "prueba" distinta que se produce entre la integración y el despliegue. No obstante, DevOps ha avanzado de tal manera que determinados elementos de la prueba pueden producirse en la planificación (desarrollo basado en el comportamiento), el desarrollo (pruebas de unidad, pruebas de contrato), la integración (escaneos de código estático, exploraciones de CVE, residuos), el despliegue (pruebas de humo, pruebas de penetración, pruebas de configuración), las operaciones (pruebas de caos, pruebas de conformidad) y el aprendizaje (pruebas A/B). Las pruebas son una buena forma de identificar riesgos y vulnerabilidades, y proporcionan una oportunidad para que el equipo de TI los acepte, mitigue o solucione.

Seguridad: mientras las metodologías de cascada y las implementaciones ágiles se "añaden" a los flujos de trabajo de seguridad después de la entrega o el despliegue, DevOps intenta incorporar la seguridad desde el principio (Planificación), cuando los problemas de seguridad son más fáciles y menos costosos de abordar, y de manera continua durante el resto del ciclo de desarrollo. Este enfoque de seguridad se conoce como desplazamiento a la izquierda (es más fácil de entender si consulta la Figura 1). Algunas organizaciones han tenido menos éxito al desplazarse a la izquierda que otras, lo que condujo al auge de DevSecOps (véase más abajo).

Conformidad: la conformidad normativa (gobierno y riesgo) también se aborda mejor en las primeras etapas y durante todo el ciclo de vida de desarrollo. Las industrias más reguladas a menudo se ven obligadas a proporcionar un determinado nivel de observabilidad, trazabilidad y acceso de cómo se entregan y gestionan las características en su entorno operativo de tiempo de ejecución. Esto requiere una planificación, un desarrollo, unas pruebas y una aplicación de políticas en el canal de entrega continua y en el entorno de ejecución. La auditabilidad de las medidas de conformidad es extremadamente importante para demostrar la conformidad a los auditores de terceros.

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

A nivel de organización, DevOps requiere una comunicación continua, una colaboración y una responsabilidad compartida entre todas las partes interesadas en la entrega de software (equipos de desarrollo de software y operaciones de TI, pero también equipos de seguridad, conformidad, gobierno, riesgo y línea de negocio) para innovar de forma rápida y continua, y aumentar la calidad del software desde el principio.

En la mayoría de los casos, la mejor manera de lograrlo es romper estos silos y reorganizarlos en equipos de DevOps autónomos y multidisciplinares que pueden trabajar en proyectos de código de principio a fin, es decir, de la planificación a los comentarios, sin hacer traspasos ni esperar aprobaciones de otros equipos. Cuando se pone en el contexto del desarrollo ágil, la responsabilidad compartida y la colaboración son la base para tener un foco de producto compartido con un resultado valioso.

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

Las demandas de DevOps y la cultura de DevOps han dado valor a las herramientas que dan soporte a la colaboración asíncrona, integran sin interrupciones los flujos de trabajo de DevOps y automatizan el ciclo de vida completo de DevOps al máximo. Las categorías de herramientas de DevOps incluyen:

• Herramientas de gestión de proyectos: son herramientas que permiten a los equipos crear un backlog de casos de usuario (requisitos) que forman proyectos de codificación, los desglosan en tareas más pequeñas y realizan un seguimiento de las tareas hasta su finalización. Muchas dan soporte a prácticas ágiles de gestión de proyectos como, por ejemplo, Scrum, Lean y Kanban, que los desarrolladores aportan a DevOps. Las opciones de código abierto más conocidas incluyen GitHub Issues y Jira.
  
  
• Repositorios de código fuente de colaboración: entornos de codificación de versión controlada que permiten a varios desarrolladores trabajar en la misma base de código. Los repositorios de código deben integrarse con CI/CD, pruebas y herramientas de seguridad, para que cuando el código se comprometa en el repositorio, se pueda cambiar automáticamente al siguiente paso. Los repositorios de código abierto incluyen GiHub y GitLab.
  
  
• Conductos CI/CD: herramientas que automatizan la extracción de código, la compilación, las pruebas y el despliegue. Jenkins es la herramienta de código abierto más conocida en esta categoría; muchas alternativas de código abierto anteriores, como CircleCI, ahora están disponibles solo en versiones comerciales. Cuando se trata de herramientas de despliegue continuo (CD), Spinnaker se encuentra entre la aplicación y la infraestructura como capas de código. ArgoCD es otra opción de código abierto conocida para el CI/CD nativo de Kubernetes.
  
  
• Infraestructuras 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 de estas herramientas dan soporte a varios lenguajes; algunas utilizan la inteligencia artificial (IA) para reconfigurar automáticamente las pruebas como respuesta a los cambios de código. La extensión de las herramientas de prueba y las infraestructuras es muy amplia. Las infraestructuras de automatización de pruebas de código abierto más conocidas incluyen Selenium, Appium, Katalon, Robot Framework y Serenity (anteriormente conocido como Thucydides).
  
  
• Herramientas de gestión de configuración (infraestructura como código): permiten a los ingenieros de DevOps configurar y suministrar una infraestructura totalmente versionada y plenamente documentada ejecutando un script. Las opciones de código abierto incluyen Ansible (Red Hat), Chef, Puppet y Terraform. Kubernetes realiza la misma función para las aplicaciones contenerizadas (consulte "DevOps y desarrollo nativo en cloud" a continuación).
  
  
• Herramientas de supervisión: permiten a los equipos de DevOps identificar y resolver problemas del sistema; también recopilan y analizan datos en tiempo real para revelar cómo el código cambia el rendimiento de la aplicación de impacto. Las herramientas de supervisión de código abierto incluyen Datadog, Nagios, Prometheus y Splunk.
  
  
• Herramientas de comentarios continuos: herramientas que recopilan comentarios de los usuarios, ya sea mediante mapas de calor (que graban las acciones de los usuarios en la pantalla), encuestas o notificación de problemas de autoservicio.

Nativo en cloud es un enfoque para crear aplicaciones que aprovechan las tecnologías de cloud computing fundacionales. El objetivo del enfoque nativo en cloud es permitir un desarrollo, un despliegue, una gestión y un rendimiento de aplicaciones que sean coherentes y óptimos en entornos públicos, privados y multicloud. 

Hoy en día, las aplicaciones nativas en cloud normalmente:

• Se crean utilizando microservicios, que son componentes desplegables de forma independiente y de acoplamiento ligero, que tienen su propia pila autocontenida y se comunican entre sí a través de API REST, la transmisión de sucesos o intermediarios de mensajes.
  
  
• Se despliegan en contenedores, que son unidades ejecutables de código que contienen todas las dependencias de código, tiempo de ejecución y sistema operativo necesarias para ejecutar la aplicación (para la mayoría de las organizaciones, "contenedores" es sinónimo de contenedores de Docker, pero también existen otros tipos de contenedor).
  
  
• Se manejan (a escala) utilizando Kubernetes, una plataforma de orquestación de contenedores de código abierto para planificar y automatizar el despliegue, la gestión y el escalado de aplicaciones contenerizadas.

En muchos sentidos, el desarrollo nativo en cloud y DevOps están creados el uno para el otro. 

Por ejemplo, el desarrollo y la actualización de microservicios, es decir, la entrega iterativa de pequeñas unidades de código a una base de código pequeña, es la combinación perfecta para los ciclos de gestión y release rápido de DevOps. Sería difícil lidiar con la complejidad de una arquitectura de microservicios sin el despliegue y la operación de DevOps. Una reciente encuesta de IBM a desarrolladores y ejecutivos de TI determinó que el 78 % de los usuarios actuales de microservicios esperan aumentar el tiempo, el dinero y el esfuerzo que han invertido en la arquitectura, y el 56 % de los no usuarios probablemente 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 despliegue y CI/CD rápidos, ya que toda la integración, las pruebas y el despliegue se producen en el mismo entorno. La orquestación de Kubernetes realiza las mismas tareas de configuración continua para aplicaciones contenerizadas que Ansible, Puppet y Chef realizan para las aplicaciones no contenerizadas.

Los principales proveedores de cloud computing, como por ejemplo AWS, Google, Microsoft Azure e IBM Cloud, ofrecen algún tipo de solución de conducto de DevOps gestionada.

DevSecOps es un entorno DevOps que integra y automatiza continuamente la seguridad en todo el ciclo de vida de DevOps, de principio a fin, desde la planificación a los comentarios, volviendo de nuevo a la planificación.

Otra forma de describirlo es que DevSecOps es lo que DevOps debería haber sido desde el principio. No obstante, dos de los retos más importantes (y durante un tiempo insuperables) de la adopción de DevOps fueron la integración de la experiencia de 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 percibirse como el "Equipo negativo" y como un costoso cuello de botella en muchas prácticas de DevOps.

DevSecOps surgió como una iniciativa específica para integrar y automatizar la seguridad como se pretendía originalmente. En DevSecOps, la seguridad es una parte interesada y un "ciudadano de primera" junto con el desarrollo y las operaciones, y aporta seguridad al proceso de desarrollo con un enfoque de producto.

Vea "¿Qué es DevSecOps?" para obtener más información sobre los principios, las ventajas y los casos de uso de DevSecOps:

La ingeniería de fiabilidad del sitio (SRE) utiliza técnicas de ingeniería de software para automatizar las tareas de las operaciones de TI, por ejemplo, la gestión de sistemas de producción, la gestión de cambios, la respuesta a incidencias e incluso la respuesta a emergencias, que de otro modo debían realizar manualmente los administradores de sistemas. SRE busca transformar al administrador del sistema clásico en un ingeniero.

El objetivo final de SRE es similar al objetivo de DevOps, pero más específico: SRE intenta equilibrar el deseo de una organización de un desarrollo rápido de aplicaciones con su necesidad de cumplir los niveles de rendimiento y disponibilidad especificados en los acuerdos de nivel de servicio (SLA) con clientes y usuarios finales. 

Los ingenieros de fiabilidad del sitio logran este equilibrio determinando un nivel aceptable de riesgo operativo debido a las aplicaciones, denominado "presupuesto de error", y automatizando las operaciones para llegar a ese nivel. 

En un equipo de DevOps multifuncional, la SRE puede servir como puente entre el desarrollo y las operaciones, al proporcionar las métricas y la automatización que el equipo necesita para impulsar cambios de código y nuevas funciones a través del canal DevOps lo más rápido posible, sin "incumplir" los términos de los SLA de las organizaciones. 

Más información sobre la ingeniería de fiabilidad del sitio