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 se vuelve más eficiente, rápido y confiable.
Por definición, DevOps, operaciones de desarrollo, describe un proceso de desarrollo de software y un cambio de cultura organizacional que fomenta la coordinación y colaboración entre los equipos de desarrollo y operaciones de TI, dos grupos que tradicionalmente practicaban por separado entre sí o en silos.
En la práctica, los mejores procesos y culturas de DevOps van más allá de las prácticas y operaciones de desarrollo para incorporar entradas de todas los stakeholders de las aplicaciones en el ciclo de vida del desarrollo de software. Esto incluye ingenieros de plataforma e infraestructura, seguridad, cumplimiento, gobernanza, gestión de riesgos y línea de negocio, usuarios y clientes.
Los principios de DevOps representan el estado actual en la evolución del proceso de entrega de software durante los últimos 20 años. El proceso de entrega progresó desde lanzamientos gigantes de código de toda la aplicación cada varios meses o incluso años, hasta características iterativas más pequeñas o actualizaciones funcionales, lanzadas con una frecuencia diaria o varias veces al día.
En última instancia, DevOps se trata de satisfacer la creciente demanda de los usuarios de software de características nuevas, innovadoras y frecuentes, y de rendimiento y disponibilidad ininterrumpidos.
Si el software es importante, entonces la eficiencia de la entrega del software también importa. Lea el reporte para obtener información sobre cómo mejorar la eficiencia general del ciclo de vida de DevOps.
Regístrese para obtener la guía sobre la nube híbrida
Antes del año 2000, la mayoría del software se desarrollaba y actualizaba a través de la metodología en cascada, un enfoque lineal para proyectos de desarrollo a gran escala. Los equipos de desarrollo de software pasaron meses desarrollando grandes conjuntos de código nuevo que afectaron la mayor parte o todo el ciclo de vida de la aplicación. Debido a que los cambios fueron tan extensos, pasaron varios meses más integrando ese nuevo código en la base del código.
A continuación, los equipos de control de calidad (QA), seguridad y operaciones pasaron aún más meses probando el código. El resultado fueron meses o incluso años entre lanzamientos de software y, a menudo, también varios parches importantes o correcciones de errores entre lanzamientos. Este gran enfoque para la entrega de funciones a menudo se caracterizó por planes de implementación complejos y arriesgados, interbloqueos difíciles de programar con sistemas ascendentes y descendentes, y la gran esperanza de TI de que los requisitos comerciales no cambiaron significativamente en los meses previos al inicio de la producción o la versión de disponibilidad general (GA).
Para acelerar el desarrollo y mejorar la calidad, los equipos de desarrollo comenzaron a adoptar metodologías ágiles de desarrollo de software a principios de la década de 2000. Estas metodologías son iterativas en lugar de lineales y se centran en realizar actualizaciones más pequeñas y frecuentes en el código base de la aplicación. Las principales metodologías de DevOps son la integración continua y la entrega continua (CI/CD).
En CI/CD, fragmentos más pequeños de código nuevo se fusionan en la base de código a intervalos frecuentes y luego se integran, prueban y preparan automáticamente para su implementación en el entorno de producción. Agile modificó el enfoque big bang en una serie de imágenes instantáneas más pequeñas, que también compartieron los riesgos.
Cuanto más aceleraban con eficacia estas prácticas de desarrollo ágil el desarrollo y la entrega de software, más exponían las operaciones de TI, el aprovisionamiento de sistemas, la configuración, las pruebas de aceptación, la gestión y la supervisión aún aisladas, por ejemplo, como el siguiente cuello de botella en el ciclo de vida de la entrega de software.
Entonces, DevOps surgió de ágil. Agregó 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. Implementó una estrecha colaboración entre desarrollo y operaciones en cada paso del proceso.
El ciclo de vida de DevOps (a veces llamado canalización de entrega continua, cuando se representa de manera 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 grande, automatizado e iterativo, diseñado para optimizar la entrega rápida de software de alta calidad. Los nombres de los flujos de trabajo y la cantidad de flujos de trabajo difieren según a quién se le pregunte, pero a menudo incluyen estos ocho pasos.
En este flujo de trabajo, los equipos analizan nuevas características y funciones para la próxima versión, y se basan en la retroalimentación de los usuarios y estudios de casos priorizados, así como en las aportaciones de todos los stakeholders. El objetivo de la etapa de planeación es maximizar el valor comercial del producto produciendo una acumulación de características que mejoran el valor del producto.
Este es el paso de programación, en el que los desarrolladores codifican y crean características nuevas y mejoradas basadas en historias de usuarios y elementos de trabajo en el backlog. Es común una combinación de prácticas como el desarrollo basado en pruebas (TDD), la programación por pares y las revisiones de código entre pares. Los desarrolladores suelen emplear sus estaciones de trabajo locales para realizar el ciclo interno de escritura y prueba del código antes de enviarlo por Delivery Pipeline.
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 y despliegue. Las actividades de automatización habituales incluyen la fusión de 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. La mejor práctica es almacenar el resultado de la fase CI en un repositorio binario para la siguiente fase.
Los equipos emplean pruebas, a menudo automatizadas, para cerciorarse de que la aplicación cumple las normas y requisitos. El enfoque DevOps tradicional incluye una fase de prueba discreta que se produce entre la construcción y la liberación.
Sin embargo, DevOps avanzó de tal manera que determinados elementos de las pruebas pueden producirse en la planeación (desarrollo basado en el comportamiento), el desarrollo (pruebas unitarias, pruebas de contrato), la integración (análisis estáticos de código, análisis de CVE, análisis), 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 continuas son una forma poderosa de identificación de riesgos y vulnerabilidades y brindan una oportunidad para que TI acepte, mitigue o remedie riesgos. Además, las pruebas shift-left son un enfoque en el desarrollo de software que enfatiza mover las actividades de prueba más temprano en el proceso de desarrollo. Este enfoque mejora la calidad del producto, la cobertura de las pruebas, los ciclos de retroalimentación continua y el tiempo de comercialización.
La primera de las etapas de operaciones, la etapa 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 del tiempo de ejecución (de la integración) se despliega en un entorno de tiempo de ejecución, generalmente un entorno de desarrollo donde se ejecutan pruebas de tiempo de ejecución para determinar la calidad, el cumplimiento 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 lo vean. Por lo general, hay entornos para el desarrollo, las pruebas y la producción, y cada entorno requiere controles de calidad cada vez más estrictos. Cuando los desarrolladores solucionan todos los problemas identificados y la aplicación cumple con todos los requisitos, el equipo de operaciones confirma que está lista para el despliegue y la integra en el entorno de producción.
El despliegue es cuando el proyecto se traslada a un entorno de producción donde los usuarios pueden acceder a los cambios en la aplicación. La infraestructura se instala y configura (a menudo mediante el uso de la infraestructura como código) y se despliega el código de la aplicación. Una buena práctica para el despliegue en un entorno de producción consiste en desplegarse primero en un subconjunto de usuarios finales y, finalmente, en todos los usuarios una vez que se establece la estabilidad.
Si la entrega de características en un entorno de producción se considera como “Día 1”, entonces una vez que las características se ejecutan en producción, comienzan las operaciones del “Día 2”. El monitoreo del rendimiento, el comportamiento y la disponibilidad de las características ayuda a garantizar que las características brinden valor a los usuarios.
En esta fase, los equipos comprueban que las características funcionan correctamente y que no hay interrupciones del servicio, asegurando que las posturas de red, almacenamiento, plataforma, computación y seguridad son saludables. Si se producen problemas, los equipos de operaciones identifican el incidente, alertan al personal adecuado, solucionan los problemas y hacen arreglos.
Se trata de recopilar la retroalimentación de usuarios y clientes sobre características, funciones, rendimiento y valor empresarial para planear las mejoras y características de la próxima versión. Esto también incluye cualquier aprendizaje y elementos pendientes de las actividades de operaciones que puedan ayudar a los desarrolladores a evitar de forma proactiva que vuelvan a producir incidentes conocidos. Este es el punto en el que se produce la "envoltura" de la fase de planeació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 “agregan” los flujos de trabajo de seguridad luego de la entrega o el despliegue, DevOps se esfuerza por incorporar la seguridad desde el principio (planeación), cuando los problemas de seguridad son más fáciles y menos costosos de abordar, y se ejecutan continuamente durante el resto del ciclo de desarrollo. Este enfoque de la seguridad se conoce como desplazamiento a la izquierda. Algunas organizaciones tuvieron menos éxito en el cambio que otras, lo que llevó al auge de DevSecOps (desarrollo, seguridad y operaciones).
También es mejor abordar gobernanza, riesgo y cumplimiento (GRC) en las primeras etapas 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 a cómo se entregan y gestionan las características en su entorno operativo de tiempo de ejecución.
Esto requiere planificación, desarrollo, pruebas y aplicación de políticas en el Delivery Pipeline continuo y el entorno de tiempo de ejecución. La auditoría de las medidas de cumplimiento es importante para demostrar el cumplimiento ante auditores externos.
Los líderes empresariales suelen estar de acuerdo en que los métodos DevOps no funcionan sin un compromiso con la cultura DevOps, es decir, un enfoque organizacional y técnico diferente del desarrollo de software.
A nivel organizacional, DevOps requiere comunicación continua, colaboración y responsabilidad compartida entre todos los stakeholders en la entrega de software. Esto incluye equipos de desarrollo de software y operaciones de TI, sin duda, pero también equipos de seguridad, cumplimiento, gobernanza, 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 manera de lograr esto es romper los silos y reorganizar al personal en equipos DevOps autónomos y multifuncionales que puedan trabajar en proyectos de principio a fin (planificando la retroalimentación) sin realizar entregas a otros equipos 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 de producto compartido con resultados valiosos.
A nivel técnico, DevOps requiere un compromiso con la automatización que mantiene los proyectos en movimiento dentro y entre flujos de trabajo. También requiere retroalimentación y medición que permite a los equipos acelerar continuamente los ciclos y mejorar la calidad y el rendimiento del software.
Fomentar una cultura de colaboración y eliminar el aislamiento hace que los desarrolladores y los equipos de operaciones trabajen juntos, lo que aumenta la eficiencia y reduce las cargas de trabajo debido a la combinación de flujos de trabajo. Debido a que 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 a medida que lo desarrollan.
Los equipos de DevOps entregan código nuevo más rápido a través de una mayor colaboración y la creación de versiones más enfocadas (y más frecuentes) mediante el uso de una arquitectura de microservicios. Este proceso impulsa mejoras, innovaciones y correcciones de errores para comercializar más prontos.
También permite a las organizaciones adaptarse a los cambios del mercado con mayor rapidez y satisfacer mejor las necesidades de los clientes, lo que se traduce en una mayor satisfacción del cliente y un beneficio competitivo. El proceso de lanzamiento de software se puede automatizar con entrega continua e integración continua.
La entrega y la integración continuas incluyen pruebas automatizadas para ayudar a garantizar la calidad y confiabilidad de las actualizaciones de software e infraestructura. El monitoreo y el 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 escalamiento más rápido con mayor eficiencia.
DevSecOps realiza integración, entrega e implementación continuas en el proceso de desarrollo para que la seguridad se incorpore desde el principio, en lugar de una actualización. Los equipos construyen pruebas y auditorías de seguridad en los flujos de trabajo mediante el uso de infraestructura como código para ayudar a mantener el control y realizar un seguimiento del cumplimiento normativo.
Un enfoque DevOps puede ayudar a mejorar la satisfacción laboral automatizando tareas ordinarias y repetitivas, lo que permite a los empleados concentrarse en un trabajo más gratificante que impulse el valor del negocio.
Las demandas de DevOps y la cultura DevOps otorgan una gran importancia a las herramientas que admiten la colaboración asincrónica, integran perfectamente 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:
Las herramientas de gestión de proyectos permiten a los equipos acumular historias de usuario (requisitos) que forman proyectos de programación, dividirlos en tareas más pequeñas y realizar un seguimiento de las tareas hasta su finalización. Muchas herramientas admiten prácticas ágiles de gestión de proyectos, como Scrum, Lean y Kanban, que los desarrolladores aportan a DevOps. Las opciones populares de código abierto incluyen GitHub Issues y Jira.
Estos son entornos de codificación controlados por versión que permiten que varios desarrolladores trabajen 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 confirme en el repositorio, pueda pasar automáticamente al siguiente paso. Los repositorios de código fuente abierto incluyen GitHub y GitLab.
Estas son herramientas que automatizan la verificación, creación, prueba y despliegue de 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 están disponibles solo en versiones comerciales.
Para las herramientas de despliegue continuo (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.
Estos incluyen herramientas de software, bibliotecas y mejores prácticas para automatizar pruebas unitarias, contractuales, funcionales, de performance, usabilidad, penetración y seguridad. Lo mejor de estas herramientas admite varios idiomas. Algunos emplean inteligencia artificial (IA) para reconfigurar automáticamente las pruebas en respuesta a cambios de código. La extensión de herramientas y marcos de prueba es amplia. Los marcos de automatización de pruebas de código abierto populares incluyen Selenium, Appium, Katalon, Robot Framework y Serenity (anteriormente 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 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 las aplicaciones en contenedores.
Las herramientas de monitoreo ayudan a los equipos de DevOps a identificar y resolver problemas del sistema. También recopilan y analizan datos en tiempo real para revelar cómo los cambios de código afectan el rendimiento de las aplicaciones. Las herramientas de monitoreo de código abierto incluyen Datadog, Nagios, Prometheus y Splunk.
Estas herramientas recogen la retroalimentación de los usuarios, ya sea mediante mapas de calor (registrando las acciones de los usuarios en la pantalla), encuestas o etiquetas de problemas de autoservicio.
La nube nativa es un enfoque para crear aplicaciones que utilizan tecnologías fundamentales de computación en la nube. Las plataformas en la nube ayudan a permitir el desarrollo, despliegue, administración y rendimiento de aplicaciones consistentes y óptimas en entornos públicos, privados y multi nube.
Hoy en día, las aplicaciones nativas de la nube suelen ser:
- Creadas mediante el uso de microservicios: Componentes poco acoplados y de despliegue independiente que tienen su propia pila autónoma y se comunican entre sí a través de API REST, transmisión de eventos o agentes de mensajes.
- Desplegado 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 hay otros contenedores disponibles.
- Operado (a escala) mediante el uso de Kubernetes: Una plataforma de orquestación de contenedores de código abierto para programar y automatizar el despliegue, la gestión y el escalamiento de aplicaciones en contenedores.
En muchos sentidos, el desarrollo nativo de la nube y DevOps se hicieron 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 una opción perfecta para los ciclos rápidos de lanzamiento y administración de DevOps. Sería difícil lidiar con la complejidad de una arquitectura de microservicios sin la implementación y operación 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 invirtieron en la arquitectura, y es probable que el 56 % de los que no son 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 y despliegue, porque 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 en contenedores que Ansible, Puppet y Chef para aplicaciones que no son en contenedores.
La mayoría de los principales proveedores de computación en la nube, incluidos AWS, Google, Microsoft Azure e IBM Cloud , ofrecen algún tipo de solución de canalización de DevOps gestionada.
DevSecOps es DevOps que integra y automatiza continuamente la seguridad durante todo el ciclo de vida de DevOps, de principio a fin, desde la planificación hasta la retroalimentación y la planificación nuevamente.
Otra forma de decirlo es que DevSecOps es lo que se suponía que debía ser DevOps desde el principio. Pero dos de los primeros desafíos importantes (y durante 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 la seguridad en el ciclo de vida de DevOps (un problema técnico). La seguridad llegó a ser percibida como el equipo "del 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, e incorpora la seguridad al proceso de desarrollo con un enfoque de producto.
La ingeniería de confiabilidad del sitio (SRE) emplea técnicas de ingeniería de software para automatizar las tareas de operaciones de TI, como la gestión del sistema de producción, la gestión del cambio, la respuesta a incidentes e incluso la respuesta a emergencias que, de otro modo, los administradores de sistemas podrían realizar manualmente. SRE busca transformar al administrador de sistemas tradicional en un ingeniero.
El objetivo de SRE es similar al objetivo de DevOps, pero es más específico: SRE tiene pretende equilibrar el deseo de una organización de 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 los clientes.
Los ingenieros de confiabilidad del sitio logran este equilibrio determinando un nivel aceptable de riesgo operativo causado por las aplicaciones, lo que se llama cotización de un error, y automatizando las operaciones para alcanzar ese nivel.
En un equipo multifuncional de DevOps, SRE puede servir como puente entre el desarrollo y las operaciones. 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 funciones a través de la canalización de DevOps lo más rápido posible, sin infringir los términos de los SLA de la organización.
A medida que aumenta la amplitud de las tareas que se pueden automatizar, se agregan más funciones a DevOps, lo que genera múltiples variaciones de DevOps. Y a medida que DevOps demuestra sus muchos beneficios, la inversión empresarial aumenta.
Según Verified Market Research, el mercado de DevOps se valoró en 10.96 mil millones USD en 2023 y se proyecta que alcance los 21.13 mil millones USD para 2031, creciendo a una CAGR del 21.23 % de 2024 a 2031.
Para ayudar a garantizar el éxito de DevOps, los negocios están adoptando cada vez más:
La inteligencia artificial para las operaciones de TI incorpora IA y aprendizaje automático para automatizar y optimizar las operaciones de TI, lo que permite un análisis rápido de grandes cantidades de datos.
BizDevOps trae unidades de negocio para colaborar en el proceso de desarrollo de software junto con el desarrollo y las 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 con contenerización, donde una aplicación y sus dependencias están encapsuladas en un paquete optimizado y portátil que se ejecuta en casi cualquier plataforma.
Agregar más funciones de seguridad al comienzo 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 tenga control de versiones, esté disponible para varios miembros del equipo y sea totalmente rastreable y auditable. Estas medidas ayudan a aumentar la eficiencia, la confiabilidad y la escalabilidad.
Si bien las herramientas de monitoreo tradicionales brindan visibilidad, las plataformas de observabilidad brindan una comprensión más profunda de cómo se está desempeñando un sistema y, lo que es más importante, del contexto: el por qué detrás de la actuación. Además de proporcionar esta comprensión integral, la observabilidad permite a todas las partes interesadas acceder a los datos que necesitan para crear soluciones y mejores aplicaciones.
La computación sin servidor es un modelo de computación en la nube de desarrollo y ejecución de aplicaciones que permite a los desarrolladores crear y ejecutar código de aplicación sin aprovisionar ni gestionar servidores o infraestructura de backend. En las arquitecturas sin servidor, los desarrolladores escriben el código de la aplicación y lo implementan en contenedores gestionados por un proveedor de servicios en la nube.
Utilice un potente software de DevOps para crear, desplegar y gestionar aplicaciones nativas de la nube con amplia seguridad en múltiples dispositivos, entornos y nubes.
Automatice su 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 costos operativos y transforme las operaciones de TI (ITOps, por sus siglas en inglés) en un entorno cambiante con una plataforma AIOps que ofrece visibilidad de los datos de rendimiento y las dependencias en todos los entornos.
Lea cómo la modernización de los entornos de aplicaciones mainframe proporcionará mejores resultados para su negocio.
Acceda a un informe de analistas exclusivo de Gartner y aprenda cómo la IA para TI mejora los resultados del negocio, genera mayores ingresos y reduce tanto los costos como los riesgos para las organizaciones.
Este IBM Redpaper analiza estrategias y soluciones arquitectónicas que pueden acelerar la modernización de sus aplicaciones de mainframe aprovechando los entornos de nube híbrida. Específicamente, consulte el capítulo 5 para obtener información sobre la modernización de DevOps empresarial.
Conozca Wazi Deploy, que agrega una opción de despliegue de aplicaciones basadas en scripts y de código abierto al amplio conjunto de herramientas de desarrollo de IBM Developer for z/OS Enterprise Edition.
Explore un programa de adopción temprana de valor agregado diseñado para asociarse con los clientes durante distintas etapas que creemos que son necesarias para cualquier transformación de DevOps.
Unir a la comunidad DevSecOps para mantenerse al tanto de las últimas tendencias y temas de Z.