General

Los 10 mandamientos de la gestión del cambio. 2ª Parte

Continuamos definiendo un conjunto de buenas prácticas que deberían convertirse en costumbre

Tras unos días de <<¿angustiosa?>> espera, aquí llega el desenlace sobre los 10 mandamientos de la gestión del cambio. Si hacemos memoria, en el post anterior vimos la primera parte de una serie de buenas prácticas a acometer en vuestra implantación Salesforce que os ayudarán a conseguir madurez y estabilidad en vuestros procesos de despliegue. Ahora en esta segunda parte, continuamos con el resto de los 10 mandamientos de la gestión del cambio:

6º No cometerás actos impuros.

En toda equipo, hay siempre un bandolero escondido dispuesto a sacar de nuevo su garrote y cometer alguna fechoría. Tenemos que tenerlos vigilados pues a la mínima nos pueden poner patas arriba nuestra tranquilidad de un noche en calma de release. 

Hay que ser puristas y no dejarnos caer en las malas prácticas. Sobre todo al principio cuando estamos empezando con esta nueva metodología. Un ejemplo de acciones a evitar (y que seguro que a todos nos suena) puede ser el siguiente: 

  • Despliegues incompletos o parciales
  • Despliegues que requieren integración y que no se tiene en cuenta el otro sistema
  • Desarrollar en periodo de bloqueo de preparación de release
  • Desplegar sin comprobar que las test requeridos han sido generados
  • Mover más cambios de lo necesario
  • Hacer despliegues críticos en horas de trabajo (en vez de horario fuera de oficina)
  • Tocar en Producción fuera de fecha de transporte
  • Subestimar las validaciones previas al despliegue

Este mandamiento busca conseguir que todos tengamos una alarma latente en el subconsciente que se active cuando alguien (incluido nosotros mismos) intente saltarse alguna norma.

7º No robarás configuración de otro desarrollo.

Es decir, pon atención a las integraciones y no generes un changeset/commit con más cambios de los necesarios. Sobre todo esto aplica a aquellos metadatos que se transportan como un único ente: o todo o nada. Un ejemplo claro son las clases de apex: si dos personas necesitan modificar la misma en clase, lo harán en el entorno de desarrollo. Pero si a la hora de desplegar al siguiente entorno no se mueve a la vez, es muy importante aislar los cambios de cada uno para subir únicamente las líneas de código oportunas. En función de la tecnología utilizada (changeset o control de versiones), el paso de ejecutar un  merge o de comparación de entornos es clave para transportar lo justo y necesario.

Al igual que el puro código hay muchos otros metadatos almacenados como XML que son susceptibles de desplegar e inyectar cambios no deseados. Por eso es muy importante definir:

  • Metadatos que se consideran como cambio desplegable (incluido en el changeset/commit).
  • Metadatos que refieren a un cambio manual (se aplica directamente en el siguiente entorno).

Se debe catalogar en base a la dificultad de despliegue, el periodicidad de que aparezca un cambio en ese metadato, la posibilidad de inyectar conflictos, etc

Aunque Salesforce plantee unas directrices básicas, podemos adaptarlas a las necesidades de nuestra implantación. Por tanto no está de más generar un listado de metadatos existentes y cómo transportarlos.

8º No dirás falso testimonio ni mentirás sobre los tests realizados.

Una buena práctica bien conocida por todos, al menos la parte teórica, trata sobre la necesidad de generar un buen conjunto de tests: unitarios, integrados, funcionales, etc. Además estos se deben mantener actualizados a la par que se realizan cambios en el sistema.

Cuando hablamos de test incluye:

  • Los test unitarios programados que Salesforce obliga a ejecutar en cualquier subida a Producción.
  • Las baterías de test funcionales, end-to-end o de regresión que se deben reproducir a la hora de validar que una funcionalidad opera acorde a lo inicialmente solicitado. 

Está práctica no es especifica de la gestión del cambio, sino que se debería catalogar dentro la metodología de desarrollo o de la gestión de proyectos, pero tiene un gran impacto cuando hay que mover un desarrollo entre entornos.

Un desarrollo no se debe considerar como terminado cuando hemos completado todos los cambios en el sistema (metadatos y programación), sino cuando los test correspondientes han sido ejecutados y se ha validado que todos ellos se pasan sin errores. Si nos apoyamos de una herramienta de seguimiento de proyectos e incidencias, podemos dejar las evidencias de los tests para su futura validación.

El párrafo anterior es clave a la hora de programar un despliegue pues no debemos dar una funcionalidad por cerrada si no ha sido probada. Al fin y al cabo puede llegar a significar múltiples despliegues correctivos en un corto periodo de tiempo referente a la misma funcionalidad: esto conlleva a una pérdida enorme de tiempo, deja el sistema inestable, además de dar mala imagen al equipo de desarrollo. La recomendación se acentúa si el despliegue es en Producción.

9º No consentirás despliegues impuros, por muy apurado que vaya el proyecto o muy crítica sea la incidencia.

Estas normas son muy lógicas, pero ¿qué pasa cuando estamos en una fase crítica de proyecto y aparecen issues no esperadas que bloquean el sistema? Por todos los medios van a forzar que subamos una solución inmediatamente saltando todas las normas anteriormente establecidas.

Aquí hay que ser fuertes, puesto que el remedio puede ser peor que la enfermedad. Modificar en Producción, o un despliegue de soluciones sin probar puede que convierta una issue en una catástrofe, más aún si no tenemos un sistema de respaldo del código.

En estos casos tenemos que tener metodología de gestión de casos: tras un breve análisis del fallo, antes que buscar las causas, hay que dar soluciones, aunque sean temporales (conocidos como Workarounds). También hay que informar para no permitir que el error se siga reproduciendo/propagando. Tras ello, podemos intentar buscar soluciones más sólidas. Aquí podemos ayudarnos de un entorno adicional conocido como HotFix utilizado para incidencias críticas y bloqueantes. Esto agilizará considerablemente los tiempos de subidas entre entornos pues HotFix debe estar conectado directamente con Producción. Tras arreglar el problema, la solución definitiva debe desarrollarse y desplegarse siguiendo la metodología tradicional.

10º Codiciarás las normas ajenas, pero con moderación.

No, no es una equivocación en la no negación del enunciado :P. Puede haber otras normas sobre la gestión de despliegues que te hayan comentado compañeros de otros proyectos y que afirman que funcionan. Siempre pueden incluirse en nuestro conjunto de mandamientos y aplicarse para mejorar más aún nuestra metodología. 

Aviso a navegantes: es importante que esos cambios de metodología de release estén organizados, porque sino al final puede acabar convirtiendo en un descontrol más que en una ayuda. Las nuevas normas deben revisarse y probarse y solo deben aplicarse aquellas que mejor se adapten a nuestras circunstancias: algo que funciona en un proyecto o equipo, puede que no se válido en todos. Cambios muy habituales en la propia metodología, hace que no termine de interiorizarse los ya existentes. Mejor incluir poco y bueno.


Tras los 10 mandamientos de la gestión del cambio, ahora toca ponerlo en práctica

Hemos aprendido que el Release Manager rescató a los administradores de la esclavitud de los despliegues desorganizados, y les ofreció la tierra prometida: despliegues sin incidentes y acorde a lo planeado siguiendo los 10 mandamientos de la gestión del cambio. Lo positivo es que para ponerlo en práctica no necesitaremos 40 años de travesía por el desierto, aunque sí puede que requiera un periodo de adaptación.

You Might Also Like...

No Comments

Leave a Reply