Por qué la fusión es la parte más difícil de integrar Git con Salesforce

Esta publicación es la #2 de nuestra serie sobre Git+Salesforce. Si no has leído la publicación anterior, consulta por qué DevOps para Salesforce es más que conectar un repositorio Git a una organización de Salesforce .

Sobrescribir el trabajo de un colega es lo último que quieres que ocurra al desplegar en Salesforce. Sin embargo, la realidad es que, usando solo conjuntos de cambios e incluso la mayoría de las herramientas de DevOps para Salesforce, sigues muy expuesto a ese riesgo. Aunque integrar Git con Salesforce es un paso en la dirección correcta, hace falta más para evitar realmente estos problemas. La fusión de cambios es clave, y es un problema difícil de resolver. Veamos ejemplos concretos de cómo pueden ser las fusiones en entornos de Salesforce y qué se necesita realmente para resolverlas.

Código Apex: cuando el conflicto es evidente

La fusión de Git entra en acción cuando un archivo se modifica desde varias fuentes (o ramas de Git). Más adelante hablaremos de los metadatos de Salesforce. Por ahora, empecemos con un escenario sencillo: código Apex en el que Charlie y Elliot están trabajando por separado.

El siguiente código proviene de la aplicación dreamhouse de Trailhead. SlackOpportunityPublisher.cls envía un aviso sobre oportunidades modificadas en un canal de Slack. En su sandbox, Charlie está agregando una funcionalidad a esa clase (agregar la nueva etapa de la oportunidad modificada):

Elliot también está trabajando en esa clase. La está editando directamente en UAT para aclarar una ambigüedad en la notificación de Slack (solo informa sobre la primera oportunidad modificada, aunque puede haber más):

Como Elliot modificó UAT directamente, Charlie ahora está trabajando con una versión desactualizada. Ni Charlie ni su sandbox tienen conocimiento de esa modificación. Cuando Charlie despliegue su código en UAT, el cambio de Elliot podría sobrescribirse sin aviso. A menos, claro, que las herramientas de Charlie y Elliot cuenten con algún tipo de detección de conflictos de fusión.

Es fácil pensar que los cambios en conflicto en una misma línea son lo más obvio que hay que detectar (adelanto: no es tan sencillo sin el concepto de un «ancestro común»). Pero antes de abordar eso, consideremos un escenario ligeramente distinto.

Fusionar cambios distintos en un mismo archivo Apex

Cambiar una sola línea es una cosa, pero las situaciones cotidianas suelen implicar cambios en distintos archivos o en varias líneas del mismo archivo. Si lo vemos desde la perspectiva de un despliegue en Salesforce:

• que varios desarrolladores modifiquen cada uno su propio conjunto de archivos no representa un gran problema. Cada uno le indicará a Salesforce que despliegue sus propios cambios, sin interferir con los demás.
• Las cosas se complican cuando varios desarrolladores trabajan en el mismo archivo. Desde la perspectiva del despliegue, surgen preguntas: ¿cuál es el origen común? ¿Debería confiar más en un cambio que en otro? ¿Qué cambios debería seleccionar?

Los conjuntos de cambios no resuelven ninguna de esas preguntas. Desplegarían todo el archivo a ciegas, sin ninguna de esas consideraciones. Podemos ilustrarlo volviendo a SlackOpportunityPublisher.cls:

• En su sandbox, Elliot agrega un mensaje a la notificación de Slack para indicar cuántas oportunidades adicionales se modificaron, si las hay:

• Luego, Charlie agrega contexto a esas notificaciones de Slack para dejar claro qué aplicación se está comunicando de repente:

En una implementación tradicional de Salesforce, la secuencia de eventos sería así:

• Elliot implementa en UAT y su cambio queda activo
• Charlie implementa en UAT (sin detección de conflictos), se «promueve» todo su archivo y se borra el cambio de Elliot

Por eso la fusión es tan esencial para los equipos que trabajan en conjunto. Y por eso creemos que detectar conflictos de fusión es imprescindible para cualquier herramienta de DevOps que aspire a prosperar en el ecosistema de Salesforce. Ahora, piensa en esto desde la perspectiva de una herramienta:

• Después de que Elliot implementa, ¿cómo sabe la herramienta que Charlie no quiere realmente deshacer el cambio de Elliot?
• En términos más generales, ante cualquier diferencia entre el sandbox de Charlie y la organización de UAT, ¿cuáles son los cambios que Charlie quiso hacer explícitamente y cuáles provienen de otras fuentes?

Responder estas preguntas no solo requiere un control de versiones preciso con Git (consulta nuestra publicación anterior sobre el tema), también implica llevar un seguimiento riguroso de la relación entre las organizaciones. En la terminología de Git, esto se conoce como seguimiento del «ancestro común» (piensa en ramas que se separan y vuelven a unirse):

• Sin seguimiento del historial ni de las relaciones, la herramienta considera a ciegas que la implementación final de Charlie es la fuente definitiva que debe implementarse => se sobrescribe el trabajo de Elliot.
• Con la detección de conflictos de fusión, la herramienta puede advertir que el trabajo de Charlie se basa en una versión anterior a la que ahora está activa en UAT (después del cambio de Elliot) => las herramientas les dan a Charlie y a su equipo la oportunidad de ajustar y corregir las cosas ✌️

