Por qué Salesforce DX y Git Flow no funcionan para los equipos de Salesforce

Hoy en día, probablemente haya muy pocos equipos de desarrollo de software en tu organización que no utilicen eficazmente algún tipo de control de versiones, y es probable que la mayoría use Git de alguna manera.

Bueno, todos excepto uno: tu equipo de desarrollo y administración de Salesforce. Puede que tu equipo de Salesforce tenga un repositorio Git en algún lugar, pero lo más probable es que no esté aprovechando todos los beneficios del control de versiones. En definitiva, esto significa que tus equipos de Salesforce no están tan protegidos como tus otros equipos de desarrollo frente a problemas como los errores (y la necesidad de revertir los cambios que los causan), y no están trabajando con toda la eficacia que podrían.

HEMOS TRABAJADO CON GRANDES ORGANIZACIONES DE Salesforce QUE SE PASARON A Blue Canvas PORQUE DEDICABAN DEMASIADAS HORAS A MANTENER SU IMPLEMENTACIÓN DE JENKINS PARA Salesforce, CON UN COSTO DE CIENTOS DE MILES DE DÓLARES AL AÑO EN SALARIOS.

Este documento técnico explica por qué Git Flow con Jenkins (la forma tradicional en que los equipos de software usan Git) y Salesforce DX (el enfoque de Salesforce para resolver su problema de experiencia del desarrollador) no funcionan bien para los equipos de Salesforce. También explica cómo puedes obtener los beneficios de las herramientas modernas de DevOps y de Git mediante herramientas como Blue Canvas.

Salesforce DX y Git Flow para Salesforce

Salesforce tuvo el deshonor de ser llamada la peor plataforma para desarrolladores en 2013 y 2015 (la 2.ª peor en 2014). En 2016, la empresa anunció “Salesforce DX”, siglas de Developer Experience, o experiencia del desarrollador. La idea era incorporar herramientas modernas de DevOps a la plataforma Salesforce para modernizar la forma en que los equipos de Salesforce desarrollaban software.

ASÍ COMO GitHub OFRECE UNA INTERFAZ INTUITIVA PARA Git, Blue Canvas TIENE LA SIMPLE MISIÓN DE PONER SALESFORCE DX Y DEVOPS AL ALCANCE DE LOS EQUIPOS DE Salesforce.

El mensaje parecía acertado en todos los sentidos. Promovía el “desarrollo basado en el código fuente” y animaba a los equipos a considerar el control de versiones como la fuente de verdad*, en lugar de la propia organización de Salesforce.

Prometía nuevos tipos de organizaciones llamadas organizaciones temporales, que serían entornos ligeros que podrían crearse rápidamente, casi como entornos virtuales o máquinas virtuales.

Y ofrecía una nueva CLI de Salesforce que pretendía ser una versión moderna de la herramienta de migración Ant basada en Java que venían usando los equipos de desarrollo de Salesforce más avanzados.

Somos grandes admiradores de lo que hace el equipo de DX y de lo que intenta cambiar en el desarrollo de Salesforce. Es un gran esfuerzo y muchos de sus principios fundamentales tienen sentido. De hecho, en Blue Canvas aprovechamos Salesforce DX de varias maneras, ¡especialmente su excelente nuevo formato de directorio!

Sin embargo, después de dos años de trabajar con equipos de Salesforce que intentan implementar DX, creemos que, aunque tiene buenas intenciones, no da en el blanco en algunos aspectos fundamentales, así como el enfoque de Git Flow y Jenkins ha resultado difícil de usar para los equipos.

Por qué Salesforce DX y Jenkins presentan desafíos

La razón principal es que Salesforce DX se basa en Git Flow, que es la forma básica en que los equipos de software usan Git.

La mayoría de los equipos de software usa Git Flow para llevar un registro de varias ramas en paralelo y utiliza Git desde la línea de comandos para mantenerlas y fusionarlas. En una pila de software tradicional con Go, Ruby, Python o Node.js, las implementaciones en producción se administran fácilmente con Git porque nunca editas el código de producción directamente en el servidor.

