DevOps empresarial: reducción del riesgo de los cambios a través de herramientas y buenas prácticas por Kevin Parker, vicepresidente de marketing mundial de Serena Software (ahora Micro Focus), febrero de 2016

Informe oficial

Índice página

¿Por qué DevOps y por qué ahora? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

El DevOps empresarial es diferente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Logros del DevOps empresarial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Conjunto de herramientas de infraestructura de DevOps esencial de Micro Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Más información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

DevOps Drive-In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Profesionales de DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Eventos de DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Grupo de pares de DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1www.microfocus.com

¿Por qué DevOps y por qué ahora?

No hay nada más importante para TI que entregar a tiempo el software al equipo de producción .

Cumplir este propósito siempre ha sido más difícil de lo que debería, ya que los equipos de

desarrollo y operaciones se han centrado en objetivos diferentes y contradictorios . En la última

década, la complejidad de los lanzamientos y las consecuencias de los fallos ha aumentado

crecido de manera sorprendente . Conforme se van sucediendo cambios en la metodología, la

tecnología y los mercados, resulta esencial que los equipos de desarrollo y operaciones ejecuten

las modificaciones de software sin contratiempos.

El equipo comercial exige más cambios (tanto de volumen como de velocidad) y la eliminación del

riesgo (es decir, seguridad y conformidad) . El departamento de desarrollo, por su parte, responde

a las presiones por adaptarse al tiempo de comercialización con enfoques más iterativos para la

entrega de software, pero esto satura a los encargados de los cambios y versiones, quienes, a su

vez, se ven forzados a ejercer un control más permisivo o afrontar aumentos significativos de las

cargas de trabajo . El equipo de operaciones mitiga el riesgo inherente de los cambios continuos

con más restricciones y mayor escrutinio, de manera que el péndulo vuelve a inclinarse y obliga al

departamento de cambios y versiones a ofrecer mayores niveles de control y restricciones .

La única manera de encontrar un equilibrio radica en cambiar todos los paradigmas . Los

responsables de desarrollo, a veces vistos como abanderados del cambio que, incansables, causan

inestabilidad, y los encargados de operaciones, caricaturizados como guardianes de la constancia

invariable de los sistemas, son en realidad equipos de profesionales altamente experimentados

y preparados que tienen el mismo objetivo: entregar los sistemas de software que necesita la

empresa de manera segura .

De esa concepción nace DevOps, que aúna la responsabilidad de los equipos de desarrollo y

operaciones respecto a los cambios que requiere la empresa, la estabilidad de los sistemas y

las exigencias del departamento comercial . Para los profesionales del desarrollo, esto implica

centrarse más en la calidad, la fiabilidad y el impacto externo. Para los encargados de las

operaciones, por su parte, significa optimizar los controles, automatizar las actividades y agilizar

los procesos . De esta forma, el equipo de desarrollo invierte en la estabilidad de los sistemas y el

de operaciones posibilita la velocidad de implantación .

En la última década, la complejidad de los lanzamientos y las consecuencias de los fallos ha aumentado crecido de manera sorprendente. Conforme se van sucediendo cambios en la metodología, la tecnología y los mercados, resulta esencial que los equipos de desarrollo y operaciones ejecuten las modificaciones de software sin contratiempos.

2

Informe oficialDevOps empresarial: reducción del riesgo de los cambios a través de herramientas y buenas prácticas

Para los puristas de DevOps, este enfoque puede conllevar cambios aún mayores y más radicales

en el sistema de diseño de aplicaciones; un planteamiento totalmente nuevo respecto a la

infraestructura que impulsa el desarrollo, la entrega y la ejecución; y una reestructuración

completa a nivel organizativo desde el departamento comercial hasta el de desarrollo, pasando

por el de operaciones y, finalmente, DevOps. Los microservicios, muy apreciados en Amazon.com,

liberan la funcionalidad de las aplicaciones de las limitaciones de uso y permiten reinventarse y

redefinir los objetivos de manera constante, de forma que cambian por completo el concepto de

aplicación. Al combinar de manera flexible herramientas ligeras y desechables, normalmente,

software de código abierto (OSS), se potencia la creatividad y la experimentación, al tiempo que

se mejora la velocidad . Los equipos de proyecto se transforman en equipos de producto que se

integran con el departamento comercial y se responsabilizan de los resultados, desde el origen de

la idea hasta la implantación e incluso la ejecución del producto a nivel operativo .

En la nueva economía, este tipo de transformación digital1 es clave para mantener la

competitividad, y no resulta difícil ver por qué empresas de la talla de Facebook, Salesforce .com

y Google han reinventado su modelo de desarrollo y entrega . Los métodos de trabajo de estas

empresas también están evolucionando hacia la microexternalización2 y el empleo eventual3,

importantes factores que están impulsando la necesidad de contar con más herramientas de

automatización y colaboración para gestionar este personal dinámico y flexible.

