Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
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
[email protected] 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 [email protected] 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