Por ejemplo, esto es lo que Blue Canvas invita al usuario a hacer en un caso así:

En realidad, esa captura de pantalla contiene varios datos:

• Se requiere una fusión; es decir, Blue Canvas detectó que al trabajo de Charlie le faltan algunas implementaciones recientes en UAT.
• La fusión puede hacerse con solo un clic. Blue Canvas puede determinar que no hay conflictos entre líneas y que todos los cambios de código de ese archivo pueden combinarse.

Más allá de los detalles, lo importante es que los desarrolladores ganan poder y control 💪 Saben claramente que el resultado final no será exactamente igual a lo que trabajaron (porque también hubo cambios en la organización de destino) y tienen pleno control sobre los siguientes pasos (en lugar de implementaciones a ciegas y riesgos de borrar el trabajo de otros). Y no se trata solo de código Apex: los administradores de Salesforce merecen el mismo poder y control cuando trabajan con metadatos de Salesforce. Veamos un ejemplo.

Fusionar metadatos de Salesforce

Con el enfoque de bajo código de Salesforce, puede parecer más difícil entender cómo se ve un conflicto de fusión en la práctica. Pero se aplica el mismo concepto: basta con observar la representación de los datos subyacentes.

El código siguiente proviene de la aplicación Nebula Logger (una herramienta genérica de registro para Salesforce), que ofrece un campo llamado «Tipo de entorno» (campo de lista de selección). En su sandbox, Charlie agrega un nuevo valor posible («UAT») a ese campo. Internamente, el cambio se encuentra en un archivo XML:

Por su parte, Elliot también está trabajando para agregar otro Tipo de entorno , llamado «Preproducción»:

Ahora que vemos la estructura de datos subyacente, podemos entender claramente cómo esto también generará un conflicto de fusión. ¿Cuál de los nuevos valores de la lista de selección es el correcto? ¿O deberían agregarse ambos? ¿Deberían ser el mismo, con un nombre acordado? Son preguntas abiertas que el equipo debe resolver. Y, para eso, al menos necesita conocer ese conflicto subyacente.

En definitiva, el razonamiento es el mismo que en los ejemplos de Apex anteriores: para fusionar sandboxes de Salesforce en una organización común, se necesita un seguimiento riguroso del origen y conocimiento de los ancestros comunes. Probablemente te encantaría automatizar todo esto, pero vale la pena pensarlo dos veces.

Fusiones en Salesforce y Git: por qué la automatización total es un señuelo

Al repasar los ejemplos, resulta tentador esperar soluciones mágicas que detecten automáticamente y resolver cualquier posible daño. En Blue Canvas sabemos que no existe tal solución mágica. Piensa en las conclusiones clave de cada uno de los ejemplos anteriores:

• Conflicto detección ¡ya es un gran logro! Aporta un enorme valor porque permite que el desarrollador y su equipo estén al tanto de un riesgo existente (por ejemplo, perder trabajo valioso o implementar cambios no deseados). Sin eso, todos trabajan a ciegas.
• Conflicto resolución depende de muchos otros factores: ¿en qué se basan los cambios? ¿Están relacionados de alguna manera? ¿Es realmente seguro agruparlos? Las herramientas pueden ayudar a responder algunas de estas preguntas, pero la responsabilidad sobre qué código llega a producción debe seguir en manos del desarrollador y su equipo. ¡La lógica de negocio está en juego!
• Esto es aún más cierto con las soluciones de bajo código, donde el usuario final no ve explícitamente cómo se registran los cambios internamente (por ejemplo, la actualización de un campo) ni cuál sería el resultado de una fusión.

Más fundamentalmente, si al igual que nosotros confías plenamente en Git, puedes consultar directamente git-mergela propia documentación:

Al ver un conflicto, puedes hacer dos cosas. [1] Decidir no fusionar. [2] Resolver los conflictos. Git marcará los conflictos en el árbol de trabajo. Edita los archivos según sea necesario y agrégalos git add al índice mediante

Esto significa que resolver cualquier conflicto está en tus manos. Git está ahí para detectarlos y, cuando sea posible, manejar los casos evidentes (por ejemplo, cambios en archivos diferentes). Pero cuando no hay una solución evidente, el desarrollador está a cargo.

Cómo buscamos ayudarte en Blue Canvas

La misión de nuestro equipo es ofrecer excelentes herramientas de implementación para Salesforce impulsadas por Git, y sabemos muy bien que eso implica abordar el problema de los conflictos de fusión. Nuestra comunidad de usuarios y clientes también ha demostrado un gran interés en recibir ayuda con esto. Por eso escribimos esta serie de publicaciones sobre Salesforce+Git: para que todos partamos de una definición común del problema que estamos resolviendo. ¡Y, al mismo tiempo, nuestros ingenieros están preparando excelentes funcionalidades para ayudarte!

Como muestran algunas capturas de pantalla de esta publicación, estamos lanzando nuestra primera versión de detección de conflictos de fusión. Ya está disponible en beta pública y se está habilitando gradualmente para todas las cuentas existentes. Creemos que esta funcionalidad marcará otro antes y después, y esperamos recibir más comentarios. No te pierdas nuestra próxima publicación, con una guía completa de la funcionalidad.

‍