Última actualización el 1 de diciembre de 2022 por Rakesh Gupta
Los conjuntos de cambios de Salesforce se utilizan ampliamente hoy en día para mover los cambios de la zona de pruebas a la producción. ¿Y por qué no se seguirían utilizando? En muchos casos, brindan una manera fácil de implementar metadatos sin conocer Git, XML, etc.
Pero una vez que su proyecto o equipo alcance cierto tamaño, comenzará a experimentar el dolor de los conjuntos de cambios de Salesforce.
En este artículo, lo guiaré a través de los desafíos que he experimentado con ellos y cuál creo que es la solución a este problema.
Los conjuntos de cambios no saben qué ha cambiado en su organización
Supongamos que trabaja mucho en su organización sandbox para un próximo proyecto. Vos tambien:
- Crear dos nuevos campos personalizados
- Modificar una clase apex existente
- Cambiar la lógica en un flujo
- Y crea una nueva plantilla de correo electrónico
Entre correos electrónicos, pausas para el almuerzo, etc., es fácil olvidar exactamente qué cambios ha realizado.
Cuando cree el conjunto de cambios por primera vez, le mostrará una lista de todos los metadatos en su organización. No tiene idea de los cambios que has hecho.
A menos que haya escrito sus cambios (o los recuerde), es fácil olvidar uno o dos, lo que hará que su implementación falle o, peor aún, que tenga éxito con la mitad de la funcionalidad.
Solo puede seleccionar un tipo de metadatos a la vez
Supongamos que desea implementar dos campos y tres plantillas de correo electrónico. La interfaz de usuario del conjunto de cambios lo obliga a seleccionar solo elementos de un tipo de metadatos a la vez
Así que tendrás que seleccionar los campos, hacer clic en guardar, seleccionar las plantillas y hacer clic en guardar nuevamente. Si está implementando cinco tipos de metadatos diferentes, son muchos clics.
Si está implementando mucho más que eso, puede dedicar fácilmente media hora a crear su conjunto de cambios.
No puede ver la diferencia entre las organizaciones de origen y de destino
Si está modificando metadatos que ya existen en la organización de destino, los conjuntos de cambios no le permiten ver cómo se ven esos metadatos en la organización de destino.
Esto significa que no puede saber cómo afectarán sus cambios a la organización de destino. No puedes ver las diferencias.
En su lugar, debe iniciar sesión en ambas organizaciones, verificar las diferencias manualmente y confirmar que los cambios previstos se realizaron correctamente una vez que implementó.
No puede implementar secciones específicas de un perfil
Cuando incluye un perfil en un conjunto de cambios, todos los permisos del sistema se implementan en el entorno de destino, incluso si solo incluyó el perfil debido a un nuevo campo (en otras palabras, deseaba implementar el campo y su seguridad de nivel de campo). (FLS)).
Si no está familiarizado con este escenario, permítame darle un ejemplo:
Suponga que crea un nuevo campo personalizado y habilita el campo para un perfil (esto se hace modificando FLS en ese perfil).
Ahora, para implementar el campo y su FLS, debe incluir tanto el campo como el perfil en el conjunto de cambios.
Si el perfil en la organización de origen tiene permisos del sistema diferentes a los de la organización de destino, esos permisos del sistema se sobrescribirán para coincidir con los de la organización de origen.
Esto significa que si el permiso del sistema "Convertir prospectos" estaba habilitado en la organización de destino pero no en la fuente, el conjunto de cambios deshabilitaría "Convertir prospectos" en la organización de destino. Esto podría evitar que todos sus representantes de ventas conviertan clientes potenciales… ¡no es divertido!
Quizás se pregunte por qué los permisos pueden ser diferentes en primer lugar. Buena pregunta. Esto podría suceder si otro administrador habilitó "Convertir clientes potenciales" directamente en producción, por lo que su sandbox no tiene este permiso habilitado en el mismo perfil.
No puede implementar datos de CPQ (o cualquier otro dato de configuración)
Salesforce CPQ utiliza objetos personalizados como datos de configuración. Esto incluye filtros de búsqueda, reglas de configuración, reglas de precios, etc. Si bien estos se almacenan como registros, representan la configuración de su implementación de CPQ.
Debido a que CPQ no es una solución nativa de Salesforce (p. ej., es un paquete administrado que se ubica sobre Salesforce), estas reglas no se pueden configurar a través del menú Configuración y no están disponibles para implementar a través de conjuntos de cambios.
Esto significa que no puede implementar la configuración de CPQ y otros datos de configuración, y debe usar herramientas especiales para esto o implementar los datos con el cargador de datos.
No puede saber qué tan desincronizadas están sus organizaciones
Con los conjuntos de cambios, mueve los metadatos de una organización a otra, pero no obtiene visibilidad sobre si esas dos organizaciones están sincronizadas y, si no, qué tan desincronizadas están.
Esto significa que la implementación de su conjunto de cambios puede finalizar con éxito, pero la característica real no funciona en la organización de destino porque algunos metadatos relacionados o la configuración es diferente de lo que esperaba.
No puede agregar dinámicamente elementos dependientes
Los conjuntos de cambios le permiten obtener elementos dependientes pero solo un nivel hacia abajo.
Esto significa que si agrega un flujo que usa un subflujo, la interfaz de usuario del conjunto de cambios le informará que también debe agregar ese subflujo. Pero si ese subflujo depende de otros metadatos como campos personalizados, etiquetas personalizadas u otros subflujos, nunca lo sabrá (a menos que lo recuerde o lo anote en alguna parte).
La solución
Esto suena demasiado negativo, pero no se desespere. ¡Hay una solución para todos estos problemas!
La solución es terminar su relación con conjuntos de cambios, por más difícil que sea.
Una vez que haya terminado con los conjuntos de cambios, debe buscar un proveedor de DevOps. Muchos proveedores de DevOps diferentes pueden hacer que la experiencia de implementar cambios sea mucho mejor.
Salto no es una solución de implementación más. Tenemos un enfoque único para los metadatos de Salesforce y estudiamos cuidadosamente todos los problemas que mencioné anteriormente y los solucionamos 😉
Permítanme compartir algunos ejemplos:
Comparación e implementación de organizaciones
Las implementaciones de Salto se basan en comparaciones de organizaciones, por lo que solo ve lo que es diferente en ambas organizaciones y puede seleccionar tantos tipos como sea necesario de una sola vez.
Además, nuestra nueva vista de diferencias lo ayuda a ver las diferencias entre organizaciones en un formato similar a un documento simple.
Retroceder a versiones anteriores
Puede realizar fácilmente un seguimiento de todo en Git, lo que le permite ver versiones anteriores de su organización de Salesforce e incluso retroceder a una versión anterior.
No olvides tus dependencias
Salto le informará si los metadatos seleccionados tienen dependencias que se requieren. ¡Esto garantiza que su primer intento de implementación sea su único intento de implementación!
Implemente y rastree sus datos de CPQ
Salto también puede ayudarlo a implementar datos de CPQ junto con sus metadatos mientras realiza un seguimiento de todo en Git Salesforce | Implementación de datos y metadatos de CPQ
¡Y hay mucho más!
Pero no confíe en mi palabra; ¡ Puede registrarse para una prueba de 30 días y comenzar a implementar como un jefe hoy!
Evaluación formativa:
¡Quiero saber de ti!
¿Qué es una cosa que aprendiste de esta publicación? ¿Cómo imagina aplicar este nuevo conocimiento en el mundo real? Siéntase libre de compartir en los comentarios a continuación.
…
Esta es una traducción realizada por EGA Futura, y este es el link a la publicación original: https://automationchampion.com/2022/12/01/let-go-of-change-sets-and-try-this-instead-2/
