Ramas por funcionalidad en Salesforce

La creación de ramas por funcionalidad es un concepto que se usa en la mayoría de los entornos de desarrollo de software. Si trabajas con .Net, Java, Python, Go, Node.js o Ruby, probablemente ya lo conoces. En lugar de modificar directamente la base de código, puedes crear una rama a partir de la principal y trabajar en una funcionalidad específica de forma aislada. Esto permite que varias personas trabajen de forma segura y en paralelo sobre la misma base de código. Atlassian lo recomienda en su guía de flujo de trabajo de Git para Salesforce.

Espera, ¿no es para eso que sirven los sandboxes?

Salesforce promueve un concepto similar, pero distinto, con su oferta de sandboxes: en lugar de hacer cambios en producción, hazlos primero en un sandbox. Luego, integra los cambios de código en producción solo cuando estén listos. Es un gran concepto, pero no resuelve exactamente los mismos problemas que el uso de ramas por funcionalidad.

Los despliegues más rápidos y sencillos son la clave para trabajar con ramas por funcionalidad en Salesforce.

Primero, los sandboxes suelen ser entornos de preproducción, en lugar de unidades de trabajo aisladas. En un sandbox puede haber decenas de funcionalidades en desarrollo al mismo tiempo. Y puede haber varios desarrolladores modificando la misma base de código, lo que provoca sobrescritura de código y los problemas que esto genera. Hemos visto sandboxes que no se han sincronizado con producción en más de un año. Por eso, es probable que las dependencias entre el sandbox y producción estén desincronizadas, lo que dificulta la fusión.

El uso de ramas por funcionalidad lleva el concepto de sandbox a otro nivel. En este artículo del blog, analizaremos con más detalle por qué tu equipo debería usar activamente ramas por funcionalidad en Salesforce y cómo hacerlo.

¿Qué es el uso de ramas por funcionalidad?

Quizás estés pensando: “Solo soy desarrollador o administrador de Salesforce. No tengo tiempo para todos estos procesos complicados de Git. ¿Qué gano con esto?”.

La idea de desarrollar cada funcionalidad en ramas aisladas, en lugar de hacerlo en la rama master, ofrece numerosos beneficios para los desarrolladores y administradores de Salesforce:

1. Los desarrolladores pueden experimentar con funcionalidades sin alterar la base de código principal.
2. Las distintas funcionalidades pueden tratarse como unidades de trabajo independientes y lanzarse según su propio calendario.
3. Tu rama principal nunca contiene código defectuoso y siempre está lista para desplegarse, lo que te permite publicar con mayor frecuencia. Esto satisface más a los usuarios finales que los cambios grandes y radicales.

Además, hace que las implementaciones sean mucho más rápidas. Tu rama de desarrollo nunca difiere demasiado de la rama principal porque trabajas en unidades pequeñas e independientes, lo que simplifica mucho la fusión. Imagina un sandbox recién creado. Haces algunos cambios en él y luego implementas un conjunto de cambios esa misma tarde. Es probable que todo salga bien porque no hubo tiempo suficiente para que se acumularan diferencias de dependencias entre tu sandbox y producción. El uso de ramas por funcionalidad permite aplicar el mismo concepto.

El uso de ramas por funcionalidad también hace posible el concepto de solicitudes de incorporación de cambios o solicitudes de implementación. Esto fomenta revisiones de código para Salesforce y el intercambio de ideas sobre cambios específicos antes de realizar implementaciones.

Si usas ramas por funcionalidad, podrás:

1. Implementa más rápido y con más frecuencia
2. Implementa con menos problemas
3. Introduce menos errores
4. Evita la sobrescritura de código
5. Tener pequeñas unidades de trabajo que puedes revertir fácilmente

Esto resulta útil para todos los integrantes de un equipo de desarrollo de Salesforce que ya tienen una carga de trabajo excesiva.

Cómo trabajar con ramas por funcionalidad

Para usar ramas por funcionalidad con Git, necesitas conocer algunos comandos. Debes comenzar con la rama principal, normalmente master:

git checkout master
git fetch origin
git reset --hard origin/master

Esto te lleva a la rama master y descarga los cambios de master que se encuentran en el repositorio remoto origin.

Puedes crear una nueva rama para tu funcionalidad:

git checkout -b my-feature

