5 lecciones aprendidas en 5 años con Salesforce y Git
Lo que hemos aprendido al profundizar en Salesforce y Git más de lo que jamás imaginamos.
Por Randalyn Hill-Coffer·Revisado por el equipo de Blue Canvas··7 min de lectura
Tras cinco años trabajando con Salesforce y Git, hemos aprendido muchísimo sobre ambas tecnologías. Nuestra visión inicial era que, al llevar el protocolo Git a más equipos de Salesforce, podríamos ayudarlos a resolver muchos de los desafíos que habíamos vivido al trabajar con Salesforce. Herramientas como Ant y los conjuntos de cambios son útiles, pero no parecían reflejar toda la magnitud de los cambios en el ecosistema de desarrollo durante la última década.
Según nuestra experiencia Git era la herramienta perfecta para resolver muchas de las frustraciones que teníamos con Salesforce. (Por ejemplo, Git es excelente para gestionar fusiones en bases de código grandes y complejas). En definitiva, un enfoque de desarrollo basado en el código fuente permitiría a los equipos de Salesforce lanzar más rápido, con la confianza de que su código se ha probado, se ha revisado y puede revertirse en el peor de los casos.
Pero lograr que Salesforce funcionara bien con Git no fue nada fácil. Si lo fuera, seguramente más equipos ya lo habrían hecho. Si estás considerando dar el paso y orientar más a tu equipo de Salesforce hacia Git, aquí tienes algunas cosas que aprendimos y que conviene tener en cuenta.
1. Aventuras al reordenar XML en Salesforce
Lo primero que creamos en 2016 fue un conector sencillo que mantenía una rama de Git sincronizada con un entorno de Salesforce, lo que permitía crear una rama de referencia para cada sandbox y entorno de producción de una organización. Este sencillo conector tuvo un éxito sorprendente y conectó con los desarrolladores que hasta entonces hacían copias de seguridad de sus sandboxes de forma manual e improvisada. (Básicamente, si recordabas ejecutar un script de Ant antes de irte el viernes, tenías una copia de todo; de lo contrario, no).
Mientras creábamos este conector de ramas de referencia, notamos que los archivos XML que Salesforce nos devolvía eran un poco, digamos, difíciles de manejar. Notamos un comportamiento extraño al que llamamos «flapping». Ocurría cuando la API de metadatos de Salesforce devolvía resultados inconsistentes. En un momento indicaba que se había eliminado un recordType y, al siguiente, afirmaba que se había vuelto a agregar. Ningún usuario estaba haciendo esos cambios, pero aparecían en las comparaciones en momentos inoportunos.
Cuando lanzamos la capacidad de implementar en Salesforce con CI/CD en 2017, detectamos un problema aún más insidioso: el orden de los objetos en un archivo XML no era consistente entre entornos. A menudo, dos entornos tenían una funcionalidad idéntica para un componente de metadatos determinado, pero Git marcaba una diferencia porque el orden del XML era distinto. Esto generaba comparaciones confusas para los desarrolladores.
Tuvimos que resolver esto personalizando una herramienta de comparación de XML para manejar estos tipos de reordenamiento. Fue complicado, pero ahora podemos identificar correctamente las diferencias desde la perspectiva del usuario final o del administrador, incluso si la estructura XML subyacente no es la misma.
2. Fusiones en un mundo centrado en organizaciones
Posiblemente, el desafío más difícil de usar Git y Salesforce fue resolver los conflictos de fusión. En un entorno de desarrollo típico, todos los cambios se basan en el código fuente y se realizan con ramas de funcionalidades. Pero al observar a los administradores de Salesforce (y a muchos desarrolladores), notamos que, a pesar de sus esfuerzos por trabajar con un enfoque basado en el código fuente solían tratar su sandbox como un IDE: preferían hacer cambios en un objeto directamente en la organización en lugar de usar algo como VS Code. (¿Y quién puede culparlos? ¡Este es precisamente el valor de una clics, no código plataforma de desarrollo como Salesforce!)
Sin embargo, esta realidad hacía que las organizaciones con frecuencia no estuvieran sincronizadas con el repositorio de Git. Por eso, el algoritmo tradicional de fusión de Git nos daba muchos falsos positivos y falsos negativos. (Algún día publicaremos un artículo completo sobre cómo lo resolvimos).
No queríamos obligar a los administradores a trabajar de una manera incómoda, pero sí queríamos aprovechar Git para reducir la cantidad de conflictos. Después de muchas iteraciones, encontramos una solución elegante: usar bloques de cambios de Git.
Al establecer dos ramas de referencia que se mantenían continuamente sincronizadas con cada entorno, podíamos garantizar que siempre tuviéramos ramas precisas para comparar. Así, podíamos permitir que los usuarios compararan y seleccionaran los archivos que querían incluir en su rama de implementación. Luego agregamos la capacidad de seleccionar los «bloques de cambios de Git» presentes en cada comparación. Esto permitía a los usuarios seleccionar cambios dentro de un archivo sin sobrescribir otras partes que quizá aún no hubieran fusionado en su propia rama. Ahora un desarrollador podía fusionar la actualización de un método en una clase de Apex sin preocuparse por sobrescribir otros cambios en esa misma clase.
Esta solución simple y elegante permitió a nuestros usuarios eliminar los conflictos de fusión en archivos importantes sin añadir mucha carga operativa ni capacitación sobre las ramas de Git.
3. Un formato racional para XML marca una gran diferencia
Antes de Salesforce DX, todos los objetos personalizados y sus traducciones se almacenaban en un único archivo XML desordenado. Esto hacía que la fusión fuera casi imposible y generaba una gran frustración para todos los desarrolladores que usaban la herramienta de implementación de Ant. Actualizar un solo campo o tipo de registro exigía mucho cuidado y atención al detalle; de lo contrario, podía provocar eliminaciones inesperadas dentro de un objeto.
Con DX, los objetos y sus traducciones ahora tienen una nueva estructura de código fuente que divide estos objetos grandes en partes más pequeñas, llamada Formato de código fuente de Salesforce DX. Cada objeto y su traducción ahora tienen subdirectorios organizados de forma más lógica. Cada campo se encuentra en un subdirectorio `fields/`. Los RecordTypes se encuentran en `recordTypes/`, y así sucesivamente.
Convertir a este formato requiere cierto esfuerzo, especialmente en organizaciones antiguas. ¡Pero creemos que vale la pena! El nuevo formato simplifica mucho las fusiones y permite que tu equipo trabaje en distintas partes del mismo objeto sin sobrescribir el trabajo de los demás. Git también puede ayudar a gestionar conflictos, pero si no usas el formato de directorios más moderno, solo aprovechas una fracción de su eficacia. Convertimos automáticamente a todos nuestros clientes al formato de código fuente de Salesforce DX y recomendamos que todos los equipos de Salesforce hagan lo mismo. Los beneficios a largo plazo son enormes.
4. Las comparaciones en Git son realmente muy rápidas
Comparar entornos en Salesforce es complicado. Usar scripts de Ant o la API de metadatos puede ser bastante lento y difícil, según cómo esté funcionando Salesforce en ese momento. Para algunos equipos, comparar dos entornos suele tardar 5-10 minutos (y a veces hasta 20 o 30 cuando Salesforce está sobrecargado). Nos sorprendió gratamente descubrir que una de las grandes fortalezas de Git es comparar diferencias de forma rápida y eficiente, incluso cuando son enormes.
En Blue Canvas administramos más de 100 millones de líneas de código y metadatos de Salesforce, y observamos que una comparación promedio se puede realizar en unos 10 segundos. Ten en cuenta que son comparaciones de organizaciones completas, no de selecciones específicas. Pasarte a Git aumentará considerablemente la velocidad de tu equipo de desarrollo. Ahorrar 5-10 minutos cada vez que quieras fusionar algo puede ahorrar horas por semana a cada uno de tus administradores y desarrolladores.
5. Solicitudes de incorporación de cambios y cultura de equipo
Git es, ante todo, una herramienta de colaboración. Está diseñado para que distintos desarrolladores puedan fusionar su código de forma segura en una base de código compartida. Una de las prácticas más populares en Git es la «solicitud de incorporación de cambios», con énfasis en «solicitud». Cuando empezamos a usar Git, pensábamos en todas las formas en que podía ayudarnos como desarrolladores individuales. Sin embargo, descubrimos el enorme efecto que tenía en la cultura del equipo.
Al implementar con conjuntos de cambios o scripts de Ant, puedes ver qué archivos se están implementando y poco más. Quizás revises un poco el package.xml para obtener más contexto. Pero Git ofrece una experiencia mucho más completa para el trabajo en equipo. Con las solicitudes de incorporación de cambios puedes ver diferencias y comentar directamente sobre el código. Esta visibilidad anima a más personas a comentar, lo que crea un ciclo de retroalimentación en el que todo el equipo comenta y comparte sus conocimientos como parte del proceso de lanzamiento.
Observamos que los equipos que usan revisiones de código con Salesforce suelen ver una disminución importante de los problemas en producción, en gran medida porque más personas revisan cada lanzamiento. También observamos que las revisiones y aprobaciones de código hacen que los equipos sean menos propensos a los silos de información y a una dependencia peligrosa de personas clave.
¿Es Git demasiado para un equipo de Salesforce?
A menudo nos preguntan: «¿Es Git demasiado para la mayoría de los equipos de Salesforce? ¿Realmente necesito invertir y capacitar a mis administradores y analistas de negocio de Salesforce para usar la línea de comandos y el protocolo Git?». Sin duda, es una inversión. Pero no tiene por qué ser abrumadora. Hay herramientas que te permiten interactuar con Git mediante interfaces gráficas en lugar de la línea de comandos (por ejemplo, SourceTree, GitHub Desktop, Blue Canvas).
Git te permite avanzar más rápido sin romper nada. Las comparaciones rápidas, la capacidad de revertir cambios y las revisiones de código permiten que los equipos avancen más rápido que nunca y confíen en que cumplirán los plazos acordados con las partes interesadas del negocio.
Esperamos que cada vez más equipos reconozcan esta realidad a medida que Salesforce se consolide como una plataforma central para el desarrollo de bajo código. Será necesario invertir en herramientas de desarrollo a medida que más equipos creen soluciones extraordinarias con Salesforce.