Sin embargo, Salesforce, por diseño, fomenta que las personas editen directamente en el “servidor”. (Explicaremos por qué esto es, en realidad, una ventaja de Salesforce. En definitiva, también es la razón por la que necesitas adaptar ligeramente Git para trabajar con equipos de Salesforce).

Salesforce DX parte de la idea del desarrollo basado en el código fuente. Esto es excelente. Sin embargo, los detalles de la implementación no han terminado de funcionar. El problema es que, por mucho que digas que el control de versiones es la fuente de verdad definitiva, si las personas pueden hacer cambios directamente en la organización, es esta la que termina reflejando lo que realmente sucede.

Por supuesto, todo esto es así por diseño. Salesforce es excelente porque muchas personas pueden hacer cambios. Es el CRM empresarial número uno porque no necesitas un título en ciencias de la computación para crear aplicaciones de software increíbles. Trabajamos todos los días con equipos que crean sistemas sólidos y prácticos que, en muchos casos, seguirán funcionando durante 10 años o más. Eso es impresionante.

EN DEFINITIVA, CONTAMOS CON DEVOPS Y CONTROL DE VERSIONES PARA QUE LOS EQUIPOS PUEDAN PUBLICAR CÓDIGO DE MAYOR CALIDAD MÁS RÁPIDO.

Y Salesforce no recibe suficiente reconocimiento como plataforma por su capacidad de admitir ese tipo de desarrollo. Hay una razón por la que no quieres crear tu propio CRM desde cero con Node.js, React, Go y PostgreSQL. Quieres contar con un sistema que los usuarios de negocio puedan administrar, que simplemente funcione y que esté disponible todo el tiempo.

Por eso, puede ser difícil garantizar que lo que está en el control de versiones refleje con precisión lo que sucede en la organización. Esta es la realidad y la hemos visto una y otra vez. Esto seguirá siendo así mientras haya cambios que se puedan hacer fácilmente de forma directa en la organización (por ejemplo, agregar un campo siempre es más fácil desde la interfaz de configuración de Salesforce, y la mayoría de los equipos trabaja así).

El objetivo de Salesforce DX

Hay otro factor que impide que un repositorio Git independiente sea una buena opción como fuente de verdad en Salesforce: no encaja con el modelo mental que la mayoría de los equipos de Salesforce usa hoy.

En lugar de facilitar el trabajo en la interfaz de Salesforce, donde los equipos pueden trabajar de forma rápida, eficiente y segura, DX los anima a aprender a usar Git: una herramienta de línea de comandos conocida por ser confusa, que incluso a los mejores desarrolladores les cuesta usar.

También introduce un nuevo tipo de organización: la organización temporal. Al principio nos entusiasmó mucho, pero las organizaciones temporales tienen una funcionalidad demasiado limitada y no funcionan bien con los sandboxes de copia completa y las organizaciones tradicionales. Incluso requieren un nuevo formato de directorio que las hace incompatibles con los sandboxes, por lo que los equipos no pueden hacer una transición fluida, especialmente si tienen años de código y metadatos heredados.

Parece demasiado pedirles a los desarrolladores y administradores de Salesforce que abandonen sus formas tradicionales de trabajar para adoptar un flujo confuso basado en la línea de comandos.

El costo de mantener un pipeline de DevOps para Salesforce

A pesar de estas limitaciones, muchos equipos han insistido en crear pipelines de CI y DevOps para Salesforce, con resultados variados. Sin duda, es posible crear algo parecido a un pipeline de CI para Salesforce usando Jenkins, Git y la herramienta de migración Ant, o incluso Salesforce DX.

El problema es que, incluso cuando logras que funcione más o menos, los costos de mantenimiento son bastante altos en relación con los beneficios que obtienes.

Tan solo crear el pipeline requiere una inversión considerable de tiempo y recursos. Según entrevistas con nuestros clientes y con uno de nuestros desarrolladores que creó una herramienta interna de DevOps para Salesforce, estimamos que se necesitan al menos 3-6 meses para construir el pipeline completo. Esto desvía recursos valiosos de Salesforce que podrían estar generando valor para los clientes.

Además, mantener un sistema así requiere una persona dedicada a DevOps a tiempo completo para darle mantenimiento y depurarlo. Hemos trabajado con grandes organizaciones de Salesforce que se pasaron a Blue Canvas porque tenían que dedicar demasiadas horas a mantener su implementación de Jenkins para Salesforce, con costos salariales de cientos de miles de dólares al año. Impresionante.