Pero, ¿qué pasa con las grandes empresas altamente reguladas (HRLE) de todo el mundo? ¿Cómo

pueden adoptar la cultura DevOps?

El DevOps empresarial es diferente

Kurt Bittner y Amy DeMartine, analistas de Forrester, lo explicaban así hace poco4 en SD Times:

“nos hemos dado cuenta de que la adopción de DevOps varía significativamente de un tipo de

aplicación y sector a otro debido a las diferencias en el grado de sofisticación de los clientes, las

limitaciones normativas y los factores de competitividad” . Su estudio corrobora con exactitud la

experiencia de Micro Focus . Desde nuestro punto de vista, la adopción de DevOps está liderada

por aquellas empresas orientadas hacia el tiempo de comercialización y altamente reguladas .

Aunque el resto no se está quedando atrás, y muchas otras están avanzando rápidamente tras

ellas . DevOps se está adoptando cada vez más incluso en el sector público y en otros sectores

caracterizados tradicionalmente por evolucionar más despacio . De hecho, forma parte de la

agenda de cualquier director de sistemas de información (CIO) .

_______________________________________________________________

Desde el punto de vista de Micro Focus, la adopción de DevOps está liderada por aquellas empresas orientadas hacia el tiempo de comercialización y altamente reguladas.

__________

1 El grupo de analistas Altimeter define la transformación digital como “una reestructuración o nueva inversión en tecnología y modelos empresariales para interactuar de manera más efectiva con clientes digitales en cada punto de contacto del ciclo de vida de la experiencia del cliente”.

2 Un cambio por el que, en lugar de contratar empleados, se recurre a proveedores y personas independientes con servicios y conocimientos especializados.

3 Los empleados eventuales son un grupo temporal de trabajadores que trabajan en una empresa de manera no permanente.

4 SD Times, Where’s the heat in DevOps (Tendencias en DevOps), 01/02/2016

3www.microfocus.com

Las grandes empresas altamente reguladas (HRLE) se están enfrentando a restricciones únicas

que dificultan la adopción de prácticas puras de DevOps. Las HRLE tienen que abordar retos

excepcionales relacionados con los problemas de conformidad, arquitecturas de aplicaciones

modernas frente a las legadas, presiones en materia de recursos, equipos dispares y distribuidos

en distintos lugares, TI multimodal, interdependencias de aplicaciones y capacidad de

ampliación .

Separación de tareasLa separación de tareas (SoD, también denominada “segregación de tareas”) es un respetado

principio que defiende que los individuos con una responsabilidad específica dentro de la

empresa no pueden ser también quienes revisen y aprueben las acciones relacionadas con dicha

responsabilidad . O, como muchos han descrito, no se puede ser cazador y guardabosques . Para

bastantes profesionales de TI, la primera vez que se toparon con este requisito fue a raíz de la ley

Sarbanes-Oxley, que nació como resultado de la crisis financiera ocurrida entre los años 2000 y

2003.

Los auditores internos están pidiendo cada vez más que se siga el principio SoD en sus procesos

de TI . En las conferencias sobre riesgo y conformidad, la evaluación de riesgos de seguridad de TI

se incluye con frecuencia como uno de los temas principales, y se está advirtiendo a los directores

de seguridad de la información (CISO)6 y a los auditores de la necesidad de revisar estrechamente

las prácticas y procesos de TI . Debido al miedo al fracaso se están implantando reglas rápidas

y complicadas (como sucedió con el desastre de Knight Capital7) . Son comunes mandatos del

tipo: los desarrolladores tienen prohibido implantar código en la fase de producción, los cambios

debe aprobarlos una junta independiente antes de su implantación y los técnicos encargados del

lanzamiento no pueden acceder al código fuente . Y con toda la razón .

Las grandes empresas altamente reguladas (HRLE) se están enfrentando a restricciones únicas que dificultan la adopción de prácticas puras de DevOps.

__________

5 Fuentes: Forrester y Gartner6 CISO, responsable de

seguridad corporativa7 Forbes, 12/08/2012. Knight

Capital Trading Disaster Carries $440 Million Price Tag (El desastre bursátil de Knight Capital le cuesta más de 440 millones de dólares)

Tasa de adopción5

La adopción más rápida

Adopción más rápida

Adopción rápida

Adopción

Adopción más lenta

Quintil Primero Segundo Tercero Cuarto Último

Sistemas de innovación

Fabricación, farmacia, servicios

Fabricación de alta tecnología, servicios financieros

Minoristas, mayoristas

Medios de comunicación, entretenimiento, salud

Energía, minería, servicios públicos, telecomunicaciones

Sistemas de diferenciación

Fabricación, farmacia, servicios, servicios financieros

Fabricación de alta tecnología, minoristas, mayoristas

Servicios públicos, telecomunicaciones, gobierno

Energía, minería, salud

