La respuesta breve
Una estrategia sólida de entornos responde a tres preguntas fundamentales: ¿dónde se ejecuta cada tipo de trabajo?, ¿cómo avanza un cambio? y ¿cómo se revierte si algo falla? La estructura que funciona en la mayoría de las organizaciones incluye un entorno Developer para cada desarrollador, un entorno de integración compartido, un entorno UAT con datos representativos y un entorno de Producción. Todo esto debe complementarse con Git como fuente única de verdad y una automatización del despliegue, al menos hasta el entorno UAT.
Mapa de entornos
| Entorno | Tipo | Actividad | Datos |
|---|---|---|---|
| Desarrollo Personal | Developer | Construcción, pruebas, pruebas unitarias | Solo metadatos |
| Integración | Developer Pro | Fusión del trabajo del equipo, CI | Muestra pequeña sintetizada |
| UAT | Partial o Full | Aceptación de negocio, capacitación, escenarios de borde | Datos reales enmascarados |
| Staging / Full | Full | Ensayo general de Release, pruebas de volumen | Copia completa enmascarada |
| Producción | — | Operación continua | Datos reales |
Se recomienda un Sandbox para Hotfix a las organizaciones cuyos lanzamientos superan las dos semanas. Sin este, cualquier corrección urgente obliga a desplegar trabajo que aún no ha madurado.
De Change Sets a Source-Driven
La transición se realiza en tres etapas. Primero, se exportan los metadatos existentes a un repositorio y se establece una estructura y estrategia de ramas sencilla: una rama principal, una rama de Release y ramas de Feature de corta duración. A continuación, se implementa una integración continua (CI) que ejecuta una validación de despliegue, pruebas Apex y pruebas estáticas con cada Pull Request, sobre el entorno de integración. En la tercera etapa, se conecta el despliegue automático al UAT, manteniendo el despliegue a Producción como una acción manual aprobada con una ventana de lanzamiento definida.
Lo que dificulta la transición no es la herramienta, sino el alcance: intentar introducir toda la organización (Org) en el repositorio de una sola vez genera miles de archivos que nadie es capaz de revisar. Es preferible empezar con un grupo de metadatos de un solo dominio de negocio y expandirse gradualmente.
Lo que no entra en el repositorio
Parte del estado no consiste en metadatos desplegables: registros de configuración en Custom Settings y Custom Metadata que dependen del entorno, valores de Named Credentials, Assignment Rules que cambian con frecuencia y contenido de Knowledge. Para cada una de estas categorías debe existir un documento breve que defina quién actualiza, dónde y cómo se sincroniza entre entornos. La ausencia de esta definición es la causa más común de errores que aparecen solo en Producción.
La relación entre la frecuencia de los lanzamientos y el método de trabajo se detalla en Agile vs. Waterfall Híbrido y en la Guía de Implementación de Salesforce.
Actualización y mantenimiento de entornos
Un Sandbox que no se ha actualizado en nueve meses ya no representa a Producción, y cualquier prueba realizada en él da una falsa sensación de seguridad. La regla es simple: un entorno UAT se refresca antes de cada Release significativo, y los entornos de desarrollo se refrescan al final de cada ciclo. Es crucial planificar con antelación lo que se pierde con la actualización (datos de prueba, usuarios, configuraciones) y disponer de un script Post-Refresh que los restaure en una hora, en lugar de tres días.
Riesgos comunes y acciones preventivas
El primer riesgo es el Drift: diferencias que se acumulan silenciosamente entre Producción y el repositorio. La única defensa efectiva es una comparación automática semanal de metadatos con alertas.
El segundo riesgo son las pruebas Apex que se escribieron solo para cumplir el umbral de cobertura. Una cobertura del 75% sin Assertions reales no es una red de seguridad, y da una falsa confianza justo en el momento en que se necesita la verdadera confianza. El tercer riesgo es un cuello de botella humano: una sola persona autorizada para desplegar. Se requieren al menos dos, con permisos documentados.
Cómo se mide el éxito
Cuatro métricas: frecuencia de los lanzamientos, tiempo desde la fusión hasta Producción, tasa de despliegues fallidos y número de Hotfixes en el mes posterior a cada Release. Una mejora real se observa así: la frecuencia aumenta, el tiempo disminuye, y la tasa de fallos y Hotfixes disminuye simultáneamente. Un aumento en la frecuencia junto con un aumento en los Hotfixes significa que la ruta es más rápida, pero las pruebas son insuficientes.