Los desarrolladores de Salesforce necesitan una solución de control de versiones

Force.com es una potente plataforma de desarrollo. Permite a ingenieros de todo el mundo crear excelentes aplicaciones que ayudan a otros a dar lo mejor de sí en su trabajo. Salesforce los desarrolladores pueden usar herramientas como Visualforce, Lightning y Apex para aprovechar gran parte de las excelentes funciones que ofrece Salesforce, como Chatter, flujos de trabajo, desencadenadores y otras capacidades. Las aplicaciones creadas en la plataforma Salesforce se benefician de su disponibilidad, seguridad y confiabilidad.

Lamentablemente, muchos desarrolladores de Salesforce enfrentan obstáculos para poner su trabajo en manos de los usuarios rápidamente. Peor aún, muchos deben hacer esfuerzos extraordinarios para garantizar que su trabajo sea de la más alta calidad.

Durante las últimas semanas, en Blue Canvas hemos hablado con decenas de personas de la comunidad de desarrolladores de Salesforce sobre los obstáculos y desafíos que enfrentan. Estos son algunos de los problemas más comunes que nos han contado:

UNO: FALLAS DE COMUNICACIÓN

Uno de los problemas más comunes que hemos escuchado es que los equipos tienen dificultades para colaborar en el mismo proyecto. Quizás tú también lo has vivido: Suzy actualiza una clase de Apex mientras Joe trabaja en la misma clase dentro de la misma organización de Salesforce. Todas las pruebas de Suzy pasan, así que sube su código a producción con entusiasmo. Unos minutos después, Joe hace lo mismo y sobrescribe por completo el trabajo de Suzy. O Joe tiene una copia antigua del código fuente del proyecto sin los cambios de Suzy y luego la implementa en el entorno de UAT, donde todos los cambios de Suzy quedan sobrescritos.

La situación puede ser aún peor cuando un administrador de Salesforce hace cambios desde la interfaz web sin registrarlos en Git. Un desarrollador no tiene forma de ver que esos cambios ocurrieron y termina enviando cambios que generan conflictos.

Esto es especialmente importante para los equipos que trabajan de forma remota, y la magnitud del problema aumenta con el tamaño del equipo.

Salesforce ofrece algunas prácticas recomendadas para esto en su Guía del ciclo de vida de desarrollo de Salesforce, pero muchos de los equipos con los que hablamos todavía enfrentan estos problemas.

DOS: FALTA DE UNA FUENTE MAESTRA O ÚNICA DE REFERENCIA

Cuando Joe y Suzy se ven envueltos en este tipo de enredo de código, no hay un registro central que los ayude a salir. Es casi imposible incluso saber quién hizo qué. ¿Qué cambios ocurrieron? ¿Quién los hizo? ¿Y cuándo? Joe y Suzy tienen que averiguar manualmente quién cambió cada cosa.

Algunos equipos usan herramientas como GitHub para revisar las diferencias en el código, pero no pueden ver las diferencias entre el código de sus organizaciones de Salesforce en producción y su repositorio de código fuente. Todas las personas que pueden hacer cambios en la organización deben ser meticulosas al registrarlos en Git. Si tan solo una o dos personas del equipo no registran sus cambios en Git con regularidad, el proceso deja de funcionar. Varias de las personas con las que hablamos nos contaron sobre problemas de este tipo.

La mayoría de las decenas de equipos con los que hablamos todavía dependen de un proceso muy manual para dar seguimiento a los cambios. Como puedes imaginar, esto generaba una frustración considerable para muchos equipos.

Con demasiada frecuencia, hay diferencias importantes entre el repositorio y la organización. No hay forma de ver esas diferencias, lo que dificulta enormemente la depuración.

Esto puede agravarse para los consultores cuando sus clientes hacen cambios desde la interfaz web. Pocos equipos han encontrado flujos de trabajo repetibles que garanticen el seguimiento de estos cambios en el control de versiones.

TRES: REVERSIÓN DE CAMBIOS

Ya sea por un error en producción debido a un conflicto de colaboración como el descrito anteriormente o por alguna otra diferencia entre el código de la organización de Salesforce y el del repositorio de control de versiones, los equipos reportan dificultades para volver a una versión estable de la organización.

Para la mayoría de los equipos, no existe una forma confiable de revertir rápidamente su código y volver a la última versión funcional mientras resuelven los problemas.

Una desarrolladora con la que hablamos nos contó que faltaban 13 horas para una demostración de una versión importante. Algo salió mal y no tenía forma de ver qué cambios problemáticos se habían registrado ni de revertirlos. Luego pasó lo que llamó las “13 horas más estresantes de su vida” intentando comprender qué había fallado y hacer que todo volviera a funcionar.

La dificultad de revertir cambios es que debes deshacer manualmente las implementaciones, desde la más reciente hasta la más antigua, en orden inverso al que se aplicaron originalmente. Como los componentes de metadatos dependen entre sí, es necesario restaurar un componente eliminado antes de poder revertir una clase de Apex. Y mientras existan referencias a componentes recién agregados, estos no se pueden eliminar. Esto se vuelve aún más complejo cuando implementas metadatos junto con ajustes de configuración manuales.

CUATRO: LAS IMPLEMENTACIONES MANUALES SON RIESGOSAS Y LENTAS

Muchos equipos también mencionaron que deben registrar manualmente los cambios realizados antes de una implementación. Cada integrante debe recordar anotar cada cambio que hizo en la organización. Luego deben actualizar su package.xml, sus perfiles, permisos y roles. Como era de esperar, muchos equipos señalaron que era difícil mantener este proceso manual. Las personas cometen errores con relativa frecuencia, y los equipos dedican incontables horas a averiguar qué se omitió en el registro manual de cambios.

Implementar manualmente también es extremadamente lento. Esta presentación del propio Salesforce sobre la automatización de implementaciones para organizaciones de Salesforce indica que una implementación puede tardar 8-12 horas. Demasiados equipos esperan 8-12 horas los viernes por la tarde, después de la demostración del sprint, para descubrir que las cosas no salieron según lo planeado.

Git PUEDE AYUDAR CON LAS IMPLEMENTACIONES EN FORCE.COM

Un control de versiones adecuado para las organizaciones de Salesforce ayudaría con todo esto. Sin embargo, muchos de los equipos con los que hemos hablado se sienten muy cómodos usando Git y preferirían usarlo como su herramienta de control de versiones.

En Blue Canvas, creemos que Git puede aliviar muchos de los desafíos mencionados. Git facilita y simplifica la colaboración. Puedes usar ramas para distintas organizaciones de Salesforce. Git también funciona como un registro central para que puedas ver qué cambió en tu código. Revertir cambios también es sencillo con Git: basta con usar git revert para volver al último commit funcional. Además, Git es ideal para ver diferencias en el código.

Por último, con un flujo de trabajo que implemente los cambios al hacer push, puedes reducir tus implementaciones de horas a minutos.

En nuestra próxima publicación, analizaremos con más detalle cómo Git puede resolver estos problemas.

¡QUEREMOS ESCUCHARTE!

¿Estos son los problemas que enfrentas en tus implementaciones de Salesforce? Queremos escucharte. Escríbenos a team@bluecanvas.io para contarnos qué desafíos enfrentas al implementar. Tenemos otras excelentes ideas para resolver estos desafíos, ¡y pronto publicaremos más sobre ellas!