Medios de comunicación, entretenimiento

Sistemas de registro

Fabricación, farmacia, servicios

Fabricación de alta tecnología, servicios financieros

Minoristas, mayoristas, servicios públicos, telecomunicaciones, gobierno

Energía, minería, salud

Medios de comunicación, entretenimiento

Las grandes empresas altamente reguladas (HRLE) se indican en negrita.

4

Informe oficialDevOps empresarial: reducción del riesgo de los cambios a través de herramientas y buenas prácticas

La idea de que un equipo de producto se responsabilice de cada etapa del ciclo de vida de una aplicación es admirable, pero no resulta óptimo para las HRLE.

__________

8 Las organizaciones generativas definen altos estándares y se esfuerzan constantemente por superarlos. Los fracasos se consideran razones para mejorar, no motivos para avergonzarse. Los líderes están al tanto de lo que pasa porque sus empleados se lo cuentan. La información sobre el estado actual es una meta compartida que permite a los equipos prevenir y evitar errores. No se trata de un objetivo utópico, todos saben que los errores suceden y la cultura los acepta siempre que se mitiguen rápidamente, no pasen al siguiente nivel y se aprenda la lección correspondiente.

Sin embargo, SoD dificulta la creación de equipos multidisciplinares de DevOps que incluyan

personal de desarrollo y operaciones que compartan la responsabilidad y propiedad de la

implantación del código, como se defiende en el DevOps más puro. Lo que buscan las HRLE,

en cambio, es una infraestructura de DevOps que requiera la colaboración de los equipos de

desarrollo y operaciones, y les proporcione datos comunes y compartidos sobre las actividades de

lanzamiento . Estas empresas necesitan una capacidad total de seguimiento y auditoría para que,

en caso de fallo, sea posible determinar el punto de error a través de procedimientos de análisis

de causa raíz y, así, implementar cambios en los procesos y en la automatización para evitar que

vuelva a suceder .

Conforme las organizaciones evolucionan hacia “culturas generativas”8, con criterios muy

estrictos, la colaboración se plantea cada vez más como una característica empresarial clave .

Estas organizaciones buscan evitar de manera preventiva posibles “situaciones indeseables”

relacionadas con la seguridad, las intrusiones y las pruebas de carga como parte de las actividades

de desarrollo esenciales . También debe imponerse la capacidad de seguimiento y el cumplimiento

de los requisitos de auditoría, en lugar de considerarse una solución adicional que se puede

probar para abordar un problema de conformidad .

Especialización y segregaciónAsimismo, las HRLE suelen optimizar con frecuencia sus recursos hasta un nivel excesivo

y dividir las habilidades técnicas . El administrador de bases de datos es el especialista que

incorpora los cambios en la base de datos según sea necesario en función del lanzamiento de

una aplicación . Los empleados generalistas de los equipos de desarrollo, operaciones o DevOps

no cuentan con este permiso . De hecho, a menudo se produce una segregación física (y técnica)

de los entornos de producción y de desarrollo . El traspaso de código de uno a otro requiere

una transferencia de elementos segura, especial, aprobada y, con frecuencia, confidencial.

Normalmente, esta actividad secreta se realiza en lo que podríamos denominar “reuniones del

millón de dólares”, en las que se reúnen las partes implicadas del departamento comercial, de

desarrollo y de operaciones, dos o tres veces a la semana, para revisar y aprobar la implantación

de código . Todo esto hace que colaborar y compartir responsabilidades resulte cada vez menos

práctico .

Aunque para los puristas se trata de importantes problemas que afectan a la manera de implantar

DevOps en las HRLE, no evitan la aplicación de iniciativas de DevOps altamente satisfactorias .

La idea de que un equipo de producto se responsabilice de cada etapa del ciclo de vida de una

aplicación es admirable, pero no resulta óptimo para las HRLE . El gran volumen de requisitos

de conformidad que no tienen nada que ver con la aplicación, aunque aun así deben cumplirse

y poder demostrarse, exige una especialización excepcional . La arquitectura subyacente de

aplicaciones en n niveles es compleja debido a las capas de seguridad incorporadas, los problemas

de compatibilidad con sistemas legados y la necesidad de controles externos. Además, requiere de

técnicos expertos en aplicaciones empresariales que puedan gestionarla y permitir su evolución .

5www.microfocus.com

Encontrar un único recurso que reúna todas las habilidades técnicas necesarias para abordar

todos estos retos es muy difícil y muy caro . Llevar a la práctica el objetivo de DevOps de contar

con un solo equipo multifuncional resulta muy complicado, ya que el mercado laboral carece de

un gran número de expertos con distintas habilidades técnicas, formados y de confianza. Sustituir

el equipo actual y sus conocimientos del sistema o actualizar por completo todas sus habilidades

de la noche a la mañana no son opciones realistas .

Incluso la simple necesidad de poder intercambiar las funciones de los miembros del equipo para

