Gestión de versiones en Salesforce: del sandbox a producción sin sorpresas
La mayoría de los incidentes de Salesforce son causados por despliegues fallidos. Aquí está el proceso que usamos para entregar cambios con confianza, cada vez.
Pregunta a cualquier administrador de Salesforce experimentado qué le quita el sueño y la respuesta suele ser la misma: un despliegue en producción que salió mal. Un flujo que funcionaba perfectamente en sandbox, una regla de validación que nadie probó con datos existentes, un cambio de perfil que bloqueó a la mitad del equipo de ventas un lunes por la mañana.
Estos incidentes no son causados por malos desarrolladores. Son causados por la ausencia de un proceso fiable. Aquí está el que usamos.
El principio central: producción nunca es el primer lugar donde algo se ejecuta
Todo cambio — sin importar cuán pequeño sea — sigue el mismo camino:
Sandbox de desarrollador → Sandbox completo (UAT) → Producción
“Es solo un valor de lista de selección” o “solo estoy añadiendo un campo” son frases famosas de últimas palabras. El proceso no cambia según el riesgo percibido. La disciplina de seguirlo siempre es lo que lo hace fiable.
Fase 1: Sandbox de desarrollador
Aquí es donde construyes y pruebas inicialmente. Algunas reglas que ahorran dolores de cabeza más tarde:
Nombra tus cambios claramente. Un flujo llamado Cuenta_ActualizarDireccion_v2_FINAL es una señal de alerta. Nómbralo por lo que hace: Cuenta — Sincronizar facturación con envío. Tu yo futuro (y cada administrador después de ti) te lo agradecerá.
Escribe clases de prueba antes de creer que las necesitas. Salesforce requiere 75 % de cobertura de código para desplegar Apex en producción. Los equipos que escriben pruebas solo para alcanzar este número terminan con pruebas que no verifican nada significativo. Escribe pruebas que realmente verifiquen la lógica — especialmente los casos límite y las rutas de error.
Documenta qué construiste y por qué. Una descripción de dos líneas en el flujo o un comentario en la clase de Apex es suficiente. El objetivo es que alguien nuevo en la org pueda entender la intención sin preguntarte.
Fase 2: Sandbox completo (UAT)
Esta es tu aproximación más cercana a producción. Un sandbox completo tiene una copia de tus metadatos y datos de producción — lo que significa que los errores que solo aparecen con volúmenes de datos reales y valores de campos reales surgirán aquí, no en producción.
La UAT no es solo QA — es una aprobación de las partes interesadas. El propietario del negocio del proceso afectado debería probarlo, no solo el desarrollador. Ellos conocen los casos límite, las soluciones manuales, los estados de datos que no pensaste en probar.
Ejecuta un despliegue de prueba antes del real. El CLI de Salesforce te permite validar un despliegue sin ejecutarlo realmente:
sf project deploy validate --source-dir force-app --target-org sandbox-completo --test-level RunLocalTests
Si la validación pasa, tu despliegue real casi con certeza también pasará. Si falla, acabas de evitar un despliegue fallido en producción.
Prueba con volúmenes de datos similares a producción. Un flujo que funciona bien con 10 registros puede agotar el tiempo con 10 000. Si tu sandbox completo ha sido actualizado recientemente, tiene datos de producción — úsalos.
Fase 3: El despliegue en producción
Algunos puntos no negociables antes de pulsar el botón:
Elige el momento adecuado
Despliega durante las horas de menor tráfico. Para la mayoría de las empresas norteamericanas, eso es una tarde entre semana o temprano el fin de semana — no un lunes a las 9 AM. Revisa el informe de historial de inicio de sesión de tu org para encontrar las ventanas más tranquilas.
Notifica a los usuarios afectados
Un aviso de 15 minutos en Slack o por correo es la diferencia entre una transición fluida y una avalancha de tickets de soporte. Diles qué cambia, cuándo y con quién contactar si algo parece incorrecto.
Ten un plan de retroceso
Antes de cada despliegue, responde esta pregunta: si algo va mal, ¿cómo lo revierto en menos de 15 minutos? Para Apex, es deshabilitar la clase y redesplegar la versión anterior. Para flujos, es desactivar la nueva versión y activar la anterior. Para cambios de datos, es tu exportación de respaldo. Escríbelo antes de empezar.
Valida inmediatamente después
Justo después de desplegar, ejecuta una prueba básica del proceso afectado con un registro real. No cierres tu portátil hasta haber confirmado que funciona.
El registro de cambios
El paso que la mayoría de los equipos omite: anota qué desplegaste.
No tiene que ser elaborado — una página de Notion, una hoja de cálculo compartida, incluso un canal de Slack donde cada despliegue recibe un mensaje:
2026-04-22 · Sincronización de facturación de Cuenta Desplegado: Flujo
Cuenta — Sincronizar facturación con envío, Clase ApexGestorDireccionFacturacionModificado por: Nuage9 Motivo: Solicitud de cliente — ticket #4821 Retroceso: Desactivar flujo, sin cambios de datos
Cuando algo falla dos semanas después (y siempre falla algo), este registro te dice exactamente dónde buscar.
El ROI del proceso
Un proceso adecuado de gestión de versiones añade unos 30 minutos a cada despliegue. A cambio, obtienes:
- Casi cero incidentes de producción por despliegues
- Depuración más rápida cuando algo falla de todos modos
- Pista de auditoría para revisiones de seguridad y cumplimiento
- Capacidad de incorporar nuevos miembros del equipo sin miedo
Las orgs que “van rápido” saltándose el proceso pasan el triple de tiempo resolviendo incidentes. Las que siguen un proceso consistente entregan más rápido a largo plazo porque nunca están en modo crisis.
¿Quieres que auditemos tu proceso de despliegue actual o que configuremos CI/CD para tu org de Salesforce? Hablemos.