DevOps

menu icon

DevOps

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

¿Qué es DevOps?

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 mayor 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 contribuciones de todos los stakeholders de la aplicación, incluyendo ingeniería 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 del desarrollo.

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 gigante a nivel de toda la aplicación cada varios meses o incluso años, hasta lanzamientos de recursos iterativos más pequeños o actualizaciones funcionales cada día o varias veces al día.

Finalmente, DevOps se trata de satisfacer la demanda cada vez mayor de los usuarios de software de nuevas y frecuentes características innovadoras, además de rendimiento y disponibilidad ininterrumpidas.

Cómo hemos llegado a DevOps

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, la metodología principal era la integración continua 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.

Mientras más eficaces eran estas prácticas de desarrollo ágiles para acelerar el desarrollo y la entrega de software, más exponían las operaciones de TI todavía aisladas, como el suministro del sistema, la configuración, las pruebas de aceptación, la gestión y la supervisión, como el siguiente cuello de botella en el ciclo 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.

Cómo funciona DevOps: el ciclo de vida de DevOps

Gráfico que muestra el ciclo de vida de DevOps

Figura 1: El ciclo de vida de DevOps

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 creación o integración continua 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 (generalmente llamada implementación continua). Aquí el resultado de la creación del tiempo de ejecución (de la integración) se implementa en un entorno de ejecución, usualmente un entorno de desarrollo donde se implementan pruebas de tiempo de ejecución 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 llevar las características a un entorno de producción se caracteriza como el "Día 1", una vez que las características se ejecutan en la 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 aseguran que las características se ejecutan sin problemas y que no hay interrupciones en el servicio, ¡cerciorándose de que la red, el almacenamiento, la plataforma, la computación y la seguridad están en su máximo funcionamiento! 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 (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 conformidad) y el aprendizaje (pruebas A/B). 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: mientras que las metodologías en cascada y las implementaciones ágiles "añaden" 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 (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: el cumplimiento normativo (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.

Cultura DevOps

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 de organización, DevOps requiere comunicación continua, colaboración y responsabilidad compartida entre todos los involucrados en la entrega de software, desarrollo de software y equipos de operaciones de TI, pero también seguridad, conformidad, gestión, riesgo y equipos de línea de negocio, para innovar de forma rápida y continua, además de añadir calidad en el software desde el principio.

En la mayoría de los casos, la mejor manera de lograrlo es descomponer estos silos y reorganizarlos en equipos de DevOps autónomos e interfuncionales que pueden trabajar en proyectos de código de principio a fin, desde la planificación hasta la retroalimentación, sin hacer transferencias o 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 en el producto que tiene un resultado valioso.

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

Herramientas DevOps: creación de una cadena de herramientas DevOps

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 de 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 de código fuente de colaboración: entornos de codificación controlados por ediciones 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, 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 están 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.
  • Marcos 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 configuración (infraestructura como código): permiten a los ingenieros de DevOps configurar y suministrar una infraestructura basada en la edición 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 aplicaciones contenedorizadas (vea "DevOps y el desarrollo nativo en la nube" más abajo).
  • Herramientas de supervisión: 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.

DevOps y el desarrollo nativo en la nube

Nativo de 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

  • se desarrollan usando microservicios, componentes ligeramente relacionados entre sí que se implementan de forma independiente y que tienen su propio lote autocontenido, y se comunican entre sí a través de las API REST, el streaming de eventos o los message brokers.
  • Se implementan en contenedores, unidades ejecutables de código que contienen todas las dependencias de código, tiempos de ejecución y sistema operativo necesarias para ejecutar la aplicación. (Para la mayoría de las empresas, "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 contenedorizadas.

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

Por ejemplo, desarrollar y actualizar microservicios, es decir, la entrega continua de unidades pequeñas de código a una base de código pequeña, es la combinación ideal para los ciclos de gestión y lanzamiento rápidos 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 encontró 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 que el 56 % de los encuestados que no son usuarios probablemente adoptarán microservicios dentro de los próximos dos años. Para conocer algunos de los beneficios y desafíos específicos de los microservicios que citaron, utilice la siguiente herramienta interactiva:

(Fuente: 'Microservicios en la empresa en 2021: beneficios reales que justifican los retos').

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.

Los principales proveedores de computación en la nube, incluyendo AWS, Google, Microsoft Azure e IBM Cloud, ofrecen algún tipo de solución gestionada de línea de trabajo de DevOps.

¿Qué es DevSecOps?

DevSecOps es DevOps que integra y automatiza continuamente la seguridad en todo el ciclo de vida de DevOps, de principio a fin, desde la planificación hasta la retroalimentación y de vuelta 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 acerca de los principios, los beneficios y los casos de uso de DevSecOps:

DevOps e ingeniería de confiabilidad del sitio (SRE)

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

El objetivo final de la SRE es similar al objetivo de DevOps, pero más específico: La SRE busca equilibrar el deseo de una organización de tener un desarrollo rápido 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 determinando un nivel aceptable de riesgo operacional causado por las aplicaciones, denominado "margen de error", y automatizando las operaciones para llegar a 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

DevOps e IBM Cloud

DevOps requiere colaboración entre las personas involucradas en la empresa, el desarrollo y las operaciones para entregar y ejecutar software confiable de forma expedita. Las organizaciones que utilizan las herramientas y las prácticas de DevOps al mismo tiempo que transforman su cultura crean una base poderosa para la transformación digital y para modernizar sus aplicaciones a medida que la necesidad de automatización crece en las operaciones empresariales y de TI.

El cambio hacia una mayor automatización debe comenzar con pequeños proyectos exitosos, que luego puede escalar y optimizar para otros procesos y en otras partes de su empresa.

Al trabajar con IBM, tendrá acceso a funciones de automatización basadas en IA, incluyendo flujos de trabajo preintegrados, para hacer que cada proceso de los servicios de TI sea más inteligente, lo que permitirá a los equipos centrarse en los problemas de TI más importantes y acelerar la innovación.

Dé el siguiente paso:

Empiece hoy mismo a usar una cuenta de IBM Cloud.

IBM Cloud Pak for Watson AIOps utiliza el machine learning y la comprensión del lenguaje natural para correlacionar datos estructurados y no estructurados en toda la cadena de herramientas de sus operaciones en tiempo real para descubrir insights ocultos y ayudar a identificar las causas más rápidamente. Al eliminar la necesidad de múltiples paneles de control, Watson AIOps introduce información y recomendaciones directamente en los flujos de trabajo de su equipo para acelerar la resolución de incidentes.

Acerca del Autor

Andrea C. Crawford es una ingeniera distinguida en IBM con experiencia en DevOps clásico y moderno. Le apasiona ayudar a los clientes a transformar su entrega de aplicaciones a través de la modernización del personal, los procesos y las herramientas. Andrea disfruta de pasatiempos "atípicos" como la jardinería y las motocicletas.

https://twitter.com/acmthinks (enlace externo a IBM)

https://medium.com/@acmThinks (enlace externo a IBM)