El control de versiones y el flujo de trabajo de desarrollo de Salesforce de Atlassian

En este artículo, profundizaremos en las ideas que Melanie Wright y Sheldon Callahan, de Atlassian, compartieron durante su charla en Dreamforce sobre estrategias eficaces de desarrollo en Salesforce. Exploraremos sus principios de desarrollo, la importancia del control de versiones, la estrategia de entornos sandbox y cómo gestionar los desafíos de la colaboración en código. Al terminar, entenderás cómo optimizar tu flujo de trabajo de desarrollo, reducir las sobrescrituras accidentales de código y fomentar una mejor colaboración en tu equipo.

Estas son nuestras 5 conclusiones clave:

• Adoptar un enfoque de 'una funcionalidad a la vez' minimiza la confusión y los conflictos de fusión al llevar un seguimiento eficaz de los cambios.
• Animar a los desarrolladores a trabajar en sus propios entornos sandbox evita interferencias y fomenta un proceso de desarrollo más eficiente.
• Automatizar tantos procesos como sea posible puede aumentar la productividad al reducir las tareas manuales.
• Utilizar una práctica de desarrollo basada en la nube, con herramientas como Cloud9 IDE y Bitbucket Pipelines, puede simplificar la configuración y el mantenimiento de tu flujo de trabajo.
• Implementar un proceso sistemático de revisión de código y pruebas automatizadas puede mejorar la calidad del código e identificar posibles conflictos de forma temprana.

Dreamforce es uno de los mejores lugares para aprender de otros cómo desarrollan en Salesforce. Este año hubo cientos de sesiones para desarrolladores que cubrieron diversos temas, como entrega continua, control de versiones, Salesforce DX, pruebas automatizadas, Lightning y más.

Una de las mejores charlas de todo Dreamforce estuvo a cargo de Melanie Wright y Sheldon Callahan, de Atlassian titulada: Desarrollo en la nube: mejores prácticas para colaborar en Salesforce.

Los tres principios del desarrollo en Salesforce en Atlassian: una funcionalidad a la vez, aislar el trabajo y automatizar todo.

Atlassian es reconocida por su Flujo de trabajo de desarrollo en Salesforce así como por sus productos que facilitan la colaboración. En esta charla, Sheldon y Melanie explicaron su flujo de trabajo en detalle y destacaron excelentes herramientas en la nube que lo facilitan.

Como hay miles de sesiones de Dreamforce para ver, pensamos en ofrecerte un breve resumen de la charla para que conozcas rápidamente los puntos principales. El video está disponible aquí y vale la pena verlo completo.

Desafíos de la colaboración en código

Sheldon reconoce un gran desafío desde el principio: desarrollar en Salesforce de forma colaborativa puede ser muy difícil. Los desarrolladores y administradores deben esforzarse para mantenerse alineados gran parte del tiempo. «Yo hacía un cambio que se reflejaba en la organización [de mi colega] y nuestros cambios se sobrescribían entre sí», dijo Sheldon. La forma en que funcionan hoy los despliegues de Salesforce hace que la sobrescritura de código sea un problema real. El flujo de trabajo de Atlassian (y Blue Canvas) busca evitarlo.

El otro gran desafío que describe Sheldon ocurre cuando un administrador hace cambios en producción o, en general, desde la interfaz de usuario. Cuando los cambios se realizan desde la interfaz, puede resultar difícil para los desarrolladores ver qué cambió. En la gran mayoría de las instancias de Salesforce, estos cambios nunca se registran en el control de versiones, por lo que los desarrolladores no pueden acceder a ellos. Gestionar los conflictos de fusión se vuelve una pesadilla.

3 principios del desarrollo en Salesforce

Para abordar estos desafíos, Atlassian implementó 3 principios de desarrollo en Salesforce:

1. UNA FUNCIONALIDAD A LA VEZ

Melanie llama a esto «desarrollo orientado a funcionalidades». Cuando varios desarrolladores (y administradores) trabajan en el mismo sandbox en distintas funcionalidades, todo se vuelve confuso. Es difícil saber quién cambió qué y por qué. Al trabajar en una sola funcionalidad a la vez, es más fácil dar seguimiento a lo que ocurre y evitar conflictos de fusión complicados.

2. AÍSLA TU TRABAJO

Cada desarrollador debe trabajar en su propio sandbox. Esto garantiza que nadie interfiera con el trabajo de otros al desarrollar nuevas funcionalidades.

3. AUTOMATIZA TODO

Atlassian intenta automatizar todo lo posible. Por supuesto, no es fácil crear un proceso totalmente autónomo, pero el objetivo es avanzar tanto como puedan para reducir las tareas manuales. Automatizan los cambios de metadatos y configuración. Incluso automatizan tareas como cargar valores en listas de selección para que el equipo mantenga el ritmo y se concentre por completo en programar.

Colaboración en la nube con control de versiones

Melanie y Sheldon señalan que Salesforce se centra en la nube. Por eso, tiene sentido que tu práctica de desarrollo también se base en la nube. Aprovechan herramientas como Cloud9 IDE –un editor de código en la nube– y Bitbucket Pipelines –una extensión de integración continua en la nube para Bitbucket (que también es un sistema de control de versiones en la nube). Este enfoque completamente en la nube facilita la configuración y el mantenimiento de un buen flujo de trabajo, y solo es necesario configurarlo una vez.

Estrategia de sandbox

Uno de los problemas fundamentales que escuchamos una y otra vez sobre la colaboración en código de Salesforce es que, si alguien trabaja en el mismo sandbox que tú, puede sobrescribir fácilmente tus cambios. Esto se conoce como «sobrescritura de código».

