Informe oficial Mejores prácticas de gestión de cambios y lanzamientos de Agile Por Ben Cody, Julian Fish y Amita Abraham Noviembre de 2012
Í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........... 3 Conclusión... 7
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. Aluvión de incidentes en la oficina de servicios derivado de una gestión de cambios deficiente 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) 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. 1
Informe oficial Mejores 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. 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. 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. * 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
Un portal de peticiones unificado deriva las incidencias a los equipos de operaciones y desarrollo para resolver los problemas rápidamente. 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 incidentes Cuando 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. Fig. 2 Un portal centralizado que canaliza los incidentes y muestra los SLA 3
Informe oficial Mejores prácticas de gestión de cambios y lanzamientos de Agile 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. La gestión de cambios y lanzamientos integrada agiliza el paso a producción de las modificaciones de aplicaciones. Integrar los procesos de gestión de cambios y lanzamientos Al 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. 4
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 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. 5
Informe oficial Mejores prácticas de gestión de cambios y lanzamientos de Agile Ofrecer una visibilidad completa mediante un calendario unificado Es 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. 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 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. 6
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. 7
Argentina +54 11 5258 8899 Chile +56 2 2864 5629 Colombia +57 1 622 2766 México +52 55 5284 2700 Panamá +507 2 039291 España +34 91 781 5004 Venezuela +58 212 267 6568 Micro Focus Sedes corporativas Reino Unido +44 (0) 1635 565200 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.