Release

Un release de Salesforce es una de las tres actualizaciones estacionales que la plataforma aplica sola, sin que el cliente instale nada, a todas sus instancias a lo largo del año: Spring, Summer y Winter. Cada una incorpora cientos de funciones nuevas, mejoras y parches de seguridad, y se conoce con meses de anticipación: sabés qué va a cambiar antes de que cambie.

La analogía más útil es la actualización del sistema operativo de un teléfono: llega automáticamente, suma capacidades y corrige seguridad. La diferencia clave es la previsibilidad. Cada release se acompaña de release notes que documentan cada cambio, y los sandboxes de preview reciben la versión varias semanas antes que producción, de modo que podés ensayarla sin riesgo.

Un release no lo desplegás vos: lo empuja Salesforce. Eso lo distingue de tus propios cambios, que sí controlás y liberás desde un sandbox. Entender esa diferencia es parte del oficio de cualquier equipo de desarrollo sobre Salesforce, porque un release mal anticipado puede alterar automatizaciones, integraciones o código a medida.

Qué actualiza un release

Un release no es un parche puntual: actualiza toda la plataforma a la vez. En un mismo ciclo llegan funciones nuevas de productos como Sales Cloud o Service Cloud, mejoras en las herramientas de desarrollo, cambios en la interfaz y, sobre todo, actualizaciones de seguridad y nuevas versiones de la API. Lo importante es que el cliente no instala nada: Salesforce empuja la versión a cada instancia de forma automática, dentro de una ventana de mantenimiento breve.

El calendario: tres releases al año

La cadencia es estacional y fija, lo que permite planificar con meses de anticipación:

• Spring: típicamente alrededor de febrero.
• Summer: alrededor de junio.
• Winter: hacia octubre.

Además de estos tres grandes hitos, algunos productos reciben actualizaciones mensuales más chicas. Cada release mayor se acompaña de sus release notes, la documentación oficial que detalla función por función qué se agrega, qué cambia y qué se deja de soportar. Semanas antes de que la versión llegue a producción, los sandboxes de preview ya la tienen, así que podés ensayar en un entorno espejo. Y cada instancia tiene su propia ventana de mantenimiento, publicada con anticipación en el estado de Salesforce (Trust), donde figura la fecha real de tu actualización, más confiable que la del blog.

Por qué le importa a una empresa de LATAM

Para una empresa mediana, un release rara vez es visible en la superficie, pero puede alterar lo que corre por debajo: una automatización, una integración con el ERP o el core bancario, o una porción de código a medida. Ignorarlo es arriesgarse a que algo se rompa el fin de semana de la actualización, sin nadie de guardia. La disciplina sana es leer las release notes apenas salen, refrescar un sandbox de preview, correr una batería de pruebas de regresión y ajustar lo necesario antes de la ventana de producción. Ese trabajo de anticipación forma parte del oficio de cualquier equipo de desarrollo sobre Salesforce.

Release de plataforma vs despliegue propio

Los dos usos de la palabra "release" se confunden seguido, pero son cosas distintas:

En un release de plataforma no elegís la fecha ni el contenido: te preparás. En un despliegue propio controlás todo el proceso, desde un sandbox hasta producción.

Errores comunes

• No leer las release notes y enterarse de los cambios cuando ya están en producción.
• No tener un sandbox de preview para testear la próxima versión antes de tiempo.
• Confundir la fecha del blog con la ventana real de tu instancia, que puede caer otro fin de semana.
• Subir versiones de API en masa sin medir el impacto sobre integraciones y código existente.

Anticiparse a cada release no es un lujo: es la diferencia entre vivir la actualización como una sorpresa de fin de semana o como un trámite planificado.