Mejores prácticas de gestión de cambios y lanzamientos de Agile Por Ben Cody, Julian Fish y Amita Abraham Noviembre de 2012

Informe oficial

Índice página

Aluvión de incidentes en la oficina de servicios derivado de una gestión de cambios deficiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

El dilema de la desconexión de DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Mejores prácticas de gestión de cambios y lanzamientos de Agile . . . . . . . . . . . 3Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1www.microfocus.com

Aluvión de incidentes en la oficina de servicios derivado de una gestión de cambios deficiente

El dilema de la desconexión de DevOps

El volumen de los negocios que se realizan en línea es cada vez mayor. A fin de no perder

nivel de competitividad, la organización de TI debe ofrecer continuamente aplicaciones

y servicios innovadores, pues con frecuencia son la parte más visible de su negocio. La

capacidad para introducir cambios en estas aplicaciones rápidamente y sin sacrificar la

estabilidad de la infraestructura ya no es una cualidad meramente atractiva, sino toda una

necesidad .

A fin de no perder nivel de competitividad, la organización de TI debe ofrecer continuamente aplicaciones y servicios innovadores, pues con frecuencia son la parte más visible de su negocio.

Fig. 1

Fuente: Forrester/itSMF Q2 2011 US ITSM Online Survey (Encuesta online sobre ITSM en EE. UU. durante el segundo trimestre de 2011, de Forrester/itSMF)

2

Informe oficialMejores prácticas de gestión de cambios y lanzamientos de Agile

Para dar respuesta a esta necesidad, las organizaciones de desarrollo adoptan metodologías

ágiles. Ahora, pueden transferir al instante las aplicaciones y los servicios nuevos o

actualizados al canal de operaciones de TI. No obstante, esto carga a los equipos de

operaciones de TI con la ardua tarea de implantar los cambios sin introducir otros riesgos

asociados. Las transferencias entre estos dos equipos suelen dejar mucho que desear. Por

ello, no es de extrañar lo que señalan las investigaciones recientes*: más del 40 % de los

incidentes que se comunican a las oficinas de servicios se deben a errores cometidos durante

la introducción de cambios en las aplicaciones y la infraestructura en la que se basan. Las

desconexiones del proceso entre los equipos de operaciones y desarrollo pueden afectar

seriamente a la capacidad de una empresa para generar ingresos.

Algo que agrava aún más los problemas del proceso es el hecho de que la mayoría de los

equipos de operaciones de TI mantengan sus propios sistemas para la gestión de incidentes,

problemas y cambios relacionados con la infraestructura de TI. Estos sistemas suelen

ser diferentes de los que utilizan los equipos de desarrollo de aplicaciones para realizar

el seguimiento de los requisitos, los incidentes, las mejoras y las peticiones de cambio.

Normalmente, los equipos de operaciones de TI no podían acceder o ver las correcciones

y modificaciones que realizaban los equipos de desarrollo de aplicaciones. Asimismo, los

equipos de desarrollo rara vez disponen de acceso a las herramientas que los equipos de

operaciones de TI usan para realizar el seguimiento de los requisitos, los problemas y los

cambios. Estos sistemas organizados en silos y de función específica complican aún más la

situación .

Los desafíos de las desconexiones del proceso y de las herramientas se vuelven evidentes en

este ejemplo del lanzamiento de un nuevo portal de transacciones en línea de un proveedor

de telecomunicaciones. El equipo de desarrollo informó al equipo de operaciones de TI

tan solo unos días antes del lanzamiento de que se necesitaba una versión diferente de la

base de datos de Oracle en el entorno operativo. Como el equipo de operaciones de TI tenía

una visibilidad limitada de los detalles del lanzamiento, no conocía los procedimientos

de implantación y no sabía que era necesario actualizar la base de datos. Para complicar

aún más esta situación, el resto de aplicaciones que compartían la instancia de la base de

datos de Oracle eran incompatibles con la nueva versión. Como resultado, el equipo de

operaciones de TI tuvo que ingeniárselas para adquirir más hardware y establecer una

instancia nueva de la base de datos. Esto ocasionó que el lanzamiento de las aplicaciones

fuera más caro y se retrasara. Además, afectó a los ingresos y aumentó la brecha que existía

entre las empresas de operaciones y desarrollo.

El impacto empresarial que supone la incapacidad de unir al personal, los procesos y los

sistemas de los equipos de operaciones y desarrollo se aprecia cuando las aplicaciones que

forman el pilar de una empresa se tambalean porque los cambios y los lanzamientos fallan.

El 40 % de las incidencias que llegan a las oficinas de servicios se deben a errores cometidos durante la introducción de cambios en las aplicaciones y su infraestructura.

