La Previa

Ya sean mantenimientos o nuevos desarrollos el paso a producción es un caso delicado.

Siempre sale alguna incidencia, de primeras,la arquitectura no es 100% identica en todos los entornos. Incluso intentandolo siempre habrá algo que por algún matiz (por ejemplo precio) no se puede replicar de la misma manera y sin contar que los parámetros cambian, los errores tipográficos existen, las políticas de seguridad pueden ser mas estrictas, etc.

Con una buena gestión de cambios se puede estar relativamente optimista pero como se dice, el demonio esta en los detalles. Debes estar preparado para limarlos y que no aparezcan al usuario. Esto es muy importante, es como ser portero de fútbol, no importa que seas un buen portero y pares todo, si te marcan un gol no han servido de nada y si ademas es cantada te persigue, como el runrun en los campos.

El método es tener planificado el antes, durante y despues de la intervención.

Antes de la intervención:

  • Identificar ventana horaria y lugar de intervención (fuera de horas? remoto?)
  • Identificar personas y recursos que van a realizar la intervención.
    • Esas personas tienen permisos para realizar su trabajo?. Si es fuera de horas y en local tienen forma de entrar, si es en remoto tienen acceso a los servicios involucrados?
  • Identificar el conjunto de pruebas que debe pasar la solución. Si es distribuida en multiples sedes en todas ellas, idem si se accede de diferentes metodos: directamente, via proxy, desde internet, en local, por vpn, por citrix,…
    • Asegurarse que el conjunto de pruebas se pasa previamente tanto en la oficina como en el lugar/hora de intervencion. Si remotamente no es posible validar que la aplicación funciona piensa en hacerlo presencial o buscar formas de poder hacerlo remotamente (pj con dameware si terminal service no cumple).
  • Identificar y reservar conjunto de personas clave: grupo 1) responsables de la aplicación, grupo 2) usuarios clave de la aplicación (pj uno por sede)
    • Grupo1: Anunciar con tiempo, solicitar permisos necesarios y recibir vistos buenos
    • Grupo2: Reservarlos para pruebas de funcionamiento (antes, durante y despues). Si el proyecto es importante los tendras durante pero lo normal es que solo esten disponibles despues e incluso ya en horario solo produccion.
  • Documentar el plan de pruebas en modo checklist y que sea validado por el Grupo 1. Esto es importante, es tu contrato con negocio. Si falta algo siempre podrás venir a este documento y decir que no entraba en las especificaciones (es un escudo no una carta de “libre de cárcel”). En un mundo ideal el plan de pruebas te lo pasaría desarrollo o el dueño de la aplicacion, y es cierto en parte pero por diferencias lingüísticas (nota mental: diferencias conceptuales entre desarrollo y sistemas) lo normal es obtener pruebas funcionales pero no pruebas completas.
  • Documentar plan de contingencia y marcha atras. Especial atencion a cuando se activa (fecha limite para decidir continuar o dar marcha atras. Aqui se debe tener en cuenta el tiempo necesario para poder dejar la situacion original) y que personas lo deciden y bajo que condiciones.

A veces el proyecto es mas complejo, involucra múltiples equipos, aplicaciones y dependencias. Es complicado llegar a ellos sin haber hecho previamente más simples. Mismos pasos pero de forma recursiva. Ata cada componente y añade la complejidad de interelación entre ellos que tambien deberás controlar y validar.

 

Leave a Reply

Your email address will not be published. Required fields are marked *