La verdad no contada sobre Git con Salesforce

El término DevOps abarca hoy tantas expectativas y herramientas que una pregunta sencilla como “¿Mi equipo está haciendo DevOps?” puede recibir respuestas muy diferentes según a quién le preguntes. En el peor de los casos, esto genera expectativas incumplidas: crees que estás aumentando la velocidad porque configuraste una “herramienta de DevOps”, cuando en realidad sigues limitado por funcionalidades insuficientes o casos de uso no cubiertos.

El control de versiones del código fuente es un gran ejemplo de una funcionalidad de DevOps que puede quedarse corta. Con la creciente popularidad de DevOps para Salesforce, ahora existen muchas soluciones para conectar una organización a un repositorio de Git. Pero eso es solo la punta del iceberg: sí, puedes obtener un historial de revisiones, pero ¿realmente puedes fusionar sin problemas el trabajo de distintos sandboxes? ¡Veamos en detalle qué se necesita realmente para habilitar un flujo de trabajo de DevOps en Salesforce!

La entrada: historial de cambios y reversiones en Salesforce

Lo bueno de Git es que, en cuanto lo incorporas a tu flujo de trabajo (y adoptas el concepto de hacer commits), obtienes beneficios inmediatos sin configuración adicional. Entre ellos:

• Un historial detallado de los cambios en tus archivos y datos (es decir, el historial de commits)Comparar versiones en solo unos segundos (es decir, comparar diferencias)
• Volver a una versión anterior con solo unos comandos
• Aplica eso al mundo de Salesforce y, siempre que tus sandboxes estén sincronizados con un repositorio de Git, podrás revisar de un vistazo los cambios en tus metadatos de Salesforce, comparar sandboxes y, si lo necesitas, revertir implementaciones recientes con mayor facilidad.

Compara eso con la situación de la comunidad cuando los conjuntos de cambios eran la única opción y verás cuánto se ha avanzado en herramientas y experiencia para desarrolladores.

Esta capacidad de llevar un seguimiento exhaustivo de los cambios a lo largo del tiempo ya resulta muy útil para los equipos de desarrollo. Es tu respaldo e historial completo en un solo lugar, todo separado en pequeños cambios de cada desarrollador. La situación se complica al revisar el trabajo en curso: varios desarrolladores pueden estar trabajando en la misma funcionalidad, en secciones de código que se superponen. Consolidar e implementar esos cambios sin contratiempos requiere funciones más complejas y nos lleva a hablar de la fusión.

El plato fuerte: la fusión de Git para Salesforce (¡cuando el trabajo en equipo hace realidad los sueños!)

En Blue Canvas hemos escuchado a demasiados equipos de Salesforce compartir su frustración con herramientas de Git “aceptables” que les fallaban cada vez que los desarrolladores enviaban cambios en conflicto. Distintas herramientas pueden comportarse de distintas maneras:

• Algunas fallan de forma explícita y dejan que el usuario final diagnostique el problema y vuelva a enviar el cambio
• Algunas pueden pasar por alto por completo la existencia de un conflicto de fusión y, en ese caso, sobrescribir silenciosamente uno de los cambios de código existentes

El escenario típico es el siguiente:

Aquí es donde resulta útil la fusión. Si conoces Git, probablemente sea una de las funciones que más aprovechas. Pero si apenas estás empezando, entonces la fusión es un concepto que aún puede resultar difícil de entender. La documentación de git-merge por sí sola demuestra la amplitud del tema (mostrar conflictos; resolverlos; estrategias de fusión…). Aunque puede resultar abrumador desde el punto de vista técnico, las implicaciones funcionales son bastante claras:

• Si no hay detección de conflictos de fusión, no existe ninguna protección que evite que un desarrollador sobrescriba el trabajo de otro sin siquiera darse cuenta
• En el contexto de Salesforce, tener sandboxes individuales conectados cada uno a un repositorio de Git no aporta nada por sí solo a la hora de consolidar el trabajo realizado en esos sandboxes separados
• Poder consolidar el trabajo de distintos desarrolladores y sandboxes también significa que tus herramientas de DevOps deben poder determinar los denominadores comunes (ancestros comunes en la terminología de Git) entre esos entornos de trabajo separados

