Cómo resolver conflictos de fusión en Salesforce

En este artículo, aclararemos los problemas habituales de conflictos de fusión y sobrescritura de código que enfrentan los equipos de Salesforce, incluso cuando usan Git. Exploraremos sus causas principales, ejemplos prácticos y soluciones eficaces, incluido un enfoque particular conocido como selección de líneas específicas de metadatos y código.

Estas son nuestras 5 conclusiones clave:

• La «sobrescritura de código» y los «conflictos de fusión» son desafíos importantes para los equipos de Salesforce y ocurren cuando los cambios de distintos desarrolladores en el mismo código entran en conflicto.
• Las soluciones de desarrollo basadas en código fuente, como Salesforce DX, buscan ayudar a gestionar los conflictos de fusión, pero suelen quedarse cortas debido a problemas inherentes a la estructura de Salesforce.
• El algoritmo tradicional de Git para conflictos de fusión tiene dificultades para trabajar con Salesforce, lo que genera problemas en la detección y resolución de estos conflictos.
• La selección de líneas de código específicas a partir de la comparación de diferencias se ha convertido en una solución eficaz para evitar la sobrescritura de código y los conflictos de fusión en Salesforce.
• Establecer un entorno de integración donde cada desarrollador sea responsable de fusionar sus cambios es otro enfoque eficaz para gestionar los conflictos de fusión y la sobrescritura de código en Salesforce.

Los conflictos de fusión y la sobrescritura de código son algunos de los mayores desafíos para los equipos de Salesforce. Ya sea que uses conjuntos de cambios, scripts de Ant, Salesforce DX, o una herramienta comercial, simplemente no hay muchas buenas formas de lidiar con la «sobrescritura de código». Incluso si usas Git, probablemente no estés detectando correctamente los conflictos de fusión (por motivos que explicaremos en detalle más adelante).

Una de las mayores promesas de Salesforce DX es que usar desarrollo basado en el código fuente ayudará a los equipos de Salesforce a resolver conflictos de fusión e implementar fusiones como lo hace la mayoría de los equipos de software.

¿Qué es la «sobrescritura de código»?

La sobrescritura de código es algo sencillo, pero devastadoramente común para muchos equipos de Salesforce.

Supongamos que Joe está trabajando en una clase Apex: classOne.cls. La clase tiene 100 métodos. Joe solo está trabajando en methodB(). Susie también está trabajando en classOne.cls, pero en methodC() y methodD(). La sobrescritura de código ocurre cuando Joe envía cambios a classOne.cls que eliminan o «sobrescriben» los cambios de Susie. Esto sucede con frecuencia en Salesforce con todo tipo de metadatos: clases Apex, objetos, campos, tipos de registro, etc.

Para ilustrarlo un poco más, classOne.cls en el sandbox de Joe no incluye los métodos methodC() y methodD() que agregó Susie porque él no ha incorporado los cambios de ella en su rama u organización:

classOne.cls en el Integración entorno incluye los cambios de Susie:

La sobrescritura de código es lo que ocurriría si Joe enviara sus cambios a Integración mediante un conjunto de cambios o un script de Ant. Los cambios de Susie se perderían y habría efectos en cadena.

¿Qué es un conflicto de fusión en Salesforce?

A Un conflicto de fusión es lo que debería ocurrir en el escenario anterior si Joe y Susie usaran Git de la manera tradicional. En lugar de permitir que Joe sobrescriba los cambios de Susie sin saberlo, Git le notificaría que sus cambios entran en conflicto y le sugeriría cómo resolverlo adecuadamente. Lo más importante es que le impediría enviar sus cambios de una manera que sobrescribiera el arduo trabajo de Susie. Esto evita errores y la necesidad de revertir los cambios.

Lamentablemente, muchos administradores y desarrolladores de Salesforce no reciben este tipo de advertencia de conflicto de fusión porque los conjuntos de cambios y los scripts de Ant no ofrecen ningún mecanismo de fusión: sobrescriben el destino a ciegas con lo que haya en la organización de origen. Git debería ayudar, pero es bien sabido que resulta difícil usar Git con Salesforce. E incluso si lo haces, descubrirás que los conflictos de fusión son un dolor de cabeza especialmente intenso.

