Estrategia de entornos
Mapa de sandboxes, scratch orgs y UAT ajustado al ritmo real de trabajo.
CI/CD y DevOps para Salesforce
Las releases dejan de ser un evento estresante cuando tienen un proceso.
Construimos un pipeline de entrega gobernado para Salesforce: una única fuente de verdad en Git, entornos definidos, pruebas automáticas, puertas de calidad y una ruta de rollback, para que cada cambio llegue a producción de forma previsible y documentada.
Pipeline de entrega
Cómo viaja un cambio del desarrollo a producción
El diagrama muestra el pipeline completo, desde el entorno donde se escribe el cambio hasta los controles posteriores a la salida a producción.
Governed Release Pipeline
Origen
Dónde nace el cambio
- Scratch org / sandboxDesarrollo aislado
- Metadatos en GitFuente única de verdad
- Rama por tareaTrazable al requisito
Integración
Qué se ejecuta solo
- Pull requestRevisión obligatoria
- Análisis estáticoPMD y estándares
- Pruebas ApexCobertura y calidad
Puertas de calidad
Qué bloquea la promoción
- Cobertura mínimaUmbral acordado
- Suite de regresiónEscenarios críticos
- Aprobación de negocioUAT documentada
Release
Cómo se llega a producción
- Despliegue automáticoMismo artefacto
- Datos de entornoEntornos consistentes
- Ventana de releasePlanificada y anunciada
Control
Qué ocurre después
- Rollback planificadoCamino de vuelta claro
- Monitorización y alertasUmbrales definidos
- Notas de versiónDocumentadas por release
Contexto
Lo que realmente determina el resultado
En la mayoría de las organizaciones los incidentes de release no se deben a código deficiente, sino a la ausencia de proceso. Los cambios se hacen directamente en un entorno, nadie sabe con exactitud qué se desplegó y no existe una vuelta atrás ordenada.
CI/CD en Salesforce no es solo herramienta. Es un acuerdo sobre qué se considera un cambio aprobado, quién lo aprueba, qué verificaciones deben pasar y qué sucede cuando algo falla.
El resultado correcto no es más automatización por sí misma, sino una cadencia mayor con menos sorpresas, y cada versión explicable, reproducible y reversible.
Áreas de trabajo
Qué hacemos en la práctica
Metadatos en Git
Estructura del repositorio, ramas y política de merge sostenible para el equipo.
Pipeline automático
Build, pruebas y despliegue con GitHub Actions, Azure DevOps o Gearset.
Puertas de calidad
Cobertura, análisis estático y aprobación de negocio como condición de promoción.
Datos de entorno
Conjuntos de prueba consistentes sin copiar datos sensibles de producción.
Release y rollback
Ventanas de release, notas de versión y vuelta atrás definida de antemano.
Modelo de madurez
Dónde está la organización hoy
La mayoría se sitúa entre el nivel 1 y el 3. El salto más significativo es adoptar Git como fuente de verdad.
| Nivel | Cómo se ve | Riesgo principal | Siguiente paso |
|---|---|---|---|
| 1 — Manual | Change sets y ediciones directas en producción | Sin registro ni vuelta atrás | Llevar los metadatos a Git |
| 2 — Parcialmente gobernado | Existe Git pero el despliegue es manual | Desviación entre entornos | Automatizar el despliegue |
| 3 — Automatizado | Un pipeline se ejecuta en cada pull request | Pruebas débiles que aprueban todo | Definir puertas de calidad reales |
| 4 — Gobernado | Las puertas de calidad bloquean la promoción | Releases retrasadas por un proceso pesado | Enfocar la suite de regresión |
| 5 — Continuo | Releases frecuentes con rollback conocido | Complacencia operativa | Monitorización y revisiones periódicas |
1 — Manual
- Cómo se ve
- Change sets y ediciones directas en producción
- Riesgo principal
- Sin registro ni vuelta atrás
- Siguiente paso
- Llevar los metadatos a Git
2 — Parcialmente gobernado
- Cómo se ve
- Existe Git pero el despliegue es manual
- Riesgo principal
- Desviación entre entornos
- Siguiente paso
- Automatizar el despliegue
3 — Automatizado
- Cómo se ve
- Un pipeline se ejecuta en cada pull request
- Riesgo principal
- Pruebas débiles que aprueban todo
- Siguiente paso
- Definir puertas de calidad reales
4 — Gobernado
- Cómo se ve
- Las puertas de calidad bloquean la promoción
- Riesgo principal
- Releases retrasadas por un proceso pesado
- Siguiente paso
- Enfocar la suite de regresión
5 — Continuo
- Cómo se ve
- Releases frecuentes con rollback conocido
- Riesgo principal
- Complacencia operativa
- Siguiente paso
- Monitorización y revisiones periódicas
Cómo trabajamos
Etapas de ejecución
- 01
Mapa de situación
Entornos, herramientas, cadencia y puntos reales de fallo.
- 02
Diseño del pipeline
Ramas, entornos y puertas de calidad adecuadas al equipo.
- 03
Montaje de la infraestructura
Repositorio, automatización y primeras verificaciones en pruebas.
- 04
Ejecución en paralelo
El nuevo pipeline convive con el proceso actual hasta estabilizarse.
- 05
Transición del equipo
Procedimientos, permisos y formación por rol.
- 06
Control continuo
Medición de cadencia, fallos y tiempo de recuperación.
Continuar desde aquí
Servicios y guías relacionados
Preguntas frecuentes
Preguntas habituales
¿Hace falta un equipo grande para justificar CI/CD?
No. Un equipo de dos o tres personas ya se beneficia, porque el valor principal es la certeza y la trazabilidad, no el volumen. Un equipo pequeño simplemente recibe un pipeline más simple.
Trabajamos sobre todo con Flow y configuración. ¿Aplica igual?
Sí. Los cambios de configuración y automatización son metadatos como cualquier otro y son una causa frecuente de incidentes. Gestionarlos en Git aporta visibilidad completa.
¿Qué herramientas utilizan?
La elección depende de la organización. GitHub Actions o Azure DevOps encajan con equipos técnicos, mientras que Gearset o Copado funcionan mejor cuando predomina la configuración.
¿Cuánto tarda la implantación?
Un pipeline básico entra en funcionamiento en pocas semanas. La ampliación a puertas de calidad completas y regresión se hace de forma gradual para no frenar el desarrollo.
Siguiente paso
Diseñar el proceso de release
Analizamos cómo funcionan hoy sus entornos y releases y definimos el pipeline adecuado a su ritmo.
Siguiente paso
Diseñar el proceso de release
Analizamos cómo funcionan hoy sus entornos y releases y definimos el pipeline adecuado a su ritmo.