General

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

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

A todos nos encanta juguetear con Salesforce…, pero cuando llega la hora de desplegar, ya si eso que sea el responsable de los despliegues (Release Manager) el que se encargue de moverlo entre entornos. Es un rol que nadie quiere ejercer pero que es fundamental y que, sobre todo, está muy cotizado.

En este post no quiero hablaros de herramientas, sino de metodología y remarcar la importancia de tenerla; y, más relevante aún, el peligro de no aplicarla correctamente. Ya sé que estaréis pensando <<¡Blufff!, ¡menuda chapa nos va a meter!>>. Así que, bueno, intentemos hacerlo entretenido e intrigante y vamos a dividirlo en dos partes.

Tener una buena metodología de gestión de cambios (o gestión de releases) es la base de toda implantación de Salesforce madura. Al fin y al cabo, no es más que la definición de una serie de normas para los despliegues acordadas por el equipo que todo el mundo debe cumplir sin dudarlo. Para que la gente las siga, hay que ser partícipe de su definición, así como comprenderlas, interiorizarlas, ponerlas en práctica y, a fin de cuentas, defenderlas con los ojos cerrados. Deben ser nuestros “10 mandamientos” del siglo XXI.

Como 10 mandamientos que son, vamos a profetizarlos a través del Release Manager. Es el representante en la tierra del Salesforce Lead que trajo las tablas con los 10 mandamientos para alejar a los pobres administradores esclavos de las malas prácticas.

En esta primera parte nos centraremos en 5 primeros mandamientos. Aquí van:

1º Amarás a la Gestión de Releases sobre todas las cosas.

Es fácil dejarse llevar por las tentaciones y hacer despliegues cuando nos venga en gana, sin cerciorarnos si va a fallar, sin comprobar que hacemos todos los cambios necesarios y sin informar a nadie. ¡Debemos ser fuertes! Es fundamental definir una serie de normas que todo el equipo Salesforce debe seguir y, consecuentemente, asegurarse de que el resto de personas involucradas en la implantación -incluido negocio, los managers y los usuarios finales-, las comprende y las respeta.

El primer mandamiento es realmente la norma sobre todas las normas. Debemos ser capaces de ver y comprender que la gestión de releases es algo positivo para nuestro proyecto y que nos ayudará a tener controlado qué subir, cuándo, cómo, dónde y quién lo hace.

Por otro lado, es  importante saber que las herramientas únicamente apoyan y reafirman la metodología; por ello, lo primero que hay que hacer es definir bien los cimientos. Este post no va a hablar de Changeset, SalesforceDX, Git, Copado, Jira, Trello o Selenium. Tampoco va a hablar de Scrum o metodologías más tradicionales. Esas son otras batallas que trataremos en posts venideros.

Como primera conclusión, una vez definida la metodología de gestión de cambio, debes seguirla, defenderla con uñas y dientes y asegurarte de que siempre se cumple.

2º No tomarás el nombre del Release Manager en vano.

El Release Manager es Dios, y los administradores son sus profetas, <<aunque esto igual viene en otro libro sagrado…>>. Esto quiere decir que el Release Manager es el responsable de la metodología, pero que el resto de administradores también deben salvaguardar la gestión del cambio.

Es relevante comprender que el Release Manager no es un puesto, sino un rol. Por tanto, cualquier miembro del equipo puede ejercerlo en un momento dado. La idea no es que haya un super responsable que, al final, se convierte en un cuello de botella por el que pasa todo desarrollo. Al contrario, se trata de que todos ayudemos cuando haya que integrar desarrollos de otros, o probemos funcionalidades implementadas por algún compañero, o validemos que se han ejecutado los test requeridos.

Otra clave para el éxito es que el Release Manager, el Jefe de Proyecto y el Salesforce Lead sean figuras distintas, pues la responsabilidad de cada uno es diferente y muchas veces genera conflictos profesionales: el Jefe de Proyecto quiere que la funcionalidad se haga en tiempo/alcance/coste; el Salesforce Lead debe asegurar la calidad y que no se corrompa el sistema; y el Release Manager debe cerciorarse de que los despliegues se hacen correctamente. En el caso de que estos roles se compartiesen, deberían llevarse a cabo juicios lo más objetivos posibles.

3º Santificarás las fechas de despliegue.