Este comando crea la rama de funcionalidad llamada my-feature y te cambia a ella al mismo tiempo. En este punto, la rama recién creada debería ser exactamente igual a master. Ahora puedes hacer cambios y confirmarlos en la rama de la funcionalidad de esta manera:

git status
git add .
git commit -m “my commit message”

Ahora el cambio está confirmado en la rama de la funcionalidad. Podemos hacer una de dos cosas: fusionarlo directamente con master o crear una solicitud de incorporación de cambios. Crear una solicitud de incorporación de cambios es una buena idea porque permite que tus colegas revisen el código antes de fusionarlo con master y luego pasarlo a producción:

git push -u origin my-feature

origin es el nombre de tu repositorio remoto de Git. my-feature es el nombre que quieres darle a la rama que vas a crear en ese repositorio remoto. En general, conviene usar exactamente el mismo nombre que usaste localmente para evitar confusiones.

Luego, si usas Bitbucket, GitHub o Gitlab puedes usar su función de solicitudes de incorporación de cambios y abrir una nueva solicitud. Estas plataformas tienen herramientas para revisar y fusionar código desde sus interfaces de usuario.

Qué dificulta el uso de ramas por funcionalidad en Salesforce

Históricamente, usar ramas por funcionalidad ha sido difícil en Salesforce. Para empezar, muy pocos equipos usan Git. Además, trabajar con ramas por funcionalidad requiere ciertos conocimientos de Git y familiaridad con la línea de comandos. Puede que esto no sea un problema para los desarrolladores de Salesforce, pero cuando un proyecto incluye consultores, administradores, gerentes de producto, gerentes de proyecto, analistas de negocio y otros participantes, es difícil esperar que todos dominen Git desde la línea de comandos.

La mayoría de los equipos usan los sandboxes como una especie de rama parcial por funcionalidad. Sin embargo, los sandboxes tardan en crearse y son engorrosos de manejar.

Implementar con conjuntos de cambios o Los scripts de Ant son difíciles de manejar. Esto hace que fusionar una rama de funcionalidad con la rama principal sea tedioso. Nadie quiere hacerlo con demasiada frecuencia, así que los equipos terminan conformándose con cambios y lanzamientos monolíticos que abarcan semanas o meses. Además, no es raro que tu código en Git y tu código en producción reflejen realidades distintas. Muchas veces, algo que se envía a Git no se puede implementar en producción debido a problemas de dependencias.

Como los equipos tienen varios usuarios que desarrollan y configuran en un mismo sandbox, los conflictos de fusión surgen con frecuencia y no son fáciles de resolver.

Las nuevas tecnologías lo hacen más fácil

Blue Canvas simplifica mucho el uso de ramas por funcionalidad para los desarrolladores de Salesforce. Con cuatro clics, puedes vincular una rama de Git a una organización sin tocar la línea de comandos. Todos los cambios de esa rama se registran automáticamente en Git. Puedes crear solicitudes de incorporación de cambios desde la interfaz de Blue Canvas, que permite revisar el código y fusionarlo si se aprueba la revisión.

Blue Canvas no solo te ayuda a crear ramas, también te ayuda con las implementaciones. Y las implementaciones más rápidas y sencillas son la clave para trabajar con ramas por funcionalidad en Salesforce. Si puedes implementar componentes específicos rápidamente, tiene más sentido tratar cada nueva funcionalidad como una rama independiente. Incluso acabamos de lanzar la eliminación de ramas para que puedas cerrar una rama cuando termines.

Salesforce DX y organizaciones temporales

Salesforce DX hace aún más viable el uso de ramas por funcionalidad en Salesforce. DX introduce el concepto de organizaciones temporales. Las organizaciones temporales son sandboxes que se pueden crear en minutos, en lugar de horas o días. Solo duran alrededor de una semana, por lo que son ideales para trabajar con ramas por funcionalidad.

Blue Canvas está desarrollando nueva tecnología para que crear ramas por funcionalidad con organizaciones temporales sea más fácil y accesible, sin usar la línea de comandos. Con Blue Canvas puedes crear una organización temporal desde la interfaz de usuario y vincularla automáticamente a una rama.

Si quieres probar la creación de ramas por funcionalidad con Salesforce DX y Blue Canvas, escribe a team@bluecanvas.io para configurar una prueba.

‍