cumplir las necesidades de recursos de un proyecto implica que los desarrolladores, los técnicos

de calidad y los expertos de fabricación no estén demasiado vinculados a una sola tecnología o a

un único conjunto de herramientas .

Seguridad y estabilidadA medida que aumenta la presión por lanzar aplicaciones a mayor velocidad, también lo hace la

libertad y la autonomía de los equipos de desarrollo. Al mismo tiempo, se corre el riesgo de dejar

puertas abiertas (o más bien, una puerta trasera) que los delincuentes puedan usar para acceder a

sistemas internos, aplicaciones orientadas al consumidor y, quizás lo más peligroso de todo, datos

confidenciales de los clientes. Las API están agilizando la integración entre proveedores, partners

y diversas plataformas para impulsar el desarrollo rápido de aplicaciones. La adopción de API, sin

embargo, también puede conllevar riesgos si no se cuenta con una gestión de API real que se adapte al

volumen, controle adecuadamente el acceso y permita desechar las API cuando dejen de ser necesarias

para evitar dejar un punto de entrada no seguro . En la misma línea, el apremio por descubrir el valor

de los contenedores debe estar en equilibrio con las consideraciones y barreras de seguridad .

AmpliaciónNo faltan las empresas de software que quieren persuadir a sus clientes de que su tecnología

resulta esencial para el éxito de DevOps . Muchas de ellas abordan el pilar de la “automatización”

del credo de DevOps, y algunas pueden ofrecer un ahorro significativo de tiempo y esfuerzo frente

a los métodos manuales . Sin embargo, el hecho de que muchas herramientas sean de código

abierto y ofrezcan versiones de evaluación gratuitas puede conducir a una proliferación de su uso

sin coordinación alguna ni mayor consideración .

Los sistemas legados son legendariosAunque se trate de tecnología con 5 años de antigüedad, sigue procesando más transacciones

diarias de lo que hace Internet . El mainframe, para la mayoría de HRLE, es la herramienta de

referencia para el procesamiento de transacciones de la empresa . Los sistemas que se ejecutan en

ellos aún contienen código escrito antes de obtener la primera señal de WiFi de Sputnik . En este

momento, se están ejecutando miles de millones de líneas de código que mantienen las empresas

en funcionamiento, y que no pueden sustituirse por microservicios de un día para otro . De hecho,

el valor que aportan rara vez supera al gasto que conlleva implementarlos . Y el riesgo que implica

llevar a cabo una modificación masiva de este tipo es demasiado grande. Muchas empresas están

añadiendo tecnología nueva a sus sistemas legados, con la esperanza de poder sustituirlos por

completo algún día .

No faltan las empresas de software que quieren persuadir a sus clientes de que su tecnología resulta esencial para el éxito de DevOps.

6

Informe oficialDevOps empresarial: reducción del riesgo de los cambios a través de herramientas y buenas prácticas

DevOps ha formado parte del entorno de mainframe desde el principio. Aunque no se llamaba

DevOps, contenía todos sus principios, y sus enfoques y cultura estaban centrados en la propiedad

compartida del éxito de un lanzamiento . En la actualidad, los recursos que dan soporte al

mainframe son cada vez más nuevos, de forma que sigue aumentando la disposición por adoptar

nuevos enfoques y metodologías, al tiempo que se va eliminando el planteamiento de silo y

plataforma .

Por ello, la transición a los microservicios resulta razonable y práctica para una empresa creada

hace solo unos años, pero no tanto para una empresa más antigua. Aunque hay bastantes

aplicaciones de mainframe diseñadas con un SOA9, ninguna de ellas ha adoptado por completo

los microservicios . Las HRLE están transformando sus soluciones de mainframe para satisfacer

las necesidades de los puristas que no están a favor del mainframe y que ya han realizado la

transición . Por ello, se ven rodeadas de sistemas legados con modernas aplicaciones que mejoran

y sustituyen algunas de las funcionalidades originales. A pesar de que este cerco para sustituir el

código antiguo no es el fin en sí mismo, añadir microservicios a las antiguas aplicaciones es un

modo de alcanzar el objetivo empresarial antes .

Es posible, y recomendable, adoptar DevOps con sistemas legados . Las empresas no son “puras”,

y nunca lo serán, pero siempre pueden ir más rápido, ofrecer mejor calidad y ser más predecibles

y fiables. Cualquier aplicación de mainframe puede aplicar los principios de DevOps y seguir

mejorando su tasa de entrega de manera significativa.

Logros del DevOps empresarial

Los líderes de pensamiento del movimiento DevOps10 han determinado que el camino hacia una

implantación correcta depende de cinco principios, conocidos por el acrónimo CALMS11, que

enumeramos a continuación:

Cultura: responsabilizarse de los cambios para fomentar la colaboración y la comunicación

Automatización: eliminar los pasos manuales de la cadena de valor