Por qué el algoritmo tradicional de Git para conflictos de fusión no funciona con Salesforce

Incluso los equipos de desarrollo de Salesforce más sofisticados tienen dificultades con los conflictos de fusión, aun cuando usan Git.

Aquí tienes un ejemplo de una llamada de ventas de esta semana (anonimizado, por supuesto):

Un desarrollador de javascript de Acme Inc. se entusiasmó con un proyecto para incorporar CI/CD al equipo de Salesforce. Así que creó una implementación de Circle CI con scripts de Ant. El equipo usa un flujo tradicional de Git para registrar los cambios que realiza en Salesforce en ramas de un repositorio de GitHub. Usa solicitudes de incorporación de cambios para fusionarlos en ramas superiores dedicadas a UAT, preproducción o producción. Una tarea nocturna de CI recoge los cambios de la rama y los implementa en el entorno de destino esa misma noche: una configuración de CI bastante típica.

Pero esta configuración no detecta los conflictos de fusión ni la sobrescritura accidental de código como esperaban.

Primero, el equipo tuvo que eliminar muchos metadatos de su repositorio de Git porque no lograba que los metadatos declarativos funcionaran bien con Git. Esto dejó grandes vacíos en los aspectos sobre los que Git podía advertirles cuando sí detectaba conflictos.

En segundo lugar, aunque los desarrolladores de Acme entendían el concepto de ramificación, al equipo de administradores y analistas de negocio le resultaba confuso. Cada vez que creaban una rama, interrumpían a un desarrollador para pedirle ayuda.

En tercer lugar (y lo más importante), el estilo de desarrollo basado en sandboxes, tan común entre los equipos de Salesforce, no funciona bien con el flujo de trabajo de Git. Es bien sabido que a Git le resulta difícil manejar XML, y todos los metadatos declarativos de Salesforce están en XML.

Además, seleccionar cambios específicos es difícil en Git. Cuando un administrador o desarrollador logra incorporar cambios en una rama, suelen aparecer muchos otros cambios en la comparación de diferencias (los entornos a menudo están muy desincronizados). Esto genera falsos positivos, una larga lista de posibles conflictos y una solicitud de incorporación de cambios muy difícil de fusionar. Un administrador o desarrollador tiene pocas posibilidades de saber qué se puede implementar y qué no.

(Nota: estas mismas condiciones pueden darse si estás usando Salesforce DX en lugar de scripts de Ant).

Primeros intentos de abordar estas brechas

En Blue Canvas, resolvimos los dos primeros problemas vinculando estrechamente las organizaciones con las ramas en Git. Registramos automáticamente los cambios en las ramas de Git para que todos los metadatos (incluidos los declarativos) estén en el repositorio en tiempo real. Así eliminamos las brechas en los metadatos, especialmente en los cambios declarativos. Creamos una interfaz sencilla, basada en Lightning Design System interfaz gráfica para crear solicitudes de incorporación de cambios y seleccionar archivos específicos, que permitía a los administradores y analistas de negocio evitar complicarse demasiado con las estrategias de ramificación y funcionaba con la estrategia tradicional de desarrollo basada en sandboxes que usaba la mayoría de los equipos.

Pero nos encontramos con un nuevo problema: establecer una base de referencia clara para detectar los conflictos de fusión.

En la mayoría de las organizaciones de Salesforce, rara vez existe un historial común entre las ramas de Git. Los sandboxes se actualizan en distintos momentos, lo que crea enormes diferencias entre las organizaciones. Estas diferencias provocaron dos problemas:

1. Las solicitudes de incorporación de cambios entre ramas a menudo tenían miles de diferencias, lo que generaba muchos falsos positivos irrelevantes durante la detección de conflictos de fusión
   

2. Era difícil establecer una base de referencia clara que permitiera filtrar estas diferencias y obtener una lista más pequeña y manejable.

‍

Al ver que esto no iba a funcionar, seguimos un camino más experimental aprovechando Darcs (una herramienta de control de versiones bastante académica que inicialmente, junto con Git, se perfilaba como una posible mejora frente a SVN, antes de que Git se convirtiera en la opción preferida de la mayoría de los desarrolladores). Pero Darcs seguía siendo un proyecto muy académico y no ofrecía el rendimiento suficiente para implementaciones grandes de Salesforce.

