Despliegue de Aplicaciones

Los Sandboxes son copias del entorno de producción usadas para desarrollo, testing y formación sin afectar los datos reales.

Los 4 tipos de Sandbox:

Tipo	Qué copia	Storage	Refresh	Caso de uso principal
Developer	Solo metadata (configuración)	200 MB	1 día	Desarrollo individual
Developer Pro	Solo metadata (más storage)	1 GB	1 día	Desarrollo en equipo o testing unitario
Partial Copy	Metadata + datos seleccionados por plantilla	5 GB	5 días	Testing con datos reales parciales
Full	TODO: metadata + todos los datos + archivos	Igual que producción	29 días	UAT, testing de rendimiento, staging

Detalles importantes por tipo:

Developer Sandbox:
- El más ligero y rápido de crear.
- Solo copia la configuración (objetos, campos, flows, page layouts, etc.).
- NO copia ningún dato (registros).
- Ideal para que un desarrollador trabaje de forma aislada.

Developer Pro Sandbox:
- Similar al Developer pero con más espacio de almacenamiento (1 GB vs 200 MB).
- Ideal cuando múltiples desarrolladores trabajan en el mismo proyecto.
- Tampoco copia datos.

Partial Copy Sandbox:
- Copia metadata + un subconjunto de datos definido por una Sandbox Template.
- La plantilla define qué objetos incluir y cuántos registros por objeto.
- Ideal para testing con datos reales pero sin copiar TODO.
- Máximo 5 GB de datos.

Full Sandbox:
- Copia ABSOLUTAMENTE TODO: metadata, datos, archivos adjuntos.
- Puede tardar horas o días en crearse dependiendo del volumen.
- Refresh mínimo: 29 días entre actualizaciones.
- Se usa para: UAT (User Acceptance Testing), testing de rendimiento, staging pre-producción, formación con datos reales.
- Es el más caro en términos de licencias.

Ciclo de vida recomendado del desarrollo:

Developer Sandbox → Developer Pro → Partial Copy → Full → Production
   (Desarrollo)     (Integración)    (QA/Testing)   (UAT)   (En vivo)

Sandbox Refresh (Actualizar):
- Actualizar un sandbox lo reemplaza completamente con una nueva copia de producción.
- Todos los cambios no migrados se pierden.
- Los intervalos de refresh son mínimos, no fijos — puedes esperar más pero no menos.

Sandbox Login:
- URL diferente: https://test.salesforce.com (no login.salesforce.com).
- Username: [email protected].
- Al crear un sandbox, solo los usuarios con el permiso activo se copian (con las contraseñas reseteadas).

Los Change Sets son la herramienta nativa de Salesforce para migrar metadatos (configuraciones) entre entornos conectados.

Conceptos fundamentales:

Outbound Change Set (Saliente):
- Se crea en el entorno de ORIGEN (ej: Developer Sandbox).
- Se seleccionan los componentes a migrar (objetos, campos, flows, page layouts, profiles, etc.).
- Se envía (Upload) al entorno de destino.
- El botón Add Dependencies analiza automáticamente qué componentes adicionales necesita tu selección.

Inbound Change Set (Entrante):
- Aparece en el entorno de DESTINO después del upload.
- Un administrador debe Deploy (desplegar) el Change Set manualmente.
- Antes de deployar, puede ejecutar Validate para verificar que no haya errores sin hacer cambios reales.
- El deploy puede incluir: Run default tests, Run specified tests, Run local tests, Run all tests.

Reglas críticas de Change Sets (preguntadas en el examen):
1. Solo funcionan entre entornos conectados (sandboxes de la misma org de producción).
2. Son unidireccionales — se envía desde el origen y se recibe en el destino.
3. Solo migran metadatos, NUNCA datos (registros).
4. NO migran: datos de Custom Settings, usuarios, datos de registros, perfiles completos (solo se migran cambios específicos de perfiles).
5. Los componentes se sobrescriben en el destino (no se fusionan).
6. Destructive changes (eliminar componentes) NO se pueden hacer con Change Sets.

Connection Settings:
Antes de poder usar Change Sets, los entornos deben estar conectados. Se configura en: Setup > Deploy > Deployment Settings. Cada entorno debe permitir explícitamente recibir Change Sets de otros entornos.

