Upload
dotruc
View
218
Download
0
Embed Size (px)
Citation preview
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