Selección de líneas específicas de metadatos y código

La respuesta a este desafío terminó siendo sencilla: permitir que los administradores y desarrolladores seleccionen líneas específicas a partir de la comparación de diferencias.

Volviendo a nuestro ejemplo de Joe y Susie, ahora Joe podía seleccionar con seguridad solo las líneas de methodB() e ignorar las demás líneas de classOne.cls, en particular, la eliminación de methodC() y methodD(). Ahora la actualización de Joe puede avanzar a los entornos posteriores sin poner en riesgo el trabajo de Susie.

Ampliar la solución de selección de cambios específicos fue la forma más sencilla, eficiente y eficaz de evitar desde el principio la sobrescritura de código y los conflictos de fusión. Descubrimos que a los desarrolladores de Salesforce les resultaba intuitiva.

Establecimos un Integración entorno (sandbox) y una rama donde cada desarrollador es responsable de fusionar sus cambios antes de que puedan promoverse a entornos posteriores. Se espera que cada desarrollador seleccione cuidadosamente sus cambios específicos y los incorpore en Integración rama. Los responsables de versiones u otros miembros del equipo siempre deberían poder enviar cambios con confianza desde Integración hacia las ramas de UAT, preproducción, QA o producción.

Configuración ideal para resolver conflictos de fusión en Salesforce

En resumen, aprendimos que era necesario contar con los siguientes elementos para evitar las sobrescrituras de código y gestionar los conflictos de fusión de una forma intuitiva para los administradores y desarrolladores de Salesforce.

• Cada sandbox tiene una rama dedicada (herramientas: GitHub, Bitbucket, Gitlab, Blue Canvas)
  

• Usa la automatización para mantener el sandbox o entorno sincronizado con la rama lo más cerca posible del tiempo real (herramientas: scripts de Ant, Salesforce DX, CircleCI, Jenkins, TravisCI, Blue Canvas)
  

• Usa la pestaña Formato de directorios de metadatos de Salesforce DX para dividir los archivos XML en componentes más pequeños (herramientas: Salesforce DX, Blue Canvas)
  

• Lleva un registro de TODOS los metadatos (o de tantos como puedas)
  

• Permite que los usuarios seleccionen archivos específicos entre ramas en lugar de intentar fusionar la rama completa (herramientas: Eclipse, Source Tree, Blue Canvas)
  

• Permite que los usuarios seleccionen líneas específicas dentro de cada archivo para evitar la sobrescritura de código y los conflictos de fusión (herramientas: Eclipse, Source Tree, Blue Canvas)
  

Configurar un sistema como este con Git y Salesforce me permite implementar cambios de forma segura sin provocar sobrescrituras masivas en cadena de los cambios de mis colegas. Y contar con esa seguridad me permite avanzar más rápido sin romper nada, que al fin y al cabo es el objetivo de CI/CD.

Blue Canvas: tu aliado para resolver y prevenir conflictos de fusión

Lo más reciente Funcionalidad de resolución de conflictos de fusión te permite abordar de frente los conflictos de fusión y las sobrescrituras de código, con herramientas diseñadas por desarrolladores para desarrolladores. 

Aprovecha nuestro enfoque exclusivo de selección de cambios por línea para mantener tu código limpio y a tu equipo sincronizado. Comienza hoy tu camino con Blue Canvas. ¡No solo resolverás los conflictos, sino que los evitarás por completo!

‍

--------

Preguntas frecuentes

¿Qué son las «sobrescrituras de código» y los «conflictos de fusión»?

• La sobrescritura de código ocurre cuando los cambios de un desarrollador en una base de código sobrescriben o reemplazan los de otro. Esto puede suceder cuando distintos desarrolladores trabajan en las mismas secciones de código. Un conflicto de fusión, por otro lado, ocurre cuando Git no puede resolver automáticamente las diferencias de código entre dos commits.

¿Por qué ocurren estos problemas en Salesforce, incluso cuando se usa Git?

