DevOps es una metodología de desarrollo de software que acelera la entrega de aplicaciones y servicios de mayor calidad combinando y automatizando el trabajo de los equipos de desarrollo de software y operaciones de TI.
Con herramientas y prácticas compartidas, incluidas actualizaciones pequeñas pero frecuentes, el desarrollo de software es más eficiente, rápido y fiable.
Por definición, DevOps, operaciones de desarrollo, esboza tanto un proceso de desarrollo de software como un cambio de cultura organizativa que fomenta la coordinación y la colaboración entre los equipos de desarrollo y operaciones de TI, dos grupos que habitualmente trabajaban por separado o en silos.
En la práctica, los mejores procesos y culturas DevOps van más allá de las prácticas y operaciones de desarrollo para incorporar las aportaciones de todas las partes interesadas en la aplicación al ciclo de vida de desarrollo del software. Esto incluye a los ingenieros de plataformas e infraestructuras, seguridad, conformidad, gobierno, gestión de riesgos y equipos de línea de negocio, usuarios y clientes.
Los principios de DevOps representan el estado actual de la evolución del proceso de entrega de software durante los últimos 20 años o más. El proceso de entrega ha pasado de las gigantescas versiones de código para toda la aplicación cada varios meses o incluso años, a actualizaciones iterativas de características o funciones más pequeñas, publicadas con una frecuencia tan elevada como cada día o varias veces al día.
En última instancia, DevOps trata de satisfacer la demanda cada vez mayor de los usuarios de software de nuevas características frecuentes e innovadoras y un rendimiento y una disponibilidad ininterrumpidos.
Si el software importa, entonces la eficiencia de la entrega de software importa. Lea el informe para saber cómo mejorar la eficiencia general de su ciclo de vida de DevOps.
Regístrese para recibir la guía sobre la nube híbrida
Antes del año 2000, la mayor parte del software se desarrollaba y actualizaba utilizando la metodología de cascada, un enfoque lineal de los proyectos de desarrollo a gran escala. Los equipos de desarrollo de software pasaban meses desarrollando grandes cantidades de código nuevo que afectaban a la mayor parte o a todo el ciclo de vida de la aplicación. Como los cambios eran tan extensos, pasaban varios meses más integrando 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 versiones de software, y a menudo también varios parches o correcciones de errores importantes entre versiones. Este enfoque "big bang" de la entrega de funcionalidades solía caracterizarse por planes de implementación complejos y arriesgados, enclavamientos difíciles de programar con sistemas ascendentes y descendentes, y la gran esperanza de TI de que los requisitos de negocio no hubieran cambiado drásticamente en los meses previos a la puesta en producción o a la versión de disponibilidad general (GA).
Para acelerar el desarrollo y mejorar la calidad, los equipos de desarrollo empezaron a adoptar metodologías desarrollo ágil de software a principios de la década de 2000. Estas metodologías son iterativas en lugar de lineales y se centran en llevar a cabo actualizaciones más pequeñas y frecuentes de la base de código de la aplicación. Entre estas metodologías DevOps destacan la integración continua y la entrega continua (CI/CD).
En CI/CD, trozos más pequeños de código nuevo se incorporan a la base de código a intervalos frecuentes y, a continuación, se integran, prueban y preparan automáticamente para su implementación en el entorno de producción. La metodología ágil modificó el enfoque big bang y lo convirtió en una serie de pequeños pasos, que también compartimentaron los riesgos.
Cuanto más aceleraban estas prácticas de desarrollo ágil el desarrollo y la entrega de software, más exponían a las operaciones de TI aún silenciadas, el aprovisionamiento de sistemas, la configuración, las pruebas de aceptación, la gestión y la monitorización, por ejemplo, como el siguiente cuello de botella en el ciclo de vida de la entrega de software.
Así pues, DevOps surgió de la metodología ágil. 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 desarrollo y operaciones en cada paso del proceso.
El ciclo de vida de DevOps (a veces denominado canalización de entrega continua, cuando se representa de forma lineal) es una serie de procesos de desarrollo iterativos y automatizados, o flujos de trabajo, que se ejecutan dentro de un ciclo de vida de desarrollo más amplio, automatizado e iterativo, diseñado para optimizar la entrega rápida de software de alta calidad. Los nombres y el número de flujos de trabajo varían según a quién se pregunte, pero suelen incluir estos ocho pasos.
En este flujo de trabajo, los equipos analizan las nuevas características y funciones para la próxima versión, basándose en los comentarios de usuarios y los casos de éxito prioritarios, así como en las aportaciones de todas las partes interesadas internas. El objetivo de la fase de planificación es maximizar el valor empresarial del producto mediante la creación de una cartera de características que aumenten el valor del producto.
Se trata de la fase de programación, en la que los desarrolladores programan y crean características nuevas y mejoradas basadas en las historias de usuario y los elementos de trabajo del backlog. Es habitual una combinación de prácticas como el desarrollo basado en pruebas (TDD), la programación en pareja y las revisiones de código por pares. Los desarrolladores suelen utilizar sus estaciones de trabajo locales para realizar el bucle interno de escribir y probar el código antes de enviarlo por la canalización de entrega continua.
En este flujo de trabajo, el nuevo código se integra en la base de código existente y, a continuación, se prueba y empaqueta para su publicación e implementación. Las actividades de automatización habituales incluyen la fusión de los cambios de código en una copia maestra, la comprobación de ese código desde un repositorio de código fuente y la automatización de la compilación, la prueba unitaria y el empaquetado en un archivo ejecutable. Una buena práctica consiste en almacenar el resultado de la fase CI en un repositorio binario para la siguiente fase.
Los equipos utilizan pruebas, a menudo automatizadas, para asegurarse de que la aplicación cumple las normas y los requisitos. El enfoque clásico de DevOps incluye una fase de pruebas discreta que tiene lugar entre la creación y la publicación.
Sin embargo, DevOps ha avanzado de tal forma que ciertos elementos de las pruebas pueden producirse en la planificación (desarrollo basado en el comportamiento), el desarrollo (pruebas unitarias, pruebas de contrato), la integración (análisis de código estático, análisis de CVE, linting), la implementación (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 continuas son una poderosa forma de identificación de riesgos y vulnerabilidades y brindan a TI la oportunidad de aceptar, mitigar o remediar los riesgos. Además, las pruebas de desplazamiento a la izquierda son un enfoque en el desarrollo de software que hace hincapié en trasladar las actividades de prueba a una fase más temprana del proceso de desarrollo. Este enfoque mejora la calidad del producto, la cobertura de las pruebas, los ciclos continuos de retroalimentación y el tiempo de comercialización.
La primera de las fases de las operaciones, la fase de lanzamiento, es la última antes de que los usuarios accedan a la aplicación. En este flujo de trabajo, el resultado de la compilación en tiempo de ejecución (desde la integración) se implementa en un entorno de tiempo de ejecución, normalmente un entorno de desarrollo en el que se ejecutan pruebas de calidad, conformidad y seguridad.
Si se detectan errores o defectos, los desarrolladores tienen la oportunidad de interceptarlos y solucionarlos antes de que los usuarios los vean. Suele haber entornos de desarrollo, pruebas y producción, cada uno de los cuales exige puertas de calidad cada vez más estrictas. Cuando los desarrolladores han solucionado todos los problemas detectados y la aplicación cumple todos los requisitos, el equipo de operaciones confirma que está lista para su implementación y la crea en el entorno de producción.
La implementación se produce cuando el proyecto se traslada a un entorno de producción en el que los usuarios pueden acceder a los cambios de la aplicación. Se instala y configura la infraestructura (a menudo utilizando la infraestructura como código) y se implementa el código de la aplicación. Una buena práctica para la implementación en un entorno de producción es hacerlo primero con un subconjunto de usuarios finales y, finalmente, con todos los usuarios una vez que se haya establecido la estabilidad.
Si el "Día 1" es la entrega de las prestaciones a un entorno de producción, el "Día 2" es el comienzo de las operaciones. Monitorizar el rendimiento, el comportamiento y la disponibilidad de las funciones ayuda a garantizar que estas aportan valor a los usuarios.
En esta fase, los equipos comprueban que las características funcionen correctamente y que no haya interrupciones del servicio, asegurándose de que la red, el almacenamiento, la plataforma, la informática y las posiciones de seguridad estén en buen estado. Si surgen problemas, los equipos de operaciones identifican el incidente, alertan al personal adecuado, solucionan los problemas y aplican correcciones.
Se trata de recopilar los comentarios de los usuarios y clientes sobre las características, funciones, rendimiento y valor empresarial para planificar las mejoras y características de la próxima versión. También incluye cualquier elemento aprendido y pendiente de las actividades operativas que pueda ayudar a los desarrolladores a evitar de forma proactiva que vuelvan a producirse incidentes conocidos. Este es el punto en el que se produce la "envoltura" de la fase de planificación que impulsa la mejora continua.
Hay otros dos flujos de trabajo continuos importantes en el ciclo de vida:
Mientras que las metodologías en cascada y las implementaciones ágiles "añaden" 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 se ejecutan de forma continua durante el resto del ciclo de desarrollo. Este enfoque de la seguridad se conoce como desplazamiento a la izquierda. Algunas organizaciones han tenido menos éxito que otras, lo que ha dado lugar al surgimiento de DevSecOps (desarrollo, seguridad y operaciones).
También es mejor abordar el gobierno, el riesgo y la conformidad (GRC) desde el principio y a lo largo de todo el ciclo de vida del desarrollo. Los sectores regulados a menudo están obligados a proporcionar un cierto nivel de observabilidad, trazabilidad y acceso a cómo se entregan y gestionan las características en su entorno operativo en tiempo de ejecución.
Para ello es necesario planificar, desarrollar, probar y aplicar políticas en el proceso de canalización de entrega continua y en el entorno de tiempo ejecución. La auditabilidad de las medidas de conformidad es importante para probarla ante auditores externos.
Los líderes empresariales suelen estar de acuerdo en que los métodos de DevOps no funcionan sin un compromiso con la cultura DevOps, es decir, un enfoque organizativo y técnico diferente del desarrollo de software.
A nivel organizativo, DevOps requiere comunicación continua, colaboración y responsabilidad compartida entre todas las partes interesadas en la entrega de software. Esto incluye a los equipos de desarrollo de software y operaciones de TI, por supuesto, pero también a los equipos de seguridad, conformidad, gobierno, riesgo y línea de negocio, para innovar de forma rápida y continua y centrarse en la calidad desde el principio.
Por lo general, la mejor forma de conseguirlo es romper los silos y reorganizar al personal en equipos de DevOps multifuncionales y autónomos que puedan trabajar en proyectos de principio a fin (desde la planificación hasta los comentarios) sin tener que hacer traspasos a otros equipos ni esperar su aprobación. En el contexto del desarrollo ágil, la responsabilidad compartida y la colaboración son los cimientos de un enfoque de producto compartido con resultados valiosos.
A nivel técnico, DevOps requiere un compromiso con la automatización que mantenga los proyectos en movimiento dentro de los flujos de trabajo y entre ellos. También requiere comentarios y mediciones que permitan a los equipos acelerar continuamente los ciclos y mejorar la calidad y el rendimiento del software.
Fomentar una cultura de colaboración y eliminar los silos acerca el trabajo de los equipos de desarrolladores y operaciones, lo que aumenta la eficacia y reduce la carga de trabajo debido a la combinación de flujos de trabajo. Como los desarrolladores y los equipos de operaciones comparten muchas responsabilidades, hay menos sorpresas a medida que avanzan los proyectos. Los equipos de DevOps saben exactamente en qué entorno se ejecuta el código mientras lo desarrollan.
Los equipos de DevOps entregan código nuevo más rápido gracias a una mayor colaboración y a la creación de versiones más centradas (y más frecuentes) mediante el uso de una arquitectura de microservicios. Este proceso impulsa mejoras, innovaciones y correcciones de errores que llegan antes al mercado.
También permite a las organizaciones adaptarse a los cambios del mercado más rápidamente y satisfacer las necesidades de los clientes en mayor medida, lo que se traduce en una mayor satisfacción del cliente y una ventaja competitiva. El proceso de lanzamiento de software puede automatizarse con la entrega y la integración continuas.
La entrega y la integración continuas incluyen pruebas automatizadas para ayudar a garantizar la calidad y fiabilidad de las actualizaciones de software e infraestructura. La monitorización y la información de registro verifican el rendimiento en tiempo real.
La automatización, incluida la infraestructura como el código, puede ayudar a gestionar el desarrollo, las pruebas y la producción, y permitir un escalado más rápido con mayor eficiencia.
DevSecOps incorpora la integración, la entrega y la implementación continuas en el proceso de desarrollo, de modo que la seguridad se incorpora desde el principio, en lugar de modificarse a posteriori Los equipos incorporan pruebas y auditorías de seguridad en los flujos de trabajo utilizando la infraestructura como código para ayudar a mantener el control y realizar un seguimiento de la conformidad.
Un enfoque DevOps puede ayudar a mejorar la satisfacción laboral automatizando tareas rutinarias y repetitivas y permitiendo a los empleados centrarse en un trabajo más gratificante que impulse el valor empresarial.
Las exigencias de DevOps y de la cultura DevOps hacen que sea necesario contar con herramientas que admitan la colaboración asíncrona, integren de manera fluida los flujos de trabajo de DevOps y automaticen todo el ciclo de vida de DevOps en la medida de lo posible.
Las categorías de herramientas de DevOps incluyen:
Las herramientas de gestión de proyectos permiten a los equipos crear un backlog de historias de usuario (requisitos) que forman proyectos de codificación, dividirlos en tareas más pequeñas y realizar un seguimiento de las tareas hasta su finalización. Muchas herramientas son compatibles con prácticas ágiles de gestión de proyectos, como Scrum, Lean y Kanban, que los desarrolladores aportan a DevOps. Entre las opciones de código abierto más populares se encuentran GitHub Issues y Jira.
Se trata de entornos de codificación controlados por versiones que permiten a varios desarrolladores trabajar en la misma base de código. Los repositorios de código deben integrarse con herramientas de CI/CD, pruebas y seguridad, de modo que cuando el código se consigne en el repositorio pueda pasar automáticamente al siguiente paso. Entre los repositorios de código abierto se encuentran GitHub y GitLab.
Se trata de herramientas que automatizan la comprobación, construcción, prueba e implementación del código. Jenkins es la herramienta de código abierto más popular en esta categoría; muchas alternativas anteriores de código abierto, como CircleCI, ahora solo están disponibles en versiones comerciales.
En cuanto a las herramientas de implementación continua (CD), Spinnaker se sitúa entre las capas de aplicación e infraestructura como código. ArgoCD es otra opción popular de código abierto para el CI/CD nativo de Kubernetes.
Se trata de herramientas de software, bibliotecas y buenas prácticas para automatizar pruebas unitarias, contractuales, funcionales, de rendimiento, de usabilidad, de penetración y de seguridad. Las mejores herramientas son compatibles con varios lenguajes. Algunas utilizan inteligencia artificial (IA) para reconfigurar automáticamente las pruebas en respuesta a cambios en el código. El abanico de herramientas y marcos de pruebas es muy amplio. Entre los marcos de automatización de pruebas de código abierto más populares están Selenium, Appium, Katalon, Robot Framework y Serenity (antes conocido como Thucydides).
Las herramientas de gestión de la configuración (también conocidas como herramientas de infraestructura como código) permiten a los ingenieros de DevOps configurar y aprovisionar una infraestructura totalmente versionada y documentada mediante la ejecución de un script. Las opciones de código abierto incluyen Ansible (Red Hat), Chef, Puppet y Terraform. Kubernetes realiza la misma función para aplicaciones en contenedores.
Las herramientas de monitorización ayudan a los equipos de DevOps a identificar y resolver los problemas del sistema. También recopilan y analizan datos en tiempo real para revelar cómo afectan los cambios de código al rendimiento de la aplicación. Entre las herramientas de monitorización de código abierto se encuentran Datadog, Nagios, Prometheus y Splunk.
Estas herramientas recogen los comentarios de los usuarios, ya sea mediante mapas de calor (registrando las acciones de los usuarios en la pantalla), encuestas o tickets de incidencias de autoservicio.
La natividad de la nube es un enfoque para crear aplicaciones que utilizan tecnologías de cloud computing fundacionales. Las plataformas en la nube permiten un desarrollo, implementación, gestión y rendimiento óptimos y coherentes de las aplicaciones en entornos públicos, privados y multinube.
Hoy en día, las aplicaciones nativas de la nube suelen estar:
- Creadas mediante microservicios: componentes libremente acoplados e implementables de forma independiente 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.
- Implementadas en contenedores: unidades ejecutables de código que contienen todo el código, los tiempos de ejecución y las dependencias del sistema operativo necesarios para ejecutar la aplicación. Para muchas organizaciones, los contenedores son sinónimo de contenedores Docker, pero existen otros tipos.
- Operadas (a escala) mediante el uso de Kubernetes: una plataforma de orquestación de contenedores de código abierto para programar y automatizar la implementación, la gestión y el escalado de aplicaciones en contenedores.
En muchos sentidos, el desarrollo nativo de la nube y DevOps están hechos 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 pequeña base de código, encaja a la perfección con los rápidos ciclos de lanzamiento y gestión de DevOps. Sería difícil hacer frente a la complejidad de una arquitectura de microservicios sin la implementación y el funcionamiento de DevOps.
Una encuesta reciente de IBM a desarrolladores y ejecutivos de TI reveló 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 es probable que el 56 % de los no usuarios adopten microservicios en los próximos dos años.
Al empaquetar y fijar permanentemente todas las dependencias del sistema operativo, los contenedores permiten ciclos rápidos de CI/CD e implementación, porque toda la integración, las pruebas y la implementación se producen en el mismo entorno. La orquestación de Kubernetes realiza las mismas tareas de configuración continua para aplicaciones en contenedores que Ansible, Puppet y Chef para aplicaciones no contenedorizadas.
La mayoría de los principales proveedores de cloud computing, incluidos AWS, Google, Microsoft Azure e IBM Cloud, ofrecen algún tipo de solución gestionada de canalización de DevOps.
DevSecOps es DevOps que integra y automatiza continuamente la seguridad a lo largo del ciclo de vida de DevOps, desde la planificación hasta la retroalimentación y de nuevo a la planificación.
En otras palabras: DevSecOps es lo que DevOps debería haber sido desde el principio. Pero dos de los primeros e importantes (y durante un tiempo insuperables) retos 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 la seguridad en el ciclo de vida de DevOps (un problema técnico). La seguridad llegó a percibirse como el equipo del no, y como un costoso cuello de botella en muchas prácticas 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 de primera categoría y parte interesada junto con el desarrollo y las operaciones, y lleva la seguridad al proceso de desarrollo con un enfoque de producto.
La ingeniería de fiabilidad del sitio (SRE) utiliza técnicas de ingeniería de software para automatizar tareas de operaciones informáticas, 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 los administradores de sistemas podrían realizar manualmente. La SRE pretende transformar al clásico administrador de sistemas en un ingeniero.
El objetivo de la SRE es similar al de DevOps, pero es más específico: la SRE pretende equilibrar el deseo de una organización de desarrollar aplicaciones rápidamente con su necesidad de cumplir los niveles de rendimiento y disponibilidad especificados en los acuerdos de nivel de servicio (SLA) con los clientes.
Los ingenieros de fiabilidad del sitio logran este equilibrio determinando un nivel aceptable de riesgo operativo causado por las aplicaciones, denominado presupuesto de errores, y automatizando las operaciones para alcanzar ese nivel.
En un equipo multifuncional de DevOps, la SRE puede servir de puente entre el desarrollo y las operaciones. La SRE proporciona las métricas y las herramientas de automatización que los equipos necesitan para impulsar los cambios de código y las nuevas características a través del canal de DevOps lo más rápido posible, sin violar los términos de los acuerdos de nivel de servicio de la organización.
A medida que aumenta la amplitud de las tareas que pueden automatizarse, se añaden más funciones a DevOps, lo que genera múltiples variaciones de DevOps. Y a medida que DevOps demuestra sus numerosos beneficios, aumenta la inversión empresarial.
Según Verified Market Research, el mercado de DevOps se valoró en 10,96 mil millones de USD en 2023 y se prevé que alcance los 21,13 mil millones de USD en 2031, creciendo a una CAGR del 21,23 % de 2024 a 2031.
Para ayudar a garantizar el éxito de DevOps, las empresas están adoptando cada vez más:
La inteligencia artificial para las operaciones de TI incorpora IA y machine learning para automatizar y agilizar las operaciones de TI, permitiendo el análisis rápido de enormes cantidades de datos.
BizDevOps hace que las unidades de negocio colaboren en el proceso de desarrollo de software junto con las de desarrollo y operaciones. También conocido como DevOps 2.0, este cambio cultural acelera el proceso y conduce a soluciones más sólidas que se alinean con los objetivos de la unidad de negocio.
Otra forma de crear nuevas eficiencias es la contenerización, en la que una aplicación y sus dependencias se encapsulan en un paquete ágil y portátil que se ejecuta en casi cualquier plataforma.
Añadir más funciones de seguridad al principio del desarrollo impulsó DevSecOps. La seguridad ya no es una ocurrencia tardía.
GitOps se centra en almacenar el código de la aplicación en un repositorio Git para que esté controlado por versiones, disponible para múltiples miembros del equipo y totalmente rastreable y auditable. Estas medidas ayudan a aumentar la eficiencia, la fiabilidad y la escalabilidad.
Mientras que las herramientas de monitorización tradicionales proporcionan observabilidad, las plataformas de observabilidad proporcionan una comprensión más profunda del rendimiento de un sistema y, lo que es más importante, del contexto: el porqué del rendimiento. Además de proporcionar esta comprensión global, la observabilidad permite a todas las partes interesadas acceder a los datos que necesitan para construir soluciones y crear mejores aplicaciones.
La informática sin servidor o serverless es un modelo de desarrollo y ejecución de aplicaciones que permite a un desarrollador crear y ejecutar código de aplicación sin necesidad de aprovisionar o gestionar servidores o infraestructura de backend. En las arquitecturas serverless, los desarrolladores escriben el código de la aplicación y lo implementan en contenedores gestionados por un proveedor de servicios cloud.
Utilice un potente software DevOps para crear, implementar y gestionar aplicaciones nativas de la nube con un alto nivel de seguridad en varios dispositivos, entornos y nubes.
Automatice el proceso de entrega de software para aumentar la productividad y la eficiencia operativa.
Transforme las aplicaciones de misión crítica para entornos de nube híbrida con estabilidad, seguridad y agilidad.
Innove más rápido, reduzca los costes operativos y transforme las operaciones de TI (ITOps) en un panorama cambiante con una plataforma de AIOps que ofrece visibilidad de los datos de rendimiento y las dependencias en todos los entornos.
Descubra cómo la modernización de sus entornos de aplicaciones mainframe le proporcionará mejores resultados empresariales.
Acceda a un informe exclusivo de analistas de Gartner y descubra cómo la IA para TI mejora los resultados empresariales, conduce a un aumento de los ingresos y reduce tanto los costes como los riesgos para las organizaciones.
Este Redpaper de IBM analiza las estrategias y soluciones de arquitectura que pueden acelerar la modernización de sus aplicaciones de mainframe aprovechando los entornos de nube híbrida. En concreto, consulte el capítulo 5 para obtener información sobre la modernización de DevOps empresarial.
Conozca Wazi Deploy, que añade una opción de implementación de aplicaciones basada en código abierto y en scripts al amplio conjunto de herramientas de desarrollo de IBM Developer for z/OS Enterprise Edition.
Explore un programa de adopción temprana de valor añadido diseñado para asociarse con los clientes durante las distintas etapas que consideramos necesarias para cualquier transformación de DevOps.
Únase a la comunidad DevSecOps para estar al día de las últimas tendencias y temas de Z.