Conjuntos de cambios de Salesforce: cuándo cambiar de herramienta
Compara las limitaciones de los conjuntos de cambios y sus alternativas, con una lista de verificación que ayuda a tu equipo a decidir cuándo cambiar.
Los conjuntos de cambios de Salesforce funcionan bien para entregas ocasionales desde un solo sandbox. Cuando varias personas realizan cambios, el seguimiento manual y la falta de un historial de versiones pueden dificultar la gestión de las implementaciones. Los equipos que buscan una alternativa pueden elegir Salesforce Lifecycle Center, una herramienta de implementación de terceros o un flujo de trabajo creado con la CLI de Salesforce.
Esta guía está dirigida a administradores y equipos pequeños de Salesforce que evalúan si su proceso actual de entrega todavía les funciona.
Cómo funcionan los conjuntos de cambios de Salesforce
Un conjunto de cambios es una colección de metadatos, como campos, flujos, clases Apex y formatos de página, que reúnes en una organización e implementas en otra. Transfiere configuración, no registros de negocio.
Las organizaciones deben pertenecer a la misma organización de producción y tener una conexión de implementación autorizada. Una vez cargado, un conjunto de cambios no se puede editar; tendrás que clonarlo para modificar su contenido. Algunos tipos de metadatos no son compatibles, así que consulta el informe de cobertura de metadatos de Salesforce.
Dónde los conjuntos de cambios generan trabajo adicional
Las principales limitaciones son la selección manual de componentes, la visibilidad limitada de las diferencias y la ausencia de un historial de versiones o una función de reversión integrados.
Tienes que llevar un registro de cada cambio. Alguien debe recordar qué campos, flujos, permisos y componentes relacionados forman parte de la entrega. Ver/Agregar dependencias ayuda, pero no identifica todo lo que una implementación puede necesitar. Una dependencia omitida puede requerir otra ronda de correcciones y validación. Hemos hablado con equipos que gestionan entregas con varias hojas de cálculo compartidas por correo electrónico y Slack, y que detienen el desarrollo durante un día, a veces una semana, solo para determinar qué cambió y en qué orden.
Recuperar una versión anterior requiere preparación. Los conjuntos de cambios no muestran una comparación completa con la organización de destino ni conservan la versión anterior de cada componente. Si una implementación exitosa causa problemas, necesitas una copia anterior para restaurarla. Sin ella, quizás tengas que reconstruir la configuración. Consulta cómo recuperarte de una implementación fallida de Salesforce.
Las eliminaciones y los cambios de nombre requieren un proceso independiente. Los conjuntos de cambios no pueden eliminar componentes ni cambiarles el nombre. Según el componente, necesitarás pasos manuales o una implementación mediante la API de metadatos que use cambios destructivos.
Los cambios en paralelo pueden sobrescribirse entre sí. Dos personas pueden editar el mismo flujo en sandboxes separados sin darse cuenta. Los conjuntos de cambios no fusionan su trabajo ni advierten que la implementación posterior podría sobrescribir la anterior.
Los permisos de los perfiles dependen del contenido del paquete. Incluir un perfil no transfiere toda su configuración. Los permisos de los componentes relacionados dependen de qué más se incluya, lo que puede generar un acceso distinto del que esperabas.
Corregir una entrega añade más trabajo manual. Si el paquete necesita otro componente, debes clonarlo, realizar el cambio y volver a cargarlo. Los errores en las pruebas también pueden retrasar las entregas a producción. Con el nivel de pruebas predeterminado, las pruebas locales de Apex se ejecutan cuando la implementación incluye clases o desencadenadores de Apex; una entrega que solo contiene configuración no las ejecuta automáticamente. La documentación de Salesforce sobre conjuntos de cambios explica los valores predeterminados.
Los equipos liderados por administradores pueden mejorar este proceso sin aprender a usar herramientas de línea de comandos. En nuestro Caso de éxito de Catalyst Consulting, 20 analistas de negocio de un equipo de proyecto de 30 personas comenzaron a implementar sin capacitación en Git. Las implementaciones pequeñas que antes tomaban aproximadamente medio día pasaron a tomar minutos, y el equipo estuvo operativo en un día. Los resultados dependen del equipo y de la entrega, pero el ejemplo muestra cuánto puede afectar la coordinación manual al tiempo de implementación.
¿Cuándo es momento de dejar los conjuntos de cambios?
Considera cambiar cuando preparar y corregir implementaciones te quite regularmente tiempo para los cambios en sí. Agregar otro colaborador o sandbox puede poner el problema en evidencia, pero el tamaño del equipo por sí solo no es una razón para comprar una herramienta.
Usa esta lista de verificación para revisar tus últimas entregas. Varios problemas recurrentes son una señal más clara que una sola implementación difícil.
Lista de verificación para evaluar los conjuntos de cambios
- Más de una persona contribuye a la misma entrega.
- Los cambios pasan por más de un sandbox antes de llegar a producción.
- Una dependencia faltante provocó un error de implementación el trimestre pasado.
- Una implementación sobrescribió el trabajo de otra persona.
- El contenido de las entregas se registra en una hoja de cálculo o un hilo de chat.
- Has reconstruido manualmente una configuración de producción para deshacer un cambio.
- Las entregas incluyen eliminaciones o cambios de nombre de metadatos.
- Los desarrolladores usan Git, pero los cambios de los administradores no se registran allí.
- Necesitas un historial confiable de quién cambió qué.
- Las entregas requieren detener el desarrollo, trabajar un fin de semana o dedicar un día a la implementación.
Alternativas a los conjuntos de cambios de Salesforce
Tu elección depende de quién realiza las implementaciones, cuánta configuración puede mantener tu equipo y qué metadatos necesitas admitir.
| Opción | Ideal para | Trabajo que debes prever |
|---|---|---|
| CLI de Salesforce y API de metadatos | Equipos de desarrolladores que crean su propio flujo de entrega | Scripts, mantenimiento de CI y un flujo de trabajo práctico para administradores |
| Salesforce Lifecycle Center | Equipos que buscan un flujo de entrega nativo de Salesforce | Requisitos de edición y control de versiones, configuración y adopción |
| Herramientas de terceros como Blue Canvas, Gearset, Copado y Flosum | Equipos que buscan funciones integradas de comparación, despliegue y recuperación | Costos de suscripción y verificación de compatibilidad con tus metadatos |
Para una comparación más detallada, consulta nuestra guía de herramientas de despliegue de Salesforce. Si estás considerando la opción de Salesforce, revisa la configuración y el trabajo continuo que requiere, junto con la documentación actual de Salesforce.
Qué debería ofrecerte un mejor proceso de implementación
Busca estas capacidades durante una evaluación y pruébalas con tus propios metadatos. Varían según la herramienta y la configuración.
- Historial de cambios. Los cambios de administradores y desarrolladores deben registrarse juntos, con suficiente detalle para rastrear cuándo y por qué se realizaron. Verifica si el seguimiento es automático o requiere un commit manual.
- Revisión antes del despliegue. Una comparación debe mostrar qué cambiará en la organización de destino. Las verificaciones de dependencias deben ayudar a detectar componentes faltantes, aunque no evitarán todos los errores de despliegue.
- Un proceso de recuperación probado. El historial de versiones te permite volver a desplegar una configuración anterior. La reversión basada en Git aún requiere validación y no restaura los datos de negocio modificados después de una entrega.
- Entregas manejables. Los lotes más pequeños deberían ser más fáciles de revisar y depurar, y requerir menos tiempo para conciliar hojas de cálculo antes del despliegue.
Cómo hacer la transición sin interrumpir las entregas
Comienza con una ruta de despliegue para que el equipo aprenda el proceso con una entrega real.
- Elige una ruta que genere dificultades frecuentes, como de sandbox a UAT.
- Registra los metadatos de producción en el control de versiones como punto de partida.
- Compara los entornos sandbox relevantes con producción y resuelve las diferencias no deseadas. Nuestra guía para mantener los entornos sandbox sincronizados explica esta preparación.
- Realiza una entrega real con el nuevo flujo de trabajo, incluidos la revisión, la validación y una comprobación de recuperación.
- Migra las rutas restantes a medida que el equipo se familiarice con el proceso. Elimina las conexiones de implementación que ya no necesites.
Dónde encaja Blue Canvas
Blue Canvas es ideal para equipos donde administradores y desarrolladores entregan cambios juntos y necesitan control de versiones sin mantener su propio pipeline. Registra automáticamente en Git los metadatos compatibles de la organización, mientras los administradores revisan e implementan desde la interfaz. Las integraciones con GitHub, GitLab y Bitbucket permiten a los desarrolladores conectar ese trabajo con sus repositorios existentes.
Si un solo administrador realiza unos pocos cambios cada trimestre desde un único sandbox, los conjuntos de cambios pueden seguir siendo suficientes. Un equipo con un pipeline de CLI que ya funciona bien puede tener pocos motivos para reemplazarlo. Si tu prioridad es un flujo de trabajo nativo de Salesforce, evalúa también Lifecycle Center.
Explora la gestión de entregas de Blue Canvas o todas las funciones, y evalúa el flujo de trabajo con una entrega representativa de tu organización.
Preguntas frecuentes sobre conjuntos de cambios de Salesforce
¿Los conjuntos de cambios siempre se crean en un sandbox?
No. Producción también puede enviar conjuntos de cambios a un sandbox conectado cuando la conexión de implementación lo permite. La ruta habitual de entrega comienza en un sandbox y avanza hacia producción.
¿DevOps Center es lo mismo que Lifecycle Center?
Salesforce llama Lifecycle Center a su DevOps Center de próxima generación. El paquete gestionado anterior de DevOps Center es una implementación independiente, así que confirma qué versión describe cada guía. Comienza con la ayuda actual de Salesforce al evaluar la disponibilidad y la configuración.
