Problemas comunes de despliegue y estrategias de mitigación

Los cambios declarativos provocan fallas en las pruebas de Apex

El código de prueba de Apex es excelente para identificar cambios que provocan fallas cuando se ejecuta, pero debe ejecutarse para detectar problemas. Un problema común surge cuando un cambio declarativo, como un nuevo campo obligatorio o una nueva regla de validación, se despliega a través del flujo de despliegue o, peor aún, se crea directamente en producción después de la puesta en marcha sin ejecutar pruebas de Apex. Cuando se despliegan nuevos cambios de código, el despliegue falla en producción y debes investigar y resolver el problema, lo que puede llevar mucho tiempo y generar estrés si los plazos son ajustados.

Estrategias de mitigación

Usa entornos de pruebas para todos los cambios

Para evitar este problema, debes usar un entorno de pruebas para todos los cambios. Para el código, Salesforce ya exige esto, pero no para los cambios declarativos, como agregar nuevos campos obligatorios o reglas de validación. Trabajar en un entorno de pruebas permite aislar los cambios y probarlos en una organización separada. Después de probar tus cambios en un entorno de pruebas, puedes desplegarlos a través del flujo de despliegue hasta producción.

(Una excepción a esta regla es cuando una nueva organización de producción aún no está en uso. Es mucho más fácil crear inicialmente el esquema de la base de datos y otros cambios declarativos mientras no hay usuarios en el sistema, y luego crear los entornos de pruebas para la fase de desarrollo de la implementación).

Ejecuta pruebas de Apex en cada despliegue

Al desplegar en una organización, ejecuta siempre las pruebas unitarias locales de Apex. Esto evita introducir fallas en las pruebas y permite que quien realiza el despliegue u otro integrante del equipo actualice el código de prueba para garantizar que las pruebas pasen con estos cambios. También te da la confianza de que los cambios no dañaron nada.

(Nota: Las pruebas unitarias locales de Apex son aquellas que no están en paquetes administrados, como las aplicaciones de terceros instaladas desde AppExchange. Provienen del código personalizado de tu organización y de paquetes no administrados).

Metadatos olvidados

Olvidar incluir los metadatos dependientes es otro problema común de despliegue. Por ejemplo, un nuevo desencadenador de Apex puede usar una nueva clase controladora, pero el despliegue solo incluye el desencadenador de Apex. Esto provoca un error de compilación porque la clase controladora no existe.

Estrategias de mitigación

Mantén una lista de cambios de metadatos por tarea

Por lo general, se te asignan distintas tareas de Salesforce que requieren varios cambios para completarlas. Estas tareas suelen ser tarjetas, tickets o elementos de trabajo en algún software de seguimiento de tareas, como JIRA o Azure DevOps y permiten agregarles comentarios y otros campos personalizados. A medida que realices cambios, lleva una lista de los cambios de metadatos de cada tarea y guárdala en las tareas del sistema de seguimiento. Esto ayuda a evitar olvidos y mantiene una lista actualizada de los cambios a medida que se realizan.

Si tienes un perfil más técnico, como el de un desarrollador, puedes usar VS Code y un repositorio local de Git para llevar un seguimiento de tus cambios. A medida que los realices, regístralos con un mensaje de commit «etiquetado» para identificar fácilmente todos los cambios de cada tarea más adelante. Por ejemplo, supongamos que debes crear un nuevo desencadenador de Account y que la tarea tiene el identificador «BlueCanvas 123». Agrega el prefijo «BlueCanvas 123» a todos tus mensajes de commit y, al terminar el desarrollo de la tarea, revisa todos los commits con ese prefijo para generar el manifiesto de despliegue y guardarlo en tu sistema de tareas.

Mantener esta lista también permite que otras personas desplieguen cambios por ti si es necesario. Por ejemplo, si te enfermas de forma inesperada y es necesario desplegar tus cambios, otra persona podrá hacerlo sin que estés presente.

Pruebas de Apex sin actualizar

Otro problema común es que las pruebas de Apex no se actualicen y fallen porque los elementos que verifican han cambiado. Esto suele ocurrir cuando un desarrollador implementó los cambios originales y otro los modificó después, pero olvidó actualizar las pruebas.

‍

Estrategias de mitigación

Ejecuta pruebas de Apex en sandboxes locales y usa la concurrencia

Una estrategia para mitigar los riesgos es ejecutar siempre pruebas locales de Apex durante el despliegue, como se detalló anteriormente. Otra es ejecutar todas las pruebas locales de Apex en el sandbox del desarrollador después de realizar los cambios. Activa las pruebas en paralelo y deberían completarse con bastante rapidez. Si alguna clase de prueba falla, desactiva las pruebas en paralelo y vuelve a ejecutar las clases que fallaron. Si todas pasan, los cambios deberían poder desplegarse. A veces, ejecutar pruebas en paralelo genera problemas de concurrencia entre ellas, especialmente al crear configuraciones personalizadas. Una alternativa es ejecutar todas las pruebas de forma secuencial, desactivando la ejecución en paralelo, pero esto puede tardar mucho más según la cantidad de pruebas y otros factores.