Eficacia: usar principios eficaces para permitir una mayor frecuencia de ciclo

Métricas: medir todo y usar datos para ajustar los ciclos

Uso compartido: compartir experiencias, buenas o malas, de las que otros puedan aprender

Cualquier aplicación de mainframe puede aplicar los principios de DevOps y seguir mejorando su tasa de entrega de manera significativa.

__________

9 Arquitectura orientada a los servicios

10 Gen Kim, Damon Edwards, Jez Humble, John Willis et al

11 Originalmente, 4 principios conocidos como CAMS

7www.microfocus.com

A fin de implantar la automatización correcta en los procesos, deben consolidarse los tres tipos de procesos (documentados, no documentados y prácticas de trabajo).

En nuestra opinión, el orden de estos principios debería intercambiarse para llevar la cultura

al final, ya que resulta muy complicado cambiar orgánicamente una cultura sin automatizar

primero los procesos, y así eludir ese deseo humano de hacer las cosas “a la antigua usanza” . La

automatización hace realidad los procesos de manera tangible y visible, al tiempo que permite

volver a evaluar y optimizar metódicamente los procesos, de forma que sean más rápidos y

eficaces.

La automatización brinda una telemetría (registros de cada acción, usuario, lugar, elemento,

método y motivo) que resulta muy necesaria para proporcionar una medición detallada de

las actividades, así como la capacidad para visualizar los datos en consolas compartidas por

los equipos de desarrollo y operaciones, además del resto de partes implicadas . Conforme los

recursos, las propiedades y los métodos evolucionan, todos pueden ver en sus consolas en tiempo

real el impacto positivo (o negativo) de estos cambios, de forma que se hace posible una mejora

continua y todos los participantes pueden compartir los resultados. Esto, en definitiva, conduce a

un cambio cultural duradero, que constituye el sello distintivo de DevOps .

No se puede subestimar la importancia del patrocinio ejecutivo para efectuar una transformación

cultural de este tipo . La automatización también es fundamental para reforzar el compromiso

y la inversión continuos de los ejecutivos . Puesto que la automatización aporta datos sobre las

mejoras de calidad, plazos de entrega, finalización de proyectos y eficiencia, se refuerzan las

razones por las que esta iniciativa es importante y se obtienen pruebas para demostrar el retorno

de la inversión (ROI) que justificó inicialmente la decisión.

Hay que tener en cuenta que no es aconsejable automatizar un proceso incorrecto . Durante el

proceso de revisión, el sentido común resulta fundamental como punto de partida . También hay

que ser cautos para no caer en la trampa de la “parálisis del análisis” y replantearse demasiado los

procesos existentes para tratar de optimizarlos por completo antes de automatizarlos . Es mucho

más fácil modificar y mejorar un proceso automatizado que uno sobre el papel.

Para implantar la automatización correcta en los procesos, se deben consolidar los tres tipos de

procesos (documentados, no documentados y prácticas de trabajo) . De esta forma, se obtiene una

excelente oportunidad para aplicar el sentido común a la hora de simplificar tareas y hacerlas más

eficaces siempre que sea posible.

La automatización es vital para que DevOps sea un éxito en las HRLE . Para promover la

colaboración y cooperación necesarias para ser efectivos, la tecnología debe proporcionar acceso

a los datos relevantes para lograr esa efectividad . Gracias a la automatización, es mucho más fácil

alcanzar un nivel de apertura y entendimiento del estado actual que a través de interminables

reuniones y conferencias telefónicas .

8

Informe oficialDevOps empresarial: reducción del riesgo de los cambios a través de herramientas y buenas prácticas

Como inversión mínima en tecnología para dar soporte a su iniciativa de DevOps empresarial,

tenga en cuenta estas cuatro tecnologías como punto de partida básico . Cada una de ellas aborda

una dificultad fundamental de DevOps. Puede implantarlas en cualquier orden y conectarlas de

cualquier manera a medida que evolucione su estrategia de DevOps . Empiece con aquella que le

permita encarar sus mayores preocupaciones al iniciar un programa de DevOps .

1. Plataforma de colaboración de DevOps para que los equipos comerciales, de desarrollo y de operaciones tengan una clara visibilidad de todo lo que pasa. A veces denominada “canal de DevOps”, se trata de una característica que conecta el flujo de cadena de herramientas de las tecnologías que dan soporte a las actividades de lanzamiento e implantación. Los datos comunes y compartidos deben estar accesibles y mostrar el estado de todas las actividades del equipo de proyecto (y de producto) desde el inicio del desarrollo hasta la entrega segura a la fase de producción. Además, la consola, las alertas, las notificaciones y las aprobaciones también deben integrarse en una infraestructura común de DevOps.