¿Qué componentes se pueden incluir en un Change Set?
- Custom Objects, Custom Fields, Page Layouts, Record Types.
- Flows, Validation Rules, Formula Fields.
- Profiles (parcial: solo permisos de los componentes incluidos), Permission Sets.
- Lightning Pages, Quick Actions, Custom Buttons.
- Apex Classes, Apex Triggers, Visualforce Pages, LWC.
- Reports, Dashboards, Email Templates.
- Custom Metadata Type Records (¡sí, se migran!).

Otras herramientas de despliegue:

Herramienta	Tipo	Uso principal
Change Sets	Declarativo (UI)	Migraciones simples entre sandboxes conectados
Salesforce CLI (sf/sfdx)	Línea de comandos	Desarrollo moderno, CI/CD, Scratch Orgs
Metadata API	API programática	Automatización de deployments, herramientas de terceros
Packages (Managed/Unmanaged)	Empaquetado	Distribución de soluciones
VS Code + Salesforce Extensions	IDE	Desarrollo con recuperación y despliegue de metadata

Salesforce CLI y Salesforce DX:
- Enfoque moderno de desarrollo basado en source control (Git).
- Usa Scratch Orgs (entornos temporales) en vez de Developer Sandboxes.
- Permite pipelines de CI/CD (integración continua / despliegue continuo).
- No es necesario para el examen PAB en profundidad, pero debes saber que existe.

Los Packages (paquetes) son contenedores de componentes de Salesforce que se pueden distribuir e instalar en otras organizaciones.

Unmanaged Packages (Paquetes no gestionados):
- Los componentes se instalan como copias independientes en la org destino.
- Una vez instalados, se pueden modificar libremente (son editables).
- NO soportan upgrades — no hay forma de actualizar componentes ya instalados.
- El creador pierde control sobre los componentes tras la instalación.
- Ideal para: plantillas de configuración, kits de inicio, transferencia de metadata entre orgs no conectadas.

Managed Packages (Paquetes gestionados):
- Los componentes están protegidos (código Apex ofuscado, componentes locked).
- El creador (ISV) mantiene control y propiedad intelectual.
- Soportan upgrades: Se pueden enviar actualizaciones a las orgs instaladas.
- Pueden publicarse en AppExchange tras pasar el Security Review.
- Los componentes instalados NO pueden ser modificados por el usuario (excepto configuraciones expuestas). Tienen un namespace prefix único.
- Ideal para: ISVs (Independent Software Vendors), distribución comercial de apps.

Tabla comparativa:

Característica	Unmanaged	Managed
Componentes editables	✅ Sí (después de instalar)	❌ No (protegidos/locked)
Soporta upgrades	❌ No	✅ Sí
Protección de IP (código)	❌ No	✅ Sí (ofuscado)
Namespace prefix	❌ No	✅ Sí (obligatorio)
AppExchange	❌ Generalmente no	✅ Sí
Desinstalar	✅ (elimina todo)	✅ (elimina todo)
Ideal para	Templates, transfer entre orgs	Distribución comercial, ISVs

Second-Generation Packaging (2GP):
- Modelo más moderno de empaquetado gestionado.
- Compatible con Salesforce DX y source-driven development.
- Soporta versionado semántico y mejor control de dependencias.
- No es tema profundo del examen PAB, pero debes saber que existe.

Proceso de publicación en AppExchange:
1. Desarrollar la solución en una Developer Org.
2. Crear un Managed Package con todos los componentes.
3. Enviar el paquete para Security Review de Salesforce.
4. Una vez aprobado, listar en AppExchange.
5. Los clientes instalan desde AppExchange.
6. Enviar upgrades cuando haya nuevas versiones.

Instalación de paquetes:
- Se instalan usando una URL de instalación o desde AppExchange.
- Al instalar, se elige: Install for Admins Only, Install for All Users, o Install for Specific Profiles.
- Las dependencias deben estar satisfechas antes de la instalación.

Concepto clave: Si te preguntan "cómo distribuir una solución a orgs no conectadas" → la respuesta es un Package (no Change Sets, que requieren entornos conectados).