En cada implantación Salesforce es conveniente definir un calendario de despliegue, siendo crucial seguirlo al pie de la letra. En él debemos incluir todo despliegue relevante para la gestión del cambio (paquete de issues resueltas, go-live de proyecto, nueva versión de funcionalidades, release oficial de Salesforce,…), así como su responsable, fecha y entornos origen y destino.

Si un jefe de proyecto tiene su plan de proyecto, el Release Manager debe tener su calendario de releases como herramienta de seguimiento. Debe ser algo firme, pero flexible; es decir, es un documento vivo. Debemos incluir no solo las fechas de las releases, sino también otros eventos que puedan tener impacto, como pueden ser:

  • Fechas fijas y conocidas de antemano, como los 3 releases oficiales de Salesforce, los festivos nacionales, o el cierre de año fiscal.
  • Fechas variables, es decir, aquellas que pueden cambiar, como las vacaciones del equipo o la fecha de arranque de un proyecto.

Todo ello afecta directamente a posibles fechas para hacer un despliegue y podría ser que puntualmente hubiera que ajustarlas.

Por otro lado, también hay que adaptar el procedimiento de desarrollo. Cuando nos entra un nuevo issue, funcionalidad o proyecto, tras analizarlo y estimarlo, debemos incluirlo dentro de su posible Release. Esto indicará cuando se va a promocionar al entorno siguiente.

4º Honrarás a las hojas de release.

Ya hemos comentado que no vamos a hablar de metodología de proyecto ni de directrices de desarrollo y documentación, pues es harina de otro costal. Pero sí debemos hablar de uno de los output de esa fase de desarrollo: la hoja de Release.

La hoja de Release es el documento que agrupa el conjunto de cambios necesario para hacer el transporte de una funcionalidad. Esto incluye:

  • Conjunto de cambios: puede ser un commit/rama o un archivo con los cambios;
  • Tareas manuales: aquellos metadatos de Salesforce que no se pueden desplegar. Se pueden agrupar en Pre-Despliegue y Post-Despliegue;
  • Cargas de datos: migración de datos maestros o carga de documentos históricos;
  • Despliegue destructor: borrado de metadatos obsoletos;
  • Perfiles: metadatos bastante “especialitos” en el mundo Salesforce que se pueden considerar como un subconjunto en sí mismo; e
  • Integraciones: dependencias con otros sistemas que deben subirse a la par.

Este documento, junto al resto de evidencias de los desarrollos (análisis, test, scenarios, documentación técnica, manuales,…), deben ser almacenados, actualizados y mantenidos preferiblemente como Tarea en algún software de seguimiento de proyectos e incidencias para su fácil acceso.

5º No matarás el entorno de desarrollo.

No debe elegirse a la ligera el conjunto de Sandboxes que vamos a necesitar en una implantación Salesforce. Debe tenerse en cuenta el número de administradores, tiempo de puesta en producción esperado, etapa de la implantación en la que estemos (construcción de solución vs mantenimiento), etc. En mi ejemplo, voy a suponer que tenemos los siguientes entornos: Producción, Pre-producción, Integración y Desarrollo.

Este mandamiento afirma que el entorno de Desarrollo es para que desarrollen los desarrolladores. ¡Fácil y pomposo!, ¿no? No obstante, en lo que queremos hacer hincapié es justo lo opuesto, es decir, que no se desarrolle directamente en ningún entorno superior a Desarrollo.

Debe estar prohibido codificar en un entorno de Pre-Producción o Integración o, peor aún, en Producción. Esto acaba generando inconsistencias y, por tanto, desalineando los entornos. También genera problemas en despliegues futuros, ya que pueden aparecer conflictos no esperados, así como la posibilidad de pérdida de dichos cambios porque sean pisados por otros posteriores.

Hasta aquí la primera parte. Os dejo unos días para que reflexionéis sobre los mismos y os quedéis con la curiosidad por conocer el resto. Sed buenos 🙂

You Might Also Like...

2 Comments

  • Reply
    Héctor
    6 julio, 2019 at 5:18 pm

    Genial ver como evoluciona un padawan!!

  • Reply
    Los 10 mandamientos de la gestión del cambio. 2ª Parte – Salesforce Spain
    30 julio, 2019 at 10:41 am

    […] Los 10 mandamientos de la gestión del cambio. 1ª Parte […]

  • Leave a Reply