2. Automatización de la implantación de DevOps que permite ofrecer una entrega de aplicaciones fiable, predecible y que se puede repetir a través de del canal de implantación hasta llegar a la producción. La compatibilidad automatizada con las iniciativas de implantación continua12 es esencial, puesto que permite reutilizar técnicas de implantación comunes (copia de seguridad de la base de datos, restablecimiento de la configuración del servidor, arranque del servidor web, etc.). Los procesos de recuperación y restitución automatizados minimizan el tiempo de inactividad y garantizan que los servicios sigan funcionando. Los técnicos encargados de la fabricación y el lanzamiento pasan más tiempo optimizando y ajustando las implantaciones que escribiendo guiones desechables, lo que da como resultado una mejora continua del rendimiento, la conformidad y la calidad.

3. Repositorio de elementos seguro de DevOps que representa una “única versión de la verdad”. A los encargados de operaciones siempre les ha preocupado introducir innumerables cambios en el entorno de producción desde demasiados sitios diferentes. La calidad, fiabilidad y transparencia siempre deben ser las mismas, independientemente del tamaño o la complejidad del origen de los cambios. El primer paso importante es contar con un único repositorio de elementos seguro. El equipo de desarrollo realiza las entregas en este repositorio común, donde se aplica un conjunto de pruebas estándar. Así se garantiza siempre un nivel mínimo de calidad común. A partir de aquí, el código puede ir pasando por todo el ciclo de vida hacia la producción (consulte el número 2). En términos de ITIL, a esto se le denomina Biblioteca de medios definitivos (DML).

4. Infraestructura de DevOps para equipos Agile para reforzar la dedicación del equipo de desarrollo, que usa métodos iterativos de creación y entrega de software. La integración continua es una característica clave de los equipos de desarrollo Agile. La gestión de versiones (bifurcación y fusión) es esencial y resulta fundamental para entender qué código se está usando en cada parte de los canales de entrega. Es necesario que la gestión de los elementos de tarea y del trabajo pendiente (logros e historias) se lleve a cabo sin incidencias para asegurarse de que los equipos de operaciones, de desarrollo y comercial trabajan en la misma línea. Contar con una solución empresarial ampliada que satisfaga las necesidades del equipo de entrega y desarrollo Agile es vital, pero también debe cumplir los requisitos de los responsables de supervisión de la empresa.

Con la tecnología como punto de partida, la migración a DevOps puede empezar .

Contar con una solución empresarial ampliada que satisfaga las necesidades del equipo de entrega y desarrollo Agile es vital, pero también debe cumplir los requisitos de los responsables de supervisión de la empresa. __________

12 La implantación continua (Continuous Deployment, CD) requiere que los elementos de aplicaciones fluyan automáticamente de un entorno a otro tras completar correctamente las pruebas necesarias (automatizadas o manuales).

9www.microfocus.com

Resumen

El objetivo de DevOps es siempre el mismo, sin importar de qué entorno se trate: reducir

el riesgo de los cambios mediante herramientas y buenas prácticas . Hay diferencias que es

importante entender .

_______________________________________________________________

DevOps es en parte responsable del aumento de volumen y velocidad de los lanzamientos

impulsados principalmente por la introducción de métodos Agile en la entrega y el desarrollo

de software. No olvidemos que el Manifiesto de Agile afirma que nuestra mayor prioridad es

satisfacer al cliente mediante la entrega temprana y continua de software que aporte valor .

Esto significa que tanto Agile como DevOps se centran en la velocidad del desarrollo, pero

no a expensas de la calidad. De hecho, según Kurt Bittner, de Forrester, el movimiento Agile

debe considerarse parte del movimiento de DevOps, especialmente cuando nos referimos a

las HRLE .

Como demuestra Gartner en sus taxonomías de arquitectura por capas13 y TI bimodal14, el

DevOps empresarial debe estar preparado no solo para gestionar las series de versiones

creadas a alta velocidad por los equipos Agile, sino también aquellas más lentas y pesadas de

los equipos con una organización más tradicional . El DevOps empresarial necesita su propia

arquitectura para dar soporte tanto a las versiones incrementales de interacción mínima a

pedido como a otras con mayor escrutinio que lleven meses en el calendario .

No olvidemos que el Manifiesto de Agile afirma que nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software que aporte valor. __________

13 La arquitectura por capas clasifica las aplicaciones como sistemas de innovación, sistemas de diferenciación y sistemas de registro. Cada uno de ellos se diferencia por sus tecnologías básicas, la tasa de cambio y la importancia para el negocio, ya que esto afecta a la inversión que reciben.

14 La TI bimodal sugiere que TI tiene dos velocidades de desarrollo. Para los sistemas de innovación, se usa el modo 2: alta velocidad, desarrollo iterativo. Para los sistemas de registro, se usa el modo 1: velocidad lenta, desarrollo de bajo riesgo. Micro Focus reconoce que las HRLE tienen una TI de velocidad variable con varios enfoques de desarrollo diferentes para adaptarse a los requisitos de tiempo de comercialización, conformidad, riesgos, tecnología, metodología y topología.