Para resolver este problema, Atlassian recomienda configurar tus organizaciones de forma estratégica: además de tu organización de producción (que siempre debe mantenerse lo más libre de errores y lo mejor probada posible), recomiendan un entorno UAT o de preproducción que refleje fielmente lo que sucede en producción. Atlassian usa un «sandbox de copia completa» para su entorno UAT. En el entorno UAT se realizan las pruebas finales antes de pasar a producción.

Los desarrolladores crean sus propias ramas de funcionalidad a partir del repositorio de desarrollo y trabajan en una funcionalidad. Usan su propio sandbox para implementarla y probarla, y así asegurarse de que funcione como se espera. Cuando están satisfechos con su código, pueden fusionarlo en la rama master del repositorio de desarrollo.

También tienen una organización principal de desarrollo que, a su vez, es una copia de su entorno UAT. Aquí fusionan el código de distintos desarrolladores y se aseguran de que todo funcione bien antes de enviarlo a UAT para las pruebas finales. También es donde suelen realizarse los cambios declarativos cuando son globales.

Por último, cada desarrollador también debe tener su propio sandbox personal, que es una copia de la organización principal de desarrollo. Este sirve para experimentar y desarrollar funcionalidades específicas.

Git y Bitbucket

Como era de esperar, Atlassian usa Bitbucket para el control de versiones. Recomiendan usar Git porque permite revertir los cambios fácilmente si surgen problemas y que cada persona aísle su trabajo. Aquí es donde «Git realmente brilla».

Cada funcionalidad merece su propia rama. Esto te permite aislar el código y evitar afectar a otros usuarios.

La rama master siempre es estable en el flujo de trabajo de Atlassian. Creas una nueva rama para una nueva funcionalidad y realizas varios commits en esa rama para mostrar el trabajo que has hecho. Cuando estás satisfecho con tus cambios, los fusionas en la rama master.

Atlassian también usa una estrategia de bifurcaciones en Git para reflejar sus distintas organizaciones de Salesforce en diferentes repositorios Git. Hay un repositorio de producción vinculado a la organización de producción. A partir de él, crean una bifurcación como repositorio UAT, vinculado a la organización UAT. Por último, crean una bifurcación del repositorio UAT como repositorio de desarrollo, vinculado a la organización de desarrollo, de esta manera:

Usar Bitbucket permite incorporar dos elementos clave del flujo de trabajo de desarrollo en Salesforce de Atlassian: revisiones de código y solicitudes de incorporación de cambios.

El flujo de trabajo de desarrollo de Salesforce

Configurar tu sandbox y tu estrategia de control de versiones es solo la mitad del trabajo. Necesitas que las personas sigan un flujo de trabajo específico para evitar los problemas de sobrescritura de código y la confusión general.

Los desarrolladores crean sus propias ramas de funcionalidad a partir del repositorio de desarrollo y trabajan en una funcionalidad. Usan su propio sandbox para implementarla y probarla, y así asegurarse de que funcione como se espera. Cuando están satisfechos con su código, pueden fusionarlo en la rama master del repositorio de desarrollo. Esto activa dos procesos importantes: una revisión de código y una serie de pruebas automatizadas.

Otro desarrollador siempre debe revisar el código antes de que se pueda fusionar en la rama UAT para realizar más pruebas. Esto es importante porque garantiza un código de alta calidad y permite que todos los integrantes del equipo sepan qué está pasando con las distintas funcionalidades.

Mientras un desarrollador revisa el código manualmente, este puede probarse de forma automática. Si algo no está bien, las pruebas automatizadas te lo notificarán. Esto es mucho más confiable y rápido que realizar pruebas manuales. Si alguien más ha desplegado algo en la rama de desarrollo que entra en conflicto con tus cambios, se te notificará en esta etapa.

Una vez que se complete la revisión del código y todas las pruebas pasen, puedes fusionar los cambios en la rama UAT. Luego, un script de Ant despliega el código del repositorio UAT en la organización UAT. Aquí se pueden realizar más pruebas. Una vez probado y aprobado, puedes desplegarlo en producción de forma segura.

Colaboración con administradores

Es excelente que todos tus desarrolladores trabajen de forma independiente con este flujo. Pero ¿qué pasa si tu equipo incluye administradores excepcionales?

En el flujo de Atlassian, los administradores pueden hacer cambios directamente en el sandbox principal de desarrollo y activar una compilación manualmente. Los metadatos no se detectan automáticamente, así que el administrador debe agregar todos los cambios a package.xml. En este punto, puede incluir un mensaje de commit. A partir de ahí, el proceso suele ser el mismo. Las pruebas automatizadas pueden ejecutarse al activar la compilación.

Aunque no se mencionó en la charla, aquí es donde Blue Canvas puede ser especialmente útil. Blue Canvas detecta automáticamente los cambios declarativos realizados desde la interfaz de usuario y los registra como commits en Git para que desarrolladores y administradores puedan trabajar de forma más armoniosa. Más sobre el control de versiones para Salesforce.

Más información

La charla aborda muchos otros temas, como la gestión de cambios destructivos, otras estrategias de ramificación y otras herramientas en la nube. También ofrece más detalles sobre las funciones específicas de Bitbucket Pipelines y JIRA funciones que Atlassian usa en su flujo de trabajo de desarrollo. En Blue Canvas nos encanta lo que hace Atlassian y queremos reconocer y agradecer a Sheldon y Melanie por compartir todo esto públicamente.

‍