__________

* Forrester/itSMF Q2 2011 US ITSM Online Survey (Encuesta online sobre ITSM en EE. UU. durante el segundo trimestre de 2011, de Forrester/itSMF)

3www.microfocus.com

Por tanto, ¿cómo pueden agilizarse los procesos que abarcan los equipos de operaciones

y desarrollo? ¿Cómo se puede mejorar y agilizar la gestión de cambios y lanzamientos sin

poner en peligro el control y la estabilidad del entorno?

Mejores prácticas de gestión de cambios y lanzamientos de Agile

Crear un canal único para todos los incidentesCuando los clientes experimentan problemas con una aplicación o desean solicitar

funcionalidades nuevas, suelen enviar un correo electrónico o plasmar lo que necesitan en

una hoja de cálculo o un documento de Word. Lo malo de este método es que tales peticiones

y problemas pueden perderse por el camino. Además, los clientes no pueden realizar un

seguimiento del estado de la petición fácilmente. Un portal centralizado con el que los

clientes interactúen para enviar y realizar un seguimiento del estado de los tickets puede

mejorar en gran medida los niveles de satisfacción. Por ejemplo, durante la preparación

de un lanzamiento, el director de desarrollo de aplicaciones podría pedir al equipo de

infraestructura que agregara una nueva capa web a un clúster de servidor existente para

rediseñar una aplicación.

_______________________________________________________________

Un portal de peticiones unificado deriva las incidencias a los equipos de operaciones y desarrollo para resolver los problemas rápidamente.

Fig. 2

Un portal centralizado que canaliza los incidentes y muestra los SLA

4

Informe oficialMejores prácticas de gestión de cambios y lanzamientos de Agile

La gestión de cambios y lanzamientos integrada agiliza el paso a producción de las modificaciones de aplicaciones.

Con un portal centralizado en el que se muestren los acuerdos de nivel de servicio (SLA) y

en el que se recopile la información del centro de costes necesaria para los rechazos y las

aprobaciones, se puede optimizar el proceso de incorporación de cambios de aplicaciones.

Por otro lado, un portal de peticiones unificado que derive automáticamente las incidencias

al equipo adecuado (ya sea de los grupos de operaciones o de desarrollo de aplicaciones)

contribuye a que los problemas se aborden y resuelvan con rapidez.

Integrar los procesos de gestión de cambios y lanzamientosAl integrar y automatizar los procesos de gestión de cambios y lanzamientos, se elimina la

necesidad de escribir complejos guiones de implantación y se evitan los posibles errores

humanos cuando los cambios pasan a la fase de producción.

La clave es ofrecer, tanto al equipo de operaciones como al de desarrollo, una visión

completa de la previsión y puesta en marcha de los cambios que se hayan programado.

Las peticiones de cambios y correcciones de errores se transfieren a los equipos de

desarrollo. Para que el paso de los cambios al entorno de producción resulte más fácil,

dichos equipos pueden beneficiarse de una mayor visibilidad en las ventanas de cambios

predefinidas disponibles en los entornos operativos, denominadas series de lanzamientos.

Las series de lanzamientos ayudan a combinar las peticiones de cambios operativos y de

aplicación en una ventana programada y, posteriormente, a ponerlas en marcha en el

momento oportuno para ambos equipos.

Las posibilidades de que se produzcan errores al introducir cambios se reducen de forma

significativa si los equipos de desarrollo y operaciones pueden ver las series de lanzamientos

disponibles claramente, combinar las funcionalidades y los cambios operativos planificados

fácilmente y, después, realizar un seguimiento del progreso del lanzamiento conforme pasa

por los entornos de desarrollo, pruebas y producción. Al ser capaz de rastrear los cambios

de la petición inicial, las organizaciones de TI están mejor preparadas para comunicar a sus

homólogos comerciales las novedades acerca del estado de forma precisa y detallada .

_______________________________________________________________

5www.microfocus.com

Si los procesos se vinculan, los equipos de desarrollo pueden realizar un seguimiento de

los cambios asociados a una petición a nivel de código fuente conforme pase del entorno

de desarrollo al de pruebas y producción. Una vez que la aplicación se transfiere a la

producción, las actualizaciones se deben realizar automáticamente en su entrada de la

biblioteca definitiva de medios (DML). Cuando los estos procesos de aplicación están

vinculados a una base de datos de gestión de configuraciones (CMDB) para gestionar la

infraestructura, y las actualizaciones de los elementos se realizan automáticamente en

cuanto se liberan los cambios, se obtiene un registro completo y coherente de lo que se