DevOps DevOps empresarial

Equipos de Agile puro TI de velocidad variable

Miembros de un equipo multidisciplinar El equipo mantiene la separación de tareas (SoD)

Diseñado principalmente para los equipos de desarrollo y operaciones

Diseñado principalmente para los equipos de cambios y versiones

Variación limitada en cuanto a plataformas, tecnología y conjuntos de herramientas

Amplia variedad de plataformas, tecnología y conjuntos de herramientas

Normalmente, pequeños equipos en una misma ubicación Normalmente, grandes equipos distribuidos en distintos lugares

La microexternalización y el personal eventual son frecuentes Externalización en el exterior frecuente

Cultura de conformidad flexible Cultura de conformidad estricta

Dependencias limitadas entre proyectos, microservicios Dependencias complejas entre proyectos

Experimental, pruebas A-B, cultura del fallo rápido Cultura del avanzar rápido sin romper nada

Propiedad distribuida Cultura de especialistas, centralizada

El equipo que desarrolla la aplicación también la ejecuta El equipo que desarrolla la aplicación es distinto del que la ejecuta

Usa una cadena de herramientas de soluciones de código abierto integrada de manera flexible

Necesita una infraestructura ampliable, segura y compatible con los proveedores

10

Informe oficialDevOps empresarial: reducción del riesgo de los cambios a través de herramientas y buenas prácticas

Conjunto de herramientas de infraestructura de DevOps esencial de Micro Focus

La infraestructura esencial necesaria para que DevOps funcione en la empresa se compone

de cuatro elementos principales . Micro Focus proporciona estos elementos como tecnologías

probadas y comprobadas que las HRLE llevan usando desde hace décadas .

_______________________________________________________________

_______________________________________________________________

Son los siguientes:

Micro Focus® Release Control: los procesos incluidos en la gestión del flujo de implantaciones desde la fase de desarrollo hasta la de operaciones deben ser automatizados, fáciles de entender, transparentes y flexibles. Release Control está diseñado específicamente con ese objetivo. Entre todas sus características, destaca la completa organización e integración de la cadena de herramientas, que proporciona colaboración a nivel de datos y proceso entre distintos usuarios y herramientas. Además de ofrecer automatización de los procesos, alertas, notificaciones, informes, conformidad, seguridad y capacidad de seguimiento, mantiene el portal de colaboración y el calendario compartido que dan acceso a los equipos comercial, de operaciones y de desarrollo a datos comunes y compartidos, sea cual sea el sistema de origen.

El conjunto de herramientas de infraestructura de DevOps esencial de Micro Focus incluye:

Micro Focus Release Control

Micro Focus Deployment Automation

Micro Focus Dimensions Vault

Micro Focus Dimensions CM15

11www.microfocus.com

Micro Focus Deployment Automation: proporciona los medios que permiten mover los elementos de las aplicaciones automáticamente con mínima interacción humana (idealmente, ninguna), lo que garantiza la entrega del contenido correcto en su destino en el momento adecuado con el cumplimiento de todo el conjunto de requisitos. De esta forma, se pueden crear trayectorias fiables, repetibles y predecibles hasta la producción. Deployment Automation puede configurar y gestionar numerosos canales de implantación diferentes.

Micro Focus Dimensions Vault: debe haber una “única versión de la verdad” que represente los elementos de las aplicaciones relevantes para efectuar los cambios necesarios destinados a la producción. De acuerdo con nuestra solución de gestión de configuraciones y cambios de software, Micro Focus ofrece seguridad, fiabilidad y transparencia sin precedentes. Todos los esfuerzos de desarrollo realizados en cualquier otro repositorio deben pasar por el repositorio de elementos seguro, donde tienen que revisarse y validarse antes de llegar a los entornos de prueba y, finalmente, a la fase de producción.

– El almacén se orienta hacia el equipo de desarrollo creando un repositorio seguro y común para el desarrollo por parte de todos los equipos: una única versión de la verdad. Micro Focus proporciona conectores de las herramientas de repositorio comunes (incluidos los repositorios de software de código abierto como Git y Subversion) que permiten que el equipo de desarrollo se autogestione, al tiempo que proporcionan a los miembros corporativos los controles de seguridad, visibilidad y cumplimiento que necesitan.

– El almacén también se orienta hacia el equipo de operaciones creando un repositorio común y seguro como punto de partida para una única trayectoria hacia la producción. Además, puede conectarse directamente con Deployment Automation para crear un flujo contiguo desde la fase de desarrollo hasta la de operaciones, pasando por DevOps.

