DevOps y Gestión de Entregas en Salesforce

Cuando los releases empiezan a hacerse difíciles

Algunas señales son fáciles de reconocer:

• despliegues manuales que consumen demasiado tiempo;
• conflictos frecuentes de metadata;
• ambientes que dejan de estar sincronizados;
• cambios que funcionan en un ambiente pero fallan en otro;
• dificultad para saber qué versión está realmente en producción;
• dependencias entre componentes que aparecen demasiado tarde;
• back promotions manuales o inconsistentes;
• pruebas ejecutadas al final del proceso;
• cambios urgentes difíciles de incorporar al flujo normal;
• varios equipos trabajando sobre la misma org sin suficiente coordinación;
• poca trazabilidad sobre quién cambió qué y por qué.

El problema no suele ser únicamente la herramienta.

Es necesario revisar cómo trabajan juntos los equipos, los ambientes, el código, la metadata y el proceso de entrega.

Salesforce DevOps tiene características propias

Salesforce combina diferentes tipos de componentes:

• configuración declarativa;
• Flow;
• Apex;
• Lightning Web Components;
• objetos y campos;
• permission sets y seguridad;
• layouts;
• metadata;
• integraciones;
• configuraciones que pueden depender unas de otras.

Eso hace que el proceso de entrega sea diferente al de una aplicación tradicional.

Las prácticas generales de DevOps siguen siendo importantes, pero deben adaptarse al modelo específico de Salesforce.

Control de versiones

Saber qué cambió y conservar una fuente confiable

Git puede convertirse en la base para organizar y rastrear los cambios realizados sobre Salesforce.

Podemos apoyar en:

• estructura de repositorios;
• estrategia de ramas;
• pull requests;
• revisión de cambios;
• versionamiento de metadata;
• manejo de hotfixes;
• integración de trabajo de diferentes equipos;
• trazabilidad entre requerimientos y cambios.

La estrategia debe adaptarse al tamaño del equipo y a la frecuencia real de los releases.

Ambientes y estrategia de promoción

Un cambio necesita un camino claro hasta producción

Revisamos cómo se utilizan:

• sandboxes;
• ambientes de desarrollo;
• integración;
• pruebas;
• UAT;
• producción.

Y definimos cómo deberían moverse los cambios entre ellos.

El objetivo es reducir diferencias entre ambientes y evitar que el conocimiento sobre cómo desplegar dependa únicamente de unas pocas personas.

Automatización de despliegues

Menos pasos manuales. Más repetibilidad.

Dependiendo del ecosistema existente, podemos trabajar con herramientas y enfoques como:

• Salesforce DevOps Center;
• Copado;
• Flosum;
• SFDX / Salesforce CLI;
• GitHub;
• Azure DevOps;
• Bitbucket;
• pipelines de integración y entrega continua.

No proponemos una herramienta antes de entender el proceso.

Primero revisamos cómo trabaja el equipo, qué problemas necesita resolver y qué nivel de automatización tiene sentido.

Gestión de metadata y conflictos

Una de las diferencias más importantes de Salesforce DevOps

Los cambios en Salesforce pueden involucrar componentes declarativos y programáticos con múltiples dependencias.

Podemos ayudar a mejorar prácticas alrededor de:

• selección de metadata;
• dependencias entre componentes;
• resolución de conflictos;
• promociones;
• back promotions;
• sincronización entre ambientes;
• cambios paralelos;
• manejo de componentes destructivos;
• control de configuraciones sensibles.

El objetivo es disminuir sorpresas durante los releases y hacer más visible el impacto de cada cambio.

Calidad integrada al proceso

Las pruebas funcionan mejor cuando hacen parte del ciclo de entrega y no cuando aparecen solamente antes de producción.

Dependiendo del proyecto podemos incorporar:

• validaciones automáticas;
• pruebas Apex;
• análisis estático;
• pruebas funcionales;
• criterios de aceptación;
• validaciones previas al despliegue;
• revisión de código;
• controles sobre la calidad de los cambios.

La automatización no reemplaza la revisión técnica. Ayuda a detectar problemas antes y de forma más consistente.

Releases y gobierno

Entregar más rápido no significa perder control

Un proceso saludable debe permitir responder preguntas como:

¿Qué contiene este release? ¿Quién aprobó los cambios? ¿Qué fue probado? ¿Qué dependencias existen? ¿Qué ocurre si tenemos que revertir o corregir algo?

Podemos ayudar a definir:

• criterios para promover cambios;
• responsabilidades;
• ventanas de release;
• trazabilidad;
• manejo de excepciones;
• procedimientos de hotfix;
• documentación necesaria;
• métricas de entrega.

Evolución del proceso DevOps

No todas las organizaciones necesitan llegar inmediatamente al mismo nivel de automatización.

Podemos comenzar evaluando:

• cómo trabajan actualmente los equipos;
• qué herramientas utilizan;
• dónde se producen los mayores errores o retrasos;
• qué actividades siguen siendo manuales;
• qué problemas son de proceso y cuáles son de herramienta.

A partir de ahí podemos plantear una evolución gradual.

Assessment de Salesforce DevOps

También podemos comenzar únicamente con un diagnóstico.

Revisamos:

• ambientes;
• repositorios;
• estrategia de ramas;
• herramientas;
• proceso de promoción;
• manejo de conflictos;
• pruebas;
• automatización;
• releases;
• roles y responsabilidades.

El resultado puede ser una hoja de ruta priorizada para mejorar el proceso sin necesidad de reemplazar todo lo existente.

DevOps también es colaboración

Las herramientas son una parte del problema.

Un proceso de entrega saludable también necesita que administradores, desarrolladores, arquitectos, QA, negocio y responsables de releases puedan trabajar sobre una misma forma de operar.

Por eso combinamos prácticas técnicas con acuerdos claros sobre responsabilidades, criterios de aceptación y cómo deben llegar los cambios hasta producción.