encuentra en producción.

Hacer que los equipos de operaciones y desarrollo trabajen juntos en los procesos integrados

les permite implantar rápidamente los cambios de las aplicaciones para proporcionar

asistencia a la empresa sin poner en peligro la estabilidad del entorno operativo.

Hacer que los equipos de operaciones y desarrollo trabajen juntos en los procesos integrados les permite implantar rápidamente los cambios de las aplicaciones para proporcionar asistencia a la empresa sin poner en peligro la estabilidad del entorno operativo.

Fig. 3

Combinación de los cambios operativos y de aplicación en una sola serie de lanzamiento

6

Informe oficialMejores prácticas de gestión de cambios y lanzamientos de Agile

Ofrecer una visibilidad completa mediante un calendario unificadoEs muy útil disponer de un calendario integrado al que puedan acceder los equipos de

operaciones y desarrollo. El calendario debe mostrar todos los cambios planificados

por semana o mes para que los equipos de alertas programen las actualizaciones de las

aplicaciones .

_______________________________________________________________

La capacidad de ver las distintas aplicaciones afectadas por una serie de lanzamientos y

profundizar en los detalles de una petición de cambios puede resultar muy útil para los

equipos de operaciones y desarrollo. Debe incluir los detalles de los cambios de la aplicación

hasta los elementos que se van a implantar, así como la información de los cambios en la

infraestructura. Un calendario de cambios unificado proporciona a los equipos de desarrollo,

a los encargados de los lanzamientos y a los equipos de operaciones una vista consolidada de

todo el software planificado, así como de los cambios en la infraestructura.

Calendario unificado que proporciona visibilidad sobre las ventanas disponibles para implantar los cambios.

Fig. 4

Calendario unificado que ofrece visibilidad completa del desarrollo y las operaciones

7www.microfocus.com

La conexión entre los procesos de operaciones y desarrollo mejora la satisfacción comercial respecto a la TI, puesto que se realiza un seguimiento de los incidentes y los problemas hasta su resolución, los cambios se introducen en las aplicaciones mucho antes y los usuarios empresariales reciben notificaciones directas cuando se resuelven los problemas.

Al aprovecharse de un calendario unificado, los equipos de desarrollo y lanzamiento

serán plenamente conscientes de las ventanas de cambio disponibles, y de los periodos

programados de inactividad de producción. Gracias a este conocimiento, dichos equipos

pueden solicitar un cambio de infraestructura en el momento adecuado, por ejemplo,

para resolver algún problema reciente de rendimiento de la aplicación. Cuando un cambio

operacional se asocia a una serie de lanzamientos, el control del cambio pasa a dicha serie.

Si la serie se aprueba y se marca como lista para su implantación, se les debe notificar

a los equipos de operaciones automáticamente para que realicen las modificaciones de

infraestructura necesarias en consonancia con los SLA. El proceso debe continuar hasta

que se implanten todos los cambios de la serie de lanzamientos. Después de la revisión

posterior a la implantación, las actualizaciones se deben realizar en el sistema de gestión de

configuraciones, que consta del CMDB y de la DLM.

Al vincular los lanzamientos de desarrollo aprobados con las ventanas de mantenimiento

operativo existentes, los equipos pueden evitar los retrasos de los lanzamientos y la

confusión durante la implantación .

Conclusión

Las organizaciones realizan un volumen de negocios cada vez mayor en línea, de modo

que es esencial acelerar la gestión de cambios. Las empresas podrán aprovechar la ventaja

que supone disponer de equipos de gestión de lanzamientos o DevOps que actúen como

elementos aglutinadores de los equipos de desarrollo y operaciones. Las herramientas y los

sistemas que vinculan personas y procesos durante el desarrollo y las operaciones pueden

lograr con creces que dichos equipos dispongan de la visibilidad necesaria como para

recopilar y acelerar las peticiones de cambios de aplicaciones. Además, una estrategia de

gestión de cambios y lanzamientos también reduce el número de incidencias. Los estudios

muestran que el 40 % de los incidentes que se registran se deben a errores cometidos

durante la introducción de cambios. La conexión entre los procesos de operaciones y

desarrollo mejora la satisfacción comercial respecto a la TI, puesto que se realiza un

seguimiento de los incidentes y los problemas hasta su resolución, los cambios se introducen

en las aplicaciones mucho antes y los usuarios empresariales reciben notificaciones directas

cuando se resuelven los problemas.

162-ES0086-001 | S | 05/17 | © 2017 Micro Focus. Reservados todos los derechos. Micro Focus y el logotipo de Micro Focus, entre otros, 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. 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