Y, para completar el panorama, está el enorme costo de capacitar a tu equipo para usar un proceso nuevo. Cuando las herramientas son difíciles de usar y no se adaptan al flujo de trabajo de tu equipo, se convierten en un costoso colador lleno de fugas. Inviertes dinero en el sistema, pero hay agujeros por todas partes y muchas de las ventajas que esperabas obtener con tu inversión se pierden en el proceso.

Esto quizá sea lo más doloroso que hemos escuchado de los equipos. Es difícil ver algo en lo que inviertes tiempo y dinero y que realmente tiene sentido como una buena inversión, pero que luego se vea saboteada por la falta de adaptación al flujo de trabajo y de adopción.

Nuestros clientes que antes tenían pipelines de CI con Jenkins o Bitbucket nos cuentan lo frustrante que fue invertir en un sistema así, solo para que fallara cuando más lo necesitaban.

Por qué contamos con control de versiones y herramientas de DevOps

En definitiva, usamos DevOps y control de versiones para que los equipos puedan lanzar código de mayor calidad más rápido. Un buen flujo basado en Git y una estrategia de gestión de versiones sirven para:

• Mejorar la calidad con prácticas como las revisiones de código
• Reducir errores con pruebas automatizadas
• Automatizar pasos manuales para evitar equivocaciones y errores humanos
• Permitir que tu equipo avance más rápido y mejore el software de una manera más ágil
• Contar con versiones e historial para poder revertir errores

Los problemas de usabilidad de Git Flow, Jenkins y Salesforce DX hacen que sea demasiado difícil obtener estos beneficios.

Blue Canvas adapta Git Flow de una forma que tiene sentido para los desarrolladores de Salesforce

La razón por la que SFDX no funciona es que intenta incorporar lo que funciona en otros entornos y plataformas, sin comprender las diferencias fundamentales entre Salesforce y otras plataformas.

Blue Canvas resuelve el problema fundamental de la fuente de verdad al sincronizar automáticamente el repositorio de Git con lo que hay en la organización. Cada vez que un desarrollador o administrador hace clic en “guardar”, registramos automáticamente ese cambio en Git en nombre del usuario. Esto significa que todo lo que está en el control de versiones refleja con precisión lo que hay en la organización.

También permitimos que los desarrolladores y administradores creen “pull requests” sencillos en la interfaz de Blue Canvas, con funciones similares a las de los conjuntos de cambios. Vinculamos el despliegue o conjunto de cambios con Git para mantener la continuidad entre la fuente de verdad y el estado del despliegue. Funciona de forma muy similar a un despliegue de Heroku.

Esto también resuelve el problema de usabilidad. En lugar de pedirles a los administradores y desarrolladores que aprendan un nuevo proceso con Git, podemos adaptarnos a la estrategia de desarrollo existente basada en sandboxes que los equipos quieran usar.

Al resolver estos dos problemas, hacemos posible aprovechar las ventajas de adoptar herramientas modernas de DevOps para Salesforce. Existimos para facilitarles la vida a los desarrolladores de Salesforce. Creemos que innovar requiere cambios fundamentales en las tecnologías que sustentan el proceso de gestión de versiones.

Al aprovechar internamente las mejores prácticas y herramientas de DevOps, como Git, podemos volver a estados anteriores y crear una excelente experiencia de desarrollo sin exigir que los desarrolladores aprendan a usar un conjunto de herramientas completamente nuevo. También aprovechamos el propio Salesforce DX para que tu equipo no tenga que hacerlo.

En definitiva, las buenas herramientas se basan en un diseño sencillo y elegante. Lograr este tipo de diseño ha requerido el trabajo de algunas de las mentes más brillantes de la industria de herramientas para desarrolladores.

Así como GitHub ofrece una interfaz intuitiva sobre Git, Blue Canvas tiene la sencilla misión de poner los objetivos de Salesforce DX y DevOps al alcance de los equipos de Salesforce de una manera que realmente funcione para sus desarrolladores y les dé acceso a las mejores herramientas del mundo.

‍