Micro Focus Dimensions CM15 es la solución de gestión de configuraciones y cambios de software líder para todos los equipos de desarrollo en grandes empresas altamente reguladas. Con un soporte excepcional para los desarrolladores que trabajan en pequeños equipos Agile y para los equipos globales envueltos en proyectos que duran varios años, Dimensions CM es la primera elección para empresas con diversas necesidades de conformidad, plataformas, tecnologías y metodologías. Por sus características de bifurcación y fusión avanzadas, con la posibilidad de predecir y evitar regresiones, análisis de código estático, integración continua, revisión por pares e integración del más amplio conjunto de herramientas de desarrollo, Dimensions CM es la herramienta ideal para el equipo de desarrollo en su transición hacia la entrega continua (CD) y DevOps.

Más información

Consulte el conjunto de herramientas de DevOps de Micro Focus hoy mismo en:

www.microfocus.com

_______________________________________________________________

Consulte el conjunto de herramientas de DevOps de Micro Focus hoy mismo en: www.microfocus.com

__________

15 En el caso de los clientes de mainframe, pueden usar ChangeMan ZMF de Micro Focus con el mismo fin. ChangeMan ZMF es el líder absoluto de la gestión de configuraciones y cambios de software para el desarrollo de mainframe.

12

Informe oficialDevOps empresarial: reducción del riesgo de los cambios a través de herramientas y buenas prácticas

_______________________________________________________________

DevOps Drive-In

Cada trimestre llevamos a cabo una sesión de “DevOps Drive-In”, nuestra popular y exitosa

serie . En ella han participado líderes de pensamiento como Gene Kim, Jez Humble, George

Spalding y Bola Rotibi, analista del sector, además de muchos profesionales que se enfrentan

cada día a los mismos problemas que usted . Puede ver las sesiones de formación a pedido

y registrarse en la próxima aquí: www.microfocus.com/index.php/en/company/

upcoming-events/devops-drivein/

Profesionales de DevOps

Si quiere programar una sesión cara a cara confidencial con uno de nuestros expertos en

DevOps para hablar de alguno de los temas aquí tratados, escriba un correo electrónico a

info@microfocus.com o póngase en contacto con un representante local .

Como parte de nuestro servicio, ofrecemos un análisis completo de nuestros procesos

actuales de entrega y desarrollo, y podemos recomendarle los mejores procedimientos,

políticas, procesos y prácticas para poner en marcha su iniciativa de DevOps . También

podemos brindarle un completo informe de ROI, en el que detallaremos qué mejoras

significativas, y medibles, puede poner en práctica en materia de calidad, cumplimiento

de plazos, finalización de proyectos y conformidad, al tiempo que aumenta el volumen y la

velocidad de sus lanzamientos .

Si quiere programar una sesión cara a cara confidencial con uno de nuestros expertos en DevOps para hablar de alguno de los temas aquí tratados, escriba un correo electrónico a info@microfocus.com o póngase en contacto con un representante local.

13www.microfocus.com

Eventos de DevOps

Todos los meses ofrecemos seminarios web y físicos en todo el mundo acerca de las mejores

prácticas de DevOps empresarial a cargo de nuestros clientes con mayor éxito y de nuestros

propios expertos del sector . Puede encontrar los enlaces a las grabaciones de eventos

anteriores, listas de próximos eventos y enlaces a las páginas de registro en:

www.microfocus.com/index.php/en/company/upcoming-events/

devops-drivein/

También puede suscribirse a nuestros boletines periódicos y examinar ediciones anteriores

en: http://info.microfocus.com/Preference-Center.html

Podemos organizar eventos de carácter informal en sus instalaciones, personalizados para

sus usuarios, a través de líderes de pensamiento, animados debates y consejos prácticos .

Estos eventos son de carácter gratuito . Para solicitar uno, escriba a info@microfocus.

com o póngase en contacto con un representante local .

Grupo de pares de DevOps

Nuestra conferencia anual de usuarios, llamada xChange, es una oportunidad para conocer a

profesionales como usted, debatir acerca de las mejores prácticas y aprender de expertos del

sector . Puede consultar el programa más reciente y registrarse en xChange en:

http://info.microfocus.com/Preference-Center.html/xchange

Puede encontrar los enlaces a las grabaciones de eventos anteriores, listas de próximos eventos y enlaces a las páginas de registro en: www.microfocus.com/index.php/en/company/upcoming-events/devops-drivein/

162-ES0087-002 | S | 04/17 | © 2017 Micro Focus. Reservados todos los derechos. Micro Focus, el logotipo de Micro Focus, Extra!, InfoConnect, Reflection y Rumba+, entre otros, son marcas comerciales o marcas comerciales registradas de Micro Focus o sus empresas subsidiarias y filiales en Reino Unido, Estados Unidos y en otros países. NetIQ y eDirectory son marcas comerciales o marcas comerciales registradas de NetIQ Corporation en EE. UU. El resto de marcas son propiedad de sus respectivos propietarios.

www.microfocus.com

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 FocusSedes corporativasReino Unido+44 (0) 1635 565200

www.microfocus.com