Este conjunto de problemas explica por qué DevOps para Salesforce es mucho más que conectar un repositorio de Git a una organización de Salesforce. Un flujo de trabajo confiable de Git requiere una funcionalidad adecuada de resolución de conflictos de fusión. Una que avise al equipo de desarrollo cuando surja un conflicto y que también guíe a los desarrolladores para enviar el código esperado y seguro a UAT y producción.

En Blue Canvas creemos que resolver este problema es esencial para hacer posible “DevOps para Salesforce”. Es lo que realmente permitirá a los equipos colaborar en un mismo entorno de Salesforce, con varios desarrolladores que puedan trabajar cada uno en su propio sandbox y después combinar su trabajo de forma confiable y eficiente para entregar funcionalidades en producción.

Un enfoque práctico para reducir los conflictos de fusión

En ingeniería de software se suele decir que “no hay una solución mágica”, y creemos que esto también se aplica por completo a mejorar los flujos de trabajo de Git. Tras recibir comentarios de empresas y organizaciones de todos los tamaños, pronto nos dimos cuenta de que diversas funciones pueden ayudar a resolver el problema de los cambios en conflicto dentro de un equipo. Algunos ejemplos concretos que hemos implementado con el tiempo:

• Una experiencia de usuario dedicada a revisar diferencias y comentarlas: esto permite a los integrantes del equipo avisar fácilmente sobre un posible conflicto con aquello en lo que están trabajando
• Sincronización rápida entre Salesforce y tu repositorio de Git: cuanto menos tardes en sincronizar los cambios de Salesforce con tu repositorio de Git, antes podrás detectar cambios potencialmente conflictivos que debas incorporar primero
• Rendimiento general de la herramienta: cuanto más rápido puedan tus desarrolladores compilar y enviar cambios de código, más probable será que envíen pequeños fragmentos con frecuencia, en lugar de bloques grandes con más probabilidades de entrar en conflicto con otros cambios

En definitiva, seguimos enfocados en facilitar el trabajo en equipo y reducir el tiempo de despliegue. 🚀 Por supuesto, aún hay más por hacer, incluido ese problema específico de resolución de fusiones. Antes de fin de año anunciaremos una nueva función de Blue Canvas: una integración renovada con Git que permite detectar y resolver por completo las fusiones de 3 vías directamente desde nuestra interfaz de despliegue. Menos sorpresas de último momento, más control sobre los cambios en tu código y, ¡una vez más!, despliegues más rápidos. Mantente al tanto de las novedades.

Reflexiones finales

Este artículo es el primero de una serie en la que compartiremos regularmente nuestros avances para ofrecer un control de código fuente con Git de primer nivel a los equipos de Salesforce. Ya puedes leer sobre nuestros esfuerzos recientes para cómo reducir a menos de un minuto el tiempo de sincronización entre un sandbox y un repositorio Git, que, como mencionamos en este artículo, es la base de funciones más avanzadas de Git.

Mientras tanto, te invitamos a registrarte gratis en https://accounts.bluecanvas.io/signup. Solo conecta tus organizaciones, compáralas en segundos y agiliza tu flujo de despliegue. Esperamos que disfrutes la experiencia; nos encantaría recibir tus comentarios y sorprenderte con más funciones nuevas este año. Puedes mantenerte en contacto suscribiéndote a nuestro boletín, o siguiéndonos en Twitter @bluecanvasio!

ACTUALIZACIÓN: ¡ya publicamos nuestro siguiente artículo sobre Salesforce+Git! Lee sobre Por qué la fusión es la parte más difícil de integrar Git con Salesforce

Saludos,
El equipo de Blue Canvas

‍