• Estos problemas ocurren porque la estructura de desarrollo de Salesforce es diferente a la de un proyecto de software típico. Salesforce utiliza mucho XML para los metadatos declarativos, algo que Git tiene dificultades para manejar. Esto suele provocar una gestión inadecuada de los conflictos de fusión y, en consecuencia, sobrescrituras de código.

¿Cómo gestionan los conflictos de fusión las soluciones de desarrollo basado en código fuente, como Salesforce DX?

• Salesforce DX busca ayudar a gestionar los conflictos de fusión mediante un enfoque de desarrollo basado en código fuente. Sin embargo, suele quedarse corto debido a la complejidad de la estructura y los metadatos de Salesforce, que dificulta la detección y resolución tradicional de estos conflictos.

¿Qué es la selección de cambios por línea de código y metadatos, y cómo ayuda con los conflictos de fusión y las sobrescrituras de código?

• La selección de cambios específicos consiste en elegir cambios de una rama y aplicarlos a otra sin fusionar las ramas completas. Esto puede ser especialmente eficaz para gestionar los conflictos de fusión y evitar las sobrescrituras de código, ya que los desarrolladores pueden elegir qué partes del código quieren fusionar, lo que reduce el riesgo de sobrescribir el código de otra persona.

¿Cuál es la configuración ideal para resolver conflictos de fusión en Salesforce?

• La configuración ideal consiste en que cada sandbox tenga una rama de Git dedicada, con sincronización automática entre ambos. Se recomienda usar el formato de directorios de metadatos de Salesforce DX para dividir los archivos XML en componentes más pequeños. La configuración también debe permitir el seguimiento de todos los metadatos y la selección de archivos específicos entre ramas, así como de líneas dentro de cada archivo.

¿Por qué el algoritmo tradicional de Git para detectar conflictos de fusión no funciona bien con Salesforce?

• El algoritmo tradicional de Git para detectar conflictos de fusión tiene dificultades con Salesforce porque Salesforce utiliza mucho XML para los metadatos declarativos, algo que Git no maneja bien. Además, en Salesforce, los sandboxes suelen actualizarse en distintos momentos, lo que genera diferencias importantes entre las organizaciones y dificulta establecer un historial común entre las ramas de Git.

¿Cómo aborda Blue Canvas estos problemas relacionados con los conflictos de fusión y las sobrescrituras de código en Salesforce?

• Blue Canvas vincula estrechamente las organizaciones con ramas de Git y registra automáticamente los cambios en ellas para que todos los metadatos estén en el repositorio en tiempo real. Cuenta con una interfaz sencilla para crear solicitudes de incorporación de cambios y seleccionar archivos específicos. También permite seleccionar cambios línea por línea, para que los usuarios fusionen solo sus cambios específicos y eviten sobrescrituras de código y conflictos de fusión.

¿Qué es un entorno de integración en Salesforce y cómo ayuda a gestionar los conflictos de fusión?

• Un entorno de integración en Salesforce es un sandbox con una rama donde cada desarrollador es responsable de fusionar sus cambios antes de que puedan pasar a los siguientes entornos. Esta configuración garantiza que cada desarrollador se haga responsable de sus cambios y reduce el riesgo de sobrescrituras de código y conflictos de fusión.

¿Qué limitaciones o desafíos puedes encontrar al usar un flujo de trabajo tradicional de Git con Salesforce?

• Usar un flujo de trabajo tradicional de Git con Salesforce puede dificultar la gestión de los metadatos declarativos debido a su formato XML. También puede generar confusión entre los desarrolladores que no están familiarizados con el concepto de ramas. Además, el estilo de desarrollo con sandboxes que se usa habitualmente en Salesforce no se adapta bien al flujo de trabajo de Git.

¿Cómo puedes evitar falsos positivos y solicitudes de incorporación de cambios difíciles de gestionar al usar Git con Salesforce?

• Puedes evitar falsos positivos y solicitudes de incorporación de cambios difíciles de gestionar seleccionando cambios específicos para fusionar, en lugar de intentar fusionar ramas completas. Esto garantiza que solo se incluyan los cambios relevantes y reduce la probabilidad de falsos positivos.