Informe técnico oficial

Ejemplos prácticos de DevOps

para empresas de mainframe
Mainframes más inteligentes son capaces
de alcanzar niveles de eficiencia de DevOps

Índice página

Razón . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Acerca de este informe oficial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Acerca de DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
¿Qué incluye un nombre?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Definición de DevOps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Suena bien… . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
¿Cuál es la pega?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
¿El camino a seguir?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Escenario A: Mejora de la eficacia del desarrollo
   en paralelo de varios equipos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Escenario B: Mejora de la productividad del
  desarrollador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Escenario C: Rápida provisión y distribución del
   entorno de pruebas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Conclusión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Informe técnico oficial
Ejemplos prácticos de DevOps para empresas de mainframe
Razón
Nuestro sector es el que más rápido está cambiando de toda la industria actual: debate. Nuestro sector
es el que más frases y términos vagos y posiblemente vacíos posee de todos: caso cerrado.
Excepcionalmente, utilizaremos la plataforma de un informe oficial de
DevOps para desafiar el propio concepto de DevOps. Vamos a decons-
truir su definición (tal y como es ahora) para mostrar en su lugar un
conjunto de prácticas recomendadas y adaptaciones factibles de las
actuales prácticas de trabajo y, fundamentalmente, explicar cómo el
empleo de las herramientas adecuadas puede proporcionar todas las
supuestas ventajas de DevOps sin su incierto nombre.
Acerca de este informe oficial
Aplicamos los valores de DevOps en el trabajo en el mundo real, citando
tres situaciones reales de empresas con infraestructuras y perfiles tec-
nológicos muy alejados del estudio de caso de DevOps habitual. Un
banco, una gran aseguradora y un integrador de sistemas son buenos
ejemplos de empresas que aplican mejoras de estilo DevOps y gozan
de mejores resultados empresariales como resultado directo.
Este documento es un análisis en profundidad de lo que realmente
significa DevOps y de cómo las organizaciones pueden alcanzar sus
principios de mejora sin las limitaciones de DevOps.
Porque, según nuestra filosofía, alejarse de las ineficiencias anteriores
puede significar cosas distintas para cada empresa, pero todo el mundo
puede hacerlo.
Adoptar DevOps no es solo una cuestión de darle a un botón. Se trata
de descubrir qué cambios encajan con el perfil de cada organización y
aplicar los cambios tecnológicos o de procedimientos que proporcio-
narán las mejoras deseadas.
Este documento toca el liderazgo intelectual para pasar a ser una guía
práctica con el fin de mejorar las prácticas de desarrollo. Las explica
mediante el uso de casos de la “vida real” de empresas que adoptan
la filosofía DevOps para mejorar la eficiencia empresarial. Y funciona.
No se limite a pensar en este informe oficial como un manual de instruc-
ciones de DevOps, sino más bien como una oportunidad para identificar
y corregir las áreas de mejora del desarrollo.
2
Acerca de DevOps
En las últimas dos décadas, el mundo de la tecnología ha cambiado
radicalmente. Las plataformas, las arquitecturas, el software y los méto-
dos de comunicación también han experimentado cambios sísmicos de
tal magnitud que el mundo de la tecnología es totalmente irreconocible
comparado con las generaciones anteriores.
No solo ha cambiado el resultado de la innovación tecnológica, sino que
también lo ha hecho el proceso mediante el cual se crea la tecnología.
También ha dado origen a la aparición de una nueva terminología que
inspira y crea un miedo existencial a perderse algo (o a quedarse atrás)
en los demás.
Tal vez DevOps sea menos complicado de lo que parece; básicamente
no es más que otra forma de englobar las mejores prácticas de trabajo
modernas. Porque ya pasaron los días del burocrático modelo uniforme
cargado de front-end en cascada, con proyectos que se medían en
meses o incluso en años. En muchos casos, se ha visto desplazado
por un proceso más flexible y ágil a la hora de establecer los requisitos
para crear y entregar en cuestión de días. Hoy en día, la mayor parte del
personal del ámbito de la tecnología trabaja en un marco ágil (o conoce
a alguien que lo hace), ya sea consciente de ello o no.
¿Qué incluye un nombre?
El léxico tecnológico de moda contó con una importante incorporación
en una conferencia de Agile en 2008, en la que surgió el término
“DevOps” como un medio para definir cómo los métodos de desarrollo
ágil podían interoperar con una operación de infraestructura de TI más
amplia. La frase se consolidó rápidamente, hasta el punto de que hoy
en día parece ser otro nuevo estándar emergente de facto en la tec-
nología mundial, aunque en realidad no haga más que definir el área
de influencia entre las prácticas de trabajo y la tecnología disponible.
Puede que sea un concepto ambicioso, pero eso no es óbice para
que todas las organizaciones puedan implementar algún aspecto de
DevOps en lo que hacen.
Según Wikipedia1, DevOps es “un acrónimo inglés de development (de-
sarrollo) y operations (operaciones), que se refiere a una metodología
de desarrollo de software que se centra en la comunicación, colabora-
ción e integración entre desarrolladores de software y los profesionales
de operaciones en las tecnologías de la información (TI)”.
Veremos de qué manera los principios de DevOps (el paso hacia una
metodología más ágil) se pueden aplicar en cualquier lugar donde exista
la posibilidad de mejora.
Definición de DevOps
Un reciente artículo2 para el SDTimes describe a la perfección la as-
piración de DevOps desde el punto de vista del proceso, el equipo y
la organización.
“En el nivel del proceso técnico, podemos entender DevOps de
la manera en que se inició, en el contexto de una distribución
continuada. Un proyecto se acostumbra a implantar versiones en
grandes lotes una vez al trimestre más o menos. DevOps es la
aspiración de realizar implantaciones mucho más frecuentes”.
“En el nivel del equipo, podemos entenderlo como un énfasis en la
colaboración de TI que prescinde de silos. Nuestros desarrolladores,
certificadores y equipos de operaciones deben colaborar más
estrechamente, día a día, en el flujo de proyectos”.
“Desde el punto de vista de la organización, la mejora que
­proporciona DevOps se comprende mejor a través de la perspectiva
Lean: hay que hacer hincapié en la medición y mejora continua a
través de elementos como la identificación y la eliminación de las
restricciones en el flujo del sistema”.
En términos de ventajas tangibles, las posibilidades parecen intere-
santes. Una publicación3 sugiere que la incorporación de prácticas de
DevOps permite sacar adelante más trabajo e implantar código hasta
30 veces más frecuentemente que la competencia. Y, según el estudio
realizado en 2013 por Puppet Labs sobre el estado de DevOps 4, menos
del 50 por ciento de sus implantaciones fallan.
En otras publicaciones5 se citan otras ventajas:
Reducción del gasto en desarrollo y operaciones
Ciclos de desarrollo más cortos
Mayor velocidad de publicación
Detección de defectos mejorada
Menos errores de implantación y reversiones
Reducción del tiempo de recuperación en caso de fallo
Suena bien…
Habida cuenta de los beneficios prometidos, se podría predecir con
seguridad una letanía de historias de éxito y brillantes referencias. Sin
embargo, a juzgar por la dificultad para encontrar una historia de referen-
cia comercial en Internet, no se puede culpar a nadie por pensar que esto
era mucho ruido y pocas nueces. De hecho, abundan los comentarios del
tipo6 “DevOps para empresas es difícil, pero no imposible”.
Posiblemente uno de los problemas es la naturaleza intangible de lo
que DevOps realmente es. ¿Cómo puede una organización saber si
han “alcanzado DevOps”? No hay ninguna acreditación oficial. No hay
ningún certificado para colgar en la zona de recepción.
La cuestión es que DevOps es una forma de trabajar, que trata de que
la colaboración impere en el desarrollo, el funcionamiento y las áreas de
negocio. Si hay algún aspecto tangible de DevOps, este es la elimina-
ción de los silos, la participación de las partes interesadas pertinentes
y la distribución ágil de resultados de negocio automatizados. Esto no
es, por sí mismo, una cuestión de automatización, de la nube o de vir-
tualización. Se trata de hacer las cosas mejor con lo que hay disponible
y añadir la tecnología apropiada donde el proceso necesita apoyo.
¿Cuál es la pega?
Tal vez debamos volver a examinar los posibles problemas; al fin y al
cabo, puede que sí sea bastante difícil hacer DevOps. ¿Cuál puede ser
el motivo?
DevOps fomenta un nivel de inmediatez y colaboración en TI que, en
principio, tiene mucho sentido, pero que no es en absoluto fácil de
implementar. Esto es especialmente cierto en las empresas de larga
duración. Por lo general, se trata de una combinación de cuestiones
culturales, relacionadas con las tareas y tecnológicas.
Cultura: DevOps tiene como requisito previo un nivel de agilidad
(de Agile o de agilidad, como usted prefiera) que puede ser
una vana esperanza en muchos mercados de TI empresarial.
__________
1 www.wikipedia.org/wiki/DevOps
2 www.sdtimes.com/guest-view-devops-is-many-things-but-theyre-all-
about-building-the-right-product/
3 www.newrelic.com/devops/benefits-of-devops
4 www.puppetlabs.com/wp-content/uploads/2013/03/2013-state-of-
devops-report.pdf
5 www.logicworks.net/blog/2014/10/measurable-important-benefits-
devops/
6 www.informationweek.com/software/enterprise-applications/how-
devops-benefits-large-enterprises/a/d-id/1268924?page_number=2
3
Informe técnico oficial
Ejemplos prácticos de DevOps para empresas de mainframe
En un reciente encuentro de desarrolladores de COBOL
­empresarial7, menos de un cuarto de los asistentes respondieron
positivamente a una rápida pregunta de mano alzada sobre el uso
de “metodologías ágiles”. Se comprobó este mismo nivel local de
adopción en diversos eventos celebrados por toda Norteamérica.
Lo que esto nos dice es que los “típicos” equipos de desarrollo
de TI empresarial de larga duración, y en especial los que crean
aplicaciones COBOL, no utilizan los bloques de construcción
que requiere una operación de desarrollo simplificado, que es
en lo que se basa principalmente DevOps.
Tarea: en este tipo de organizaciones, la realidad a la que se
­enfrentan los directores de desarrollo es que la gran mayoría de
las actividades gira en torno al mantenimiento regular y rutinario
o a una tímida mejora. Se calcula que la proporción del gasto en
TI que se destina a actividades de “asentamiento” está en torno
al 70-80 por ciento8. Como consecuencia directa, la mayor parte
de la actividad de desarrollo no es un trabajo “nuevo”, de tipo “hoja
en blanco”, sino que requiere un análisis en profundidad del actual
código, importantes tareas de depuración y pruebas de unidades,
y una inversión significativa en integración y pruebas del sistema
para comprobar los resultados. Esto se ha corregido en gran medida
y resulta difícil realizar los flujos de trabajo secuenciales (sobre todo
con las restricciones del uso de la tecnología) con mayor rapidez.
Tecnológicas: las típicas inversiones en tecnología y arquitectura
de las empresas de mayor envergadura no suelen mantenerse a
la altura de los niveles de inversión en otras áreas. Por lo tanto,
todavía utilizan herramientas de la década de los 70 y los 80 como
plataforma para el desarrollo de sistemas. Estas herramientas eran
perfectamente útiles en su momento, pero se quedan cortas en el
contexto de lo que se puede conseguir en cuanto a eficiencia del
desarrollo moderno y colaboración entre grupos.
¿El camino a seguir?
La realidad de DevOps es que promete mucho como modelo concep-
tual, pero exige mucho de los marcos y fundamentos actuales, sin los
cuales su aplicación se encuentra en peligro.
Sin embargo, DevOps no debe considerarse una apuesta de todo o
nada. La mayoría de los principios fundamentales que motivan la adop-
ción de DevOps son evidentes, como la visibilidad mejorada, una mejor
colaboración, pruebas en las primeras fases del ciclo y un plazo de
distribución más rápido.
__________
7 http://online.microfocus.com/devday
8 Fuentes: Gartner, Forrester, Micro Focus y otros
9 Esto no es una limitación de la tecnología de por sí, sino más bien la
­consecuencia del modo en que este cliente la implementó
4
Por lo tanto, es hora de evaluar la validez de DevOps en la vida práctica.
Los siguientes tres escenarios ofrecen ese nivel de comprensión.
Escenario A: Mejora de la eficacia del desarrollo en
paralelo de varios equipos
Distribución de más proyectos simultáneos mediante la integración del
moderno control distribuido del código fuente en el mainframe.
Perfil del cliente:
Un gran proveedor de servicios de banca y seguros de la región de
Asia-Pacífico con varias marcas y muchas líneas de negocio
El desafío:
Aumentar la distribución de una nueva funcionalidad en la empresa y
permitir que varios equipos de desarrollo trabajen en proyectos paralelos.
Como muchos proveedores, esta aplicación única de seguros del cliente
proporciona las principales funciones de negocio, pero cada línea de ne-
gocio propone distintas ofertas a los clientes, y reclama funciones dife-
rentes. Un drástico incremento en el número de proyectos era inevitable.
Su sistema de gestión de configuraciones de mainframe, su popular
control del código fuente del mainframe y el sistema de gestión de
configuraciones no conseguían dan soporte fácilmente al desarrollo en
paralelo y carecían de la flexibilidad necesaria para aumentar el número
de versiones9. El resultado era un cuello de botella en la entrega y una
inversión del tiempo en:
Reproducir versiones y resolver regresiones
Entregar actualizaciones frecuentes y
Mantener líneas de código simultáneas
Revertir cambios y resolver conflictos de fusión
La solución:
La flexibilidad de los sistemas distribuidos de control de código fuente
y los procesos de desarrollo ágil modernos permitirían:
Aumentar la productividad de los desarrolladores mediante la
automatización
Versiones flexibles y más frecuentes para incluir los cambios
Compatibilidad con el desarrollo en paralelo en funciones,
­versiones o equipos
Cumplimiento de las normas de trazabilidad total
Lo más importante es que esto se lograría con la integración directa
en la gestión de configuraciones en el host, lo cual garantiza una ruta
de promoción constante a las bibliotecas de producción. Después de
sopesar la opción de código abierto, el cliente se decantó por Micro
Focus® AccuRev® y Enterprise Developer para System z.
AccuRev10 posibilitó el soporte efectivo de corrientes de desarrollo
paralelas, sincronizado con los cambios en las principales bibliotecas
de código del mainframe. Enterprise Developer permitió sincronizar
código fuente en el host.
El resultado:
Se aporta más flexibilidad para dar soporte a corrientes de desarrollo
paralelas, se brinda a los desarrolladores y a los equipos de desarrollo
la libertad de ramificar el código donde sea necesario y proporcionar
automatización de procesos, incluyendo la promoción y la fusión auto-
mática de los cambios en sincronía con el sistema SCM del host. Se
ejecutan más proyectos al mismo tiempo y se ofrece más funcionalidad
a la empresa, con menos tiempo invertido en arreglar regresiones o
revertiendo cambios.
Gestión minimizada de los cambios y esfuerzo de formación en adop-
ción, ya que el modelo de herencia de AccuRev refleja el modelo de
concatenación del desarrollo del mainframe. Esto facilitó las cadenas
de las bibliotecas dentro de un modelo de desarrollo por etapas (DEV/
INT/SYS/PROD).
Enterprise Developer permite un desarrollo moderno basado en Eclipse,
ya sea en el mainframe o en un sistema distribuido. Este proceso se
integra a la perfección con el intuitivo y sencillo modelo de configuración
de código fuente de AccuRev.
Materialización del modelo DevOps:
Los resultados de este escenario hacían posibles genuinos objetivos
de TI:
Reducción del gasto en desarrollo y operaciones: una
­integración incompleta equivale a una adopción inadecuada
por parte de los desarrolladores, lo cual aumenta el gasto
en productividad. Un IDE más moderno y eficiente vincula
al ­desarrollador con procesos y tecnología de mainframe de
­confianza que funcionan, y reduce el gasto.
Ciclos de desarrollo más cortos: aprovechar el poder de la
­estación de trabajo para acortar el desarrollo de mainframe y
los ciclos de pruebas de las unidades significa que los nuevos
productos y funciones están disponibles más rápido.
Mayor velocidad de publicación de aplicaciones: un aumento
de la productividad en el desarrollo de aplicaciones gracias al
­empleo de las mejores herramientas para desarrolladores de su
clase con la tecnología IDE más avanzada mejora los resultados
hasta en un 40 por ciento.
Detección de defectos mejorada: al eliminar los cuellos de botella
se reducen los riesgos a la hora de cumplir las programaciones
de entrega debido a los desafíos en materia de calidad, gasto y
tiempo.
Menos errores de implantación y reversiones: esto permite a
las organizaciones de TI de mainframe realizar pruebas previas a
la producción en hardware económico básico, lo que mejora los
índices de éxito y evita gastos y retrasos innecesarios.
Reducción del tiempo de recuperación en caso de fallo: agilizar
el proceso de desarrollo incluye la posibilidad de desarrollo en
paralelo y un proceso más rápido para introducir las correcciones
en caliente en la producción.
Escenario B: Mejora de la productividad del
desarrollador
Elimina la dependencia de los recursos para el desarrollo del mainframe
y posibilita la flexibilidad.
Perfil del cliente:
Este cliente de Micro Focus es un integrador de sistemas que propor-
ciona servicios de desarrollo de mainframe a grandes empresas.
El desafío:
Para diferenciarse de la competencia, querían prestar un servicio que
eliminara la dependencia de los recursos para el desarrollo de main-
frame del cliente. Consumir menos millones de instrucciones por se-
gundo (MIPS) sería más rentable para el cliente y libraría al integrador
de sistemas de partir de los cuellos de botella que provocaban las
herramientas ineficaces y los tiempos de espera del mainframe.
Inculcar las habilidades de desarrollo de aplicaciones de mainframe
dentro de la organización para colaborar con la máxima eficacia era
otro problema.
La dificultad no radicaba tanto en la calidad del talento como en los
procesos con los que se pedía que se trabajara. Los desarrolladores
formados en JAVA y conocedores de Agile no estaban seguros de
cómo debían enfocar las metodologías basadas en el mainframe ya
implantadas.
La clave fue adaptar el entorno de host a las capacidades y habilidades
de los nuevos talentos. Las herramientas de desarrollo basadas en
Eclipse, integradas con herramientas de gestión continua de calidad
del código, como SONAR, permitieron a los desarrolladores de JAVA
experimentar una transición sencilla.
La solución:
La solución era tan sencilla como inteligente: incorporar el desarrollo
de Agile en el entorno de mainframe permitiendo a los desarrolladores
conocedores de Java conectarse a procesos de mainframe probados.
__________
10  Una herramienta de gestión de configuración de software con una
­arquitectura basada en flujos. AccuRev abarca complejos entornos de
desarrollo paralelos y distribuidos, acelera el proceso de desarrollo y mejora
la reutilización de activos. Fuente: www.borland.com/Products/Change-
Management/AccuRev
5
Informe técnico oficial
Ejemplos prácticos de DevOps para empresas de mainframe
La integración de Enterprise Analyzer y Enterprise Developer para System z
en el ciclo de vida del desarrollo basado en JAVA puso las mejores
prácticas establecidas de mainframe a disposición de una nueva raza
de desarrolladores de Agile.
Enterprise Developer para System z ofrecía a los desarrolladores un
entorno de desarrollo de mainframe con todas las funciones que se
ejecutaba en Windows sin depender de la plataforma de mainframe del
host. Mientras tanto, Analyzer proporcionaba el conocimiento y los es-
tándares de codificación y Enterprise Developer ofrecía el IDE moderno
basado en Eclipse para desarrollar y mantener el código del mainframe.
Para respaldar todo esto, los sistemas distribuidos de control de fuente
de código abierto, junto con Jenkins, ponían el entorno de integración
continua que permite la creación y las pruebas bajo solicitud.
El resultado:
A los nuevos empleados les resultaba más fácil la transición a proyec-
tos de mainframe y los programadores experimentados en mainframe
podían aprovechar las técnicas modernas de desarrollo ágil. Esto se
tradujo en:
Productividad de desarrollo mejorada, utilizando herramientas
modernas en un entorno de desarrollo ágil
Distribución más rápida de los cambios de mantenimiento y una
mejora significativa en la calidad del código entregado al cliente,
lo cual minimiza el riesgo de inactividad de la producción
Menor dependencia del mainframe: una tarea de compilación de
aplicación completa se ha reducido de un día en el mainframe a
23 minutos con Enterprise Developer
Eliminación de tiempos de espera innecesarios y reducción del
consumo de MIPS del desarrollo en el mainframe
Las habilidades ya no son motivo de preocupación, porque la
edad media del desarrollador de mainframe para este cliente se
ha reducido a 26 años
Materialización del modelo DevOps:
Los resultados de este escenario hacían posibles genuinos objetivos
de TI:
Ciclos de desarrollo más cortos: aprovechar el poder de la
estación de trabajo para acortar el desarrollo de mainframe y
los ciclos de pruebas de las unidades significa que los nuevos
productos y funciones están disponibles de manera más rápida.
Mayor velocidad de publicación de aplicaciones: un aumento de la
productividad en el desarrollo de aplicaciones gracias al empleo
de las mejores herramientas para desarrolladores de su clase con
la tecnología IDE más avanzada mejora los resultados hasta en un
40 por ciento.
Detección de defectos mejorada: al eliminarse los cuellos
de botella se reducen los riesgos a la hora de cumplir las
­programaciones de entrega debido a los desafíos en materia de
calidad, gasto y tiempo.
Reducción del gasto en desarrollo y operaciones: una
­integración incompleta equivale a una adopción inadecuada
6
por parte de los desarrolladores, lo que aumenta el gasto
en p­ roductividad. Un IDE más moderno y eficiente vincula al
­desarrollador con procesos y tecnología de mainframe de
confianza que funcionan, y reduce el gasto.
Escenario C: Rápida provisión y distribución del
entorno de pruebas
Provisión de apoyo continuo a la integración y pruebas de proyectos
paralelos.
Perfil del cliente:
Este cliente es una de las compañías aseguradoras generales más
grandes de Australia. Sus negocios en Asia y el Reino Unido emiten
9000 millones de dólares en primas de seguros cada año y emplean a
unas 13 600 personas. Sus principales sistemas de producción empre-
sarial se ejecutan en sistemas de mainframe de 4000 MIPS.
El desafío:
En los últimos tres años, la funcionalidad empresarial principal de la
aplicación de seguros se ha triplicado. La demanda superó la provisión
de entornos de prueba de mainframe y, sin inversiones importantes
previstas en más capacidad de pruebas de mainframe, su capacidad
para satisfacer las necesidades de la empresa se veía negativamente
afectada. Esto se traducía en largos períodos para la comercialización
de los cambios en la aplicación. Necesitaban una solución.
La solución:
Proporcionar nuevas regiones de prueba en cuestión de
horas en lugar de días o semanas, como era el caso en el
­mainframe. Gracias al acceso más rápido al entorno de prueba,
los desarrolladores pudieron conocer más rápido la respuesta
ante los cambios en el código.
Ofrecer la flexibilidad de ampliarse a demanda, lo que permite
­realizar pruebas simultáneas de varios proyectos y elimina los
cuellos de botella en el desarrollo.
Trasladar las pruebas que queden a los equipos de desarrollo,
a fin de permitir una identificación más temprana de los problemas
de integración.
La opción elegida fue Micro Focus Enterprise Test Server® (ETS). Al ser
clientes de Enterprise Developer, comprendieron el valor de las herra­
mientas modernas de desarrollo y podían comprender cómo la capa-
cidad de pruebas de mainframe de ETS basadas en Windows permitía
eliminar los cuellos de botella de las pruebas y el desarrollo.
El resultado:
Ahora que está totalmente implantado, ETS se encuentra perfecta­mente
integrado en sus procesos de desarrollo. Un cambio en la aplicación
activa automáticamente las versiones de la aplicación y los compo-
nentes se generan automáticamente con Enterprise Developer. Una
región de prueba se inicia automáticamente en un entorno virtualizado
y los módulos de carga de la aplicación procedentes del proceso de
generación que se copia están preparados para la prueba.
Las regiones de prueba están preparadas en cuestión de minutos, lo que
ofrece a los equipos de desarrollo un acceso mucho más rápido a un
entorno en el que pueden probar sus cambios. Esto significa que los pro-
blemas se identifican y se solucionan en una fase anterior del proceso.
El empleo de Enterprise Test Server en un entorno virtualizado permite
acceder a un número prácticamente ilimitado de instancias de Test
Server. Se pueden ampliar a demanda, lo que permite probar varias
versiones del producto en paralelo.
El entorno de mainframe sigue proporcionando la plataforma de prueba
final antes de aplicar los cambios en producción pero, gracias a la fle-
xibilidad que ofrece Enterprise Test Server y a todas las pruebas que
se pueden realizar, se evita la aparición de problemas con el ciclo ya
avanzado. El resultado neto es que pueden responder a la exigencia
de la empresa de un aumento en la entrega de proyectos y han visto
un aumento de calidad de las aplicaciones.
Materialización del modelo DevOps:
Los resultados de este escenario hacían posibles genuinos objetivos
de TI:
Mayor velocidad de publicación: un aumento de la productividad
en el desarrollo de aplicaciones gracias al empleo de las mejores
herramientas para desarrolladores de su clase con la tecnología
IDE más avanzada mejora los resultados hasta en un 40 por ciento.
Detección de defectos mejorada: al eliminar los cuellos
de botella se reducen los riesgos a la hora de cumplir las
­programaciones de entrega debido a los desafíos en materia de
calidad, gasto y tiempo.
Menos errores de implantación y reversiones: esto permite a
las organizaciones de TI de mainframe realizar pruebas previas a
la producción en hardware económico básico, lo que mejora los
índices de éxito y evita gastos y retrasos innecesarios.
Reducción del gasto en desarrollo y operaciones: una
­integración incompleta equivale a una adopción inadecuada
por parte de los desarrolladores, lo que aumenta el gasto
en productividad. Un IDE más moderno y eficiente vincula
al desarrollador con procesos y tecnología de mainframe de
­confianza que funcionan, y reduce el gasto.
Conclusión
Los líderes de TI que deseen adoptar la filosofía de DevOps de una ma-
yor colaboración y unificación dan prioridad a la eficiencia en su estra-
tegia de negocio. Al modernizar la entrega de servicios de aplicaciones
z/OS, optimizan todos los aspectos de la distribución de aplicaciones
de mainframe, lo que reduce el gasto, elimina los cuellos de botella y
acelera la innovación.
Para el propietario del mainframe, DevOps nunca será la panacea que
resuelva años de complejidad de aplicaciones, procesos de desarrollo
__________
11  www.ibm.com/ibm/devops/us/en/
12  www.microfocus.com/assets/visual-cobol-modernization-val_tcm6-
174466.pdf
en silos y todas las prácticas obsoletas que contribuyen a la aparición de
los problemas que afligen a los directores de información modernos, en
concreto la conformidad con la normativa, el plazo de rentabilización y la
pérdida de especialización en el sector. No hay ningún programa plug-
and-play de DevOps que aborde todos estos problemas en su totalidad.
Sin embargo, el software que puede alcanzar los ideales de DevOps
en cuanto a planificación, colaboración en el desarrollo, comprobación,
lanzamiento y distribución, supervisión, respuesta y optimización en un
ciclo continuo sí que existe. Como demuestran los distintos escenarios
descritos en este documento, las empresas con prácticas y tecnologías
basadas en mainframe establecidas desde hace mucho tiempo pueden
introducir nuevos niveles de flexibilidad y agilidad.
Porque, aunque los nombres cambien (DevOps no es más que la última
etiqueta que le hemos puesto a la búsqueda continua por ahorrar en
gasto y mejorar el rendimiento), siempre aspiraremos a la eficiencia. Al
fin y al cabo, ¿no es siempre eso lo que queremos? Por lo tanto, es lógico
que las organizaciones se planteen si las interpretaciones de DevOps
para mainframe encajan en el perfil de su organización.
Rosalind Radcliffe, directora de arquitectura para la gestión colaborativa
del ciclo de vida y de DevOps en IBM, reconoce que DevOps tiene un
lugar en el panorama del mainframe. Para Radcliffe e IBM11, DevOps
ofrece “la capacidad de una distribución continua de software que per-
mite [a los propietarios del mainframe] aprovechar las oportunidades del
mercado y reducir el tiempo de respuesta de los clientes”.
Como principal analista de Forrester, Amy DeMartine señala que
DevOps tiene algo para muchas organizaciones. “DevOps no trata de
borrar las diferencias entre las dos disciplinas; desarrollo de software
y operaciones de TI, sino que tiende un puente para que colaboren
mejor mientras siguen los procesos tradicionales de cada disciplina
por separado”.
Sin embargo, ella misma añade que esta sigue siendo una tarea pen-
diente para muchas empresas. “Todavía estamos en ello”, comenta, “pero
creo que, en un plazo de diez años, miraremos atrás y nos preguntare-
mos por qué lo hicimos de otra manera”.
Si desea descubrir cómo un planteamiento de DevOps podría mejorar
los resultados empresariales de su organización, póngase en contacto
con nosotros para conocer cómo nuestro servicio de valoración de
perfil12 podría representar el primer paso en el camino hacia la moder-
nización de su proceso de desarrollo de aplicaciones.
Acerca de Micro Focus
Desde 1976, Micro Focus ha ayudado a más de 20 000 clientes
a aprovechar el valor de su lógica empresarial mediante la crea-
ción de soluciones de capacitación que cubren la brecha entre las
tecnologías bien establecidas y la funcionalidad moderna. Las dos
carteras contribuyen a un único objetivo claro: ofrecer productos
innovadores respaldados por un servicio de atención al cliente
excepcional. www.microfocus.com
7
 Argentina
+54 11 5258 8899

Chile
+56 2 2864 5629

Colombia
+57 1 622 2766

México
+52 55 5284 2700

Panamá
+507 2 039291

España
+34 91 781 5004

Venezuela
+58 212 267 6568

Micro Focus
Sedes corporativas
Reino Unido
+44 (0) 1635 565200

www.microfocus.com

162-ES0027-001 | M | 11/15 | © 2015 Micro Focus. Todos los derechos reservados. Micro Focus, el logotipo de Micro Focus, AccuRev y Enterprise Test Server,
entre otros elementos, son marcas comerciales o marcas comerciales registradas de Micro Focus o sus compañías subsidiarias y filiales en Reino Unido, Estados Unidos
y en otros países. Todas las demás marcas pertenecen a sus respectivos propietarios.