Fallas comunes en la Administración del Release
Problemas con los procesos informales de administración de versiones
El proceso de administración de versiones suele verse generalmente muy desentendido en los entornos extremadamente cambiantes ya que se dispone de recursos y tiempo limitados para crear y refinar un proceso adecuado de administración del Release porque no se considera "crítico para la misión", hasta que ocurre algo terrible.
El proceso de administración de versiones suele ser generalmente propiedad de un jefe de desarrollo, dependiendo entonces de esquemas jerárquicos o de personas, y no de procesos como administración del cambio y en la práctica no se dedica el tiempo suficiente al proceso.
De manera que cuando se dispone de un proceso informal de administración de versiones, las empresas pueden experimentar problemas con una versión. Entre estos problemas se incluyen ciclos de versiones prolongados, mucho tiempo de inactividad sistemas de producción, funciones y responsabilidades poco claras y un proceso de creación sin administrar. Todos estos problemas traerán como consecuencia directa la insatisfacción de los clientes, usuarios y managers además de la consecuente pérdida económica.
A continuación, voy a enunciar los problemas habituales que pueden hacer fracasar a la administración del Release y que pueden ocasionar los problemas ya mencionados: Usted puede usar esta guía como autodiagnóstico, si en su organización encuentra coincidencias con lo que se describe a continuación sus procesos de cambio tienen una alta posibilidad de falla.
Problemas Comunes:
las directivas de cambio y Release son informales, y no están documentadas y definidas.
La administración de la distribución de versiones no está automatizada, por lo tanto, no existe ningún entorno controlado (falta de seguridad).
No contar con una estrategia de reserva y criterios de pruebas formalizados.
No contar con una Biblioteca de software definitivo (DSL, Definitive Software Library) formal. Por ejemplo, productos para almacenar el código de la aplicación., pero no existe ningún área de almacenamiento independiente para el código de las aplicaciones de producción aparte de los entornos de desarrollo, pruebas o producción.
No contar con Base de datos de administración de la configuración debido a la complejidad y la dificultad de hacer un seguimiento de los cambios efectuados en el código de las aplicaciones.
Los procesos de administración de cambios y configuraciones no están documentados y definidos.
Propósitos y fundamentos de la administración del Release
La Administración de Release considera una perspectiva holística de un cambio a un servicio de TI y debe asegurar que tanto el aspecto técnico y no técnico de un Release sea contemplado de manera conjunta.
Este objetivo principal apunta básicamente proporcionar los servicios necesarios para “empaquetar” los cambios del sistema y entregarlos al entorno de producción, y al tiempo mantener la integridad y la disponibilidad del servicio existente.
Por lo tanto, entre sus responsabilidades y actividades siempre se deberá tener en cuenta:
• Elaborar un plan completo de versiones que incluya procedimientos eficientes para implementar cambios en el entorno vivo.
• Establecer canales de comunicación para la notificación de información acerca de versiones, así como determinar las audiencias, las frecuencias de comunicación y la información que se va a comunicar a través de los canales establecidos.
• Asegurar el traslado seguro de software creado o adquirido mediante la implementación con la Biblioteca de software definitivo (DSL) para almacenar copias maestras de todo el software.
• Efectuar pruebas completas de aceptación por parte de los usuarios y pruebas piloto que incluyan la comprobación de los procedimientos de distribución y reserva.
• Implementar correctamente la versión en el entorno vivo, al tiempo que se mantienen la integridad y la disponibilidad del sistema.