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 es un proceso de desarrollo de software y un cambio de la cultura empresarial que acelera la entrega de software de alta calidad mediante la automatización e integración de los esfuerzos de los equipos de desarrollo y operaciones de TI: dos grupos que tradicionalmente trabajan independiente el uno del otro o en silos.

En la práctica, los mejores procesos y culturas de DevOps se extienden más allá del desarrollo y las operaciones para incorporar datos de todos los stakeholders de la aplicación (como diseño de plataforma e infraestructura, seguridad, conformidad, gestión, 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 durante los últimos 20 años, desde lanzamientos 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 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. 

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 era meses o incluso años entre lanzamientos de software, y a menudo varios parches significativos o correcciones de errores entre lanzamientos también. Este enfoque de "big bang" aplicado a la entrega de características a menudo se caracterizaba por planes de implementación 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 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 suministro de sistemas, configuración, pruebas de aceptación, gestión, supervisión) 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. 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 (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 entrega rápida 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 compilació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.
  
  
• Implementación (normalmente llamada implementación continua). 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, la conformidad 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. 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, computación y seguridad sean todos correctos. 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 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 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 desplazamiento a la izquierda (es más fácil de entender si consulta la Figura 1). Algunas empresas han tenido menos éxito "desplazando a la izquierda" que otras, lo que ha permitido el surgimiento de DevSecOps (vea más abajo).

Conformidad regulatoria. La conformidad normativa (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 la conformidad a los auditores de terceros.

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 (equipos de desarrollo de software y operaciones de TI, pero también equipos de seguridad, conformidad, gestión, 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 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: son 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 de código fuente de colaboración: entornos de codificación de versión controlada 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.
  
  
• 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 herramientas admiten varios lenguajes. Algunas 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 configuración (infraestructura como código): permiten a los ingenieros de DevOps configurar y proporcionar una infraestructura totalmente versionada y plenamente documentada ejecutando un script. Algunas opciones de código abierto incluyen Ansible (Red Hat), Chef, Puppet y Terraform. Kubernetes realiza la misma función para las aplicaciones en contenedores (consulte "DevOps y desarrollo nativo en la nube" a continuación).
  
  
• Herramientas de supervisión: permiten 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 aprovechan las tecnologías base de la computación en la nube. El objetivo del enfoque nativo en la nube es permitir un desarrollo, una implementación, una gestión y un rendimiento de aplicaciones consistentes y óptimos en entornos públicos, privados y de multinube. 

Hoy en día, las aplicaciones nativas en la nube normalmente:

• Desarrollado con microservicios: componentes de implementación independiente y poco acoplados que tienen su propia solución autónoma y se comunican entre sí a través de API REST, transmisión de eventos o message broker.
  
  
• 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 Docker, pero existen 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 contenerizadas.

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 de gestión y liberación rápida 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 contenerizadas como Ansible, Puppet y Chef para aplicaciones no contenerizadas.

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 línea de trabajo de DevOps gestionada.

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 negativo" 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 acerca de los principios, los beneficios y los casos de uso de DevSecOps:

La ingeniería de confiabilidad del sitio (SRE) utiliza técnicas de ingeniería de software para automatizar las tareas de operaciones de TI, por ejemplo, gestión del sistema de producción, gestión de cambios, respuesta a incidentes, incluso respuesta a emergencias, que de otra manera los administradores de sistemas podrían realizar manualmente. SRE busca transformar al administrador del sistema tradicional en un ingeniero.

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

Los ingenieros de confiabilidad del sitio logran este equilibrio al determinar un nivel aceptable de riesgo operativo ocasionado por las aplicaciones llamado "presupuesto de error", y al automatizar las operaciones para alcanzar ese nivel. 

En un equipo de DevOps multifuncional, la SRE puede ser un puente entre el desarrollo y las operaciones, ya que proporciona las métricas y la automatización que el equipo necesita para implementar cambios al código y añadir nuevas funciones a través de la línea de trabajo de DevOps lo más rápido posible, sin "incumplir" los términos de los SLA de la empresa. 

Obtenga más información acerca de la ingeniería de confiabilidad del sitio