Saltar al contenido
← Volver a proyectos
Pipeline CI/CD — Despliegue Salesforce multi-entorno — imagen de portada
Proyecto personal

Pipeline CI/CD — Despliegue Salesforce multi-entorno

Branching Git, validación Apex automatizada y un procedimiento de rollback documentado para releases de Salesforce — no una simple checklist de despliegue

Contexto

Salesforce no tiene una historia CI/CD nativa: los despliegues entre sandboxes y producción se hacen con Change Sets point-and-click o con scripts caseros — y «funcionaba en mi sandbox» es un modo de fallo habitual. Construí este pipeline como proyecto personal para aplicar la misma disciplina de release que aplicaría en cualquier plataforma — protección de ramas, validación automática en cada Pull Request, promoción por etapas, procedimiento de rollback documentado — adaptada a las restricciones propias de los despliegues de metadatos de Salesforce: sin rollback parcial, cobertura de tests Apex obligatoria, metadatos específicos de cada entorno.

Lo que construí

  • Estrategia de ramas Git: feature → develop → main, con protección de las ramas develop y main
  • Workflow de GitHub Actions: validación Apex + tests automáticos en cada Pull Request
  • Despliegue automático al sandbox de integración al hacer merge en develop, y al sandbox de validación (staging) al hacer merge en main
  • Paso a producción mediante Quick Deploy, lanzado manualmente tras la validación de usuario, reutilizando la validación ya ejecutada contra producción
  • Gestión de credenciales Salesforce vía GitHub Secrets (SFDX Auth URL cifrada)
  • Notificaciones de estado de despliegue integradas en cada etapa del pipeline

Herramientas y tecnologías

  • Salesforce CLI (SFDX) — empaquetado y despliegue de metadatos
  • GitHub Actions — orquestación del pipeline CI/CD
  • GitHub Secrets — gestión segura de credenciales SFDX
  • Apex Test Run — ejecución automatizada de pruebas unitarias
  • SFDX Source Format — control de versiones de metadatos Salesforce

Pasos de implementación

  1. 1
    Análisis
    Mapeo de entornos (Dev, Staging, Prod) y definición de una estrategia de ramas adaptada al ciclo de release de Salesforce
  2. 2
    Configuración SFDX
    Inicialización del proyecto en SFDX Source Format, configuración de .forceignore y autenticación vía SFDX Auth URL
  3. 3
    Pipeline CI
    Workflows de GitHub Actions: job de validación Apex con ejecución de tests unitarios en cada Pull Request hacia develop y hacia main
  4. 4
    Pipeline CD
    Automatización de despliegues: sandbox de integración al merge en develop, sandbox de validación (staging) al merge en main junto con una validación en seco contra producción — después, un Quick Deploy a producción lanzado manualmente que reutiliza ese test run validado en vez de repetir toda la suite
  5. 5
    Seguridad
    Credenciales SFDX Auth URL almacenadas en GitHub Secrets; develop y main protegidas por comprobaciones de estado obligatorias (la validación de CI debe pasar antes de cualquier merge)
  6. 6
    Procedimiento de rollback
    Los despliegues de metadatos de Salesforce no tienen deshacer nativo. Procedimiento documentado: revertir el commit de merge en main, re-etiquetar el último paquete validado y volver a desplegarlo por el mismo pipeline CI — tan largo como un despliegue normal, por diseño, ya que no existe atajo posible para metadatos Salesforce

Decisiones y límites

  • El Quick Deploy reutiliza el test run ya validado en la etapa de CI en vez de repetir toda la suite Apex — Salesforce lo permite dentro de una ventana de validación de 10 días, recortando minutos en cada release sin sacrificar cobertura
  • Sin disparador automático de rollback: el rollback sigue siendo el procedimiento manual documentado arriba, no una herramienta de un clic — construir un rollback automatizado real para metadatos Salesforce sería un proyecto aparte
  • La protección de rama se basa en comprobaciones de estado obligatorias, no en una revisión humana impuesta: en un pipeline con una sola mantenedora, GitHub no permite aprobar la propia Pull Request — un revisor obligatorio es la primera regla que añadiría con una segunda persona en el equipo
  • Sin pruebas de humo tras el despliegue: el pipeline valida antes de desplegar, no después — la primera limitación que resolvería si este pipeline tuviera que dar servicio a una org de producción real hoy

Resultados

3
Entornos cubiertos
Integración, validación, producción
> 75%
Cobertura de tests
Apex — requerida para el despliegue