Qué hacen los mejores equipos de desarrollo y administración de Salesforce

En este artículo, compartimos lo que hemos aprendido al gestionar más de 350 millones de líneas de código de Salesforce y describimos los hábitos y las estrategias de los equipos de desarrollo de Salesforce más eficaces del mundo. Exploramos prácticas clave como aprovechar los sandboxes, enviar cambios con frecuencia a integración, realizar revisiones de código, respaldar metadatos, comprender Salesforce DX y refactorizar y eliminar código de forma periódica. A partir de nuestra experiencia y los patrones que hemos observado, buscamos ofrecer una guía para ayudar a los usuarios de Salesforce a mejorar sus procesos de desarrollo y su eficiencia.

Estas son nuestras 5 conclusiones clave:

1. Uso óptimo de los sandboxes de Salesforce: Asigna un sandbox independiente a cada desarrollador y administrador, y usa sandboxes de integración y UAT para combinar los cambios de manera eficiente.
2. Frecuencia de los commits: Los equipos exitosos envían pequeños grupos de cambios con frecuencia al sandbox de integración, lo que mejora la eficiencia de las revisiones y reduce los conflictos.
3. Importancia de las revisiones de código: Las revisiones periódicas ayudan a evitar interrupciones y errores, fomentan una mejor comprensión del código y garantizan que esté listo para implementarse.
4. Respalda los metadatos de Salesforce: Respaldar los metadatos, preferentemente mediante control de versiones, es un paso fundamental para protegerte contra posibles pérdidas de datos o cambios accidentales.
5. Comprende Salesforce DX: Incluso si no usan Salesforce DX activamente, los mejores equipos comprenden sus funciones y su potencial, lo que los prepara para adaptarse en el futuro.

Después de tres años trabajando para llevar las mejores herramientas de DevOps a Salesforce, hemos aprendido mucho. Actualmente gestionamos más de 350M de líneas de código de Salesforce (¡y seguimos creciendo!) e interactuamos con decenas de clientes y clientes potenciales cada semana.

Ahora contamos con suficientes datos para empezar a identificar patrones en lo que hacen los equipos de desarrollo de Salesforce más eficaces.

Si personalizas Salesforce, aunque sea de forma moderada (modificas Apex o cuentas con al menos 1-2 desarrolladores o administradores de tiempo completo), estás invirtiendo como mínimo cientos de miles de dólares en Salesforce (si no millones). La inversión vale la pena porque Salesforce es fundamental para tu negocio.

Dada esa inversión, aquí tienes algunos de los hábitos que observamos en los equipos de Salesforce de mayor rendimiento en todo el mundo.

Dale un sandbox a cada desarrollador

La mayoría de las empresas no aprovechan todos los sandboxes que tienen disponibles en Salesforce. Si tienes el plan Pro de Salesforce, recibes 10 sandboxes. Si eres cliente Enterprise, recibes 25. ¡Si tienes Unlimited, recibes 100! Son muchos sandboxes, sin importar la versión de la plataforma que uses.

Fuente: Salesforce

Y, sin embargo, seguimos viendo grandes empresas que, aun teniendo fácil acceso a entre 25 y 100 sandboxes, permiten que equipos de 10, 20 o incluso 50 desarrolladores hagan cambios en un solo sandbox.

Esto genera caos innecesariamente.

A una organización de pruebas se le llama sandbox porque está pensada para que «juegues» en ella. Puedes explorar y experimentar. Puedes probar cosas nuevas. Si 50 personas trabajan en el mismo sandbox, experimentar se vuelve peligroso. Tu cambio puede sobrescribir el código de otra persona o introducir un error o una interrupción del servicio. Concentrar a todos en un solo sandbox limita la libertad de acción del desarrollador y ralentiza a toda la organización.

TENER LA CAPACIDAD DE RECUPERAR TUS CAMBIOS DEMUESTRA QUE HAS CONSIDERADO EL VALOR QUE TIENE PARA TU NEGOCIO MANTENER OPERATIVA TU INSTANCIA DE Salesforce Y PERMITE QUE TU EQUIPO AVANCE RÁPIDO SIN CAUSAR PROBLEMAS.

No usar tus sandboxes también hace que las implementaciones sean lentas, porque tienes que rastrear y separar constantemente los cambios que corresponden a cada lanzamiento.

Al fin y al cabo, estás pagando por tus sandboxes, así que conviene aprovecharlos. Los mejores equipos de desarrollo de Salesforce lo entienden y lo hacen. Configuran un sandbox individual para cada desarrollador y administrador del equipo.

Esta es una mejora fácil de lograr. Si pudieras hacer un solo cambio en tu proceso de desarrollo de Salesforce, debería ser este. Usar más sandboxes de desarrollador no tiene ningún costo.

Puedes hacer la transición esta semana.

Usa un sandbox de integración y uno de UAT

Como los mejores equipos siguen un modelo de un sandbox por desarrollador, necesitan una forma eficaz de integrar los cambios en los entornos de las siguientes etapas.

Para hacerlo, suelen aprovechar 2 sandboxes en las siguientes etapas del flujo. Uno se llama Integración y el otro, UAT.

Integración

El sandbox de integración sirve para combinar código. Es un espacio donde los desarrolladores pueden enviar sus cambios con frecuencia para asegurarse de que no haya conflictos ni efectos en cadena entre las distintas dependencias. El sandbox de integración suele ser de copia parcial, aunque también puede ser de copia completa según tus licencias.

Lo ideal es que los desarrolladores (¡y los administradores!) puedan enviar cambios al sandbox de integración con la mayor frecuencia posible (más adelante hablaremos de esto).

UAT

El entorno de pruebas de aceptación del usuario (UAT) suele ser un sandbox de copia parcial o completa, según el tamaño del equipo y el modelo de licencias. Allí, los usuarios de negocio, los gerentes de producto y los evaluadores de calidad pueden verificar que los cambios cumplan con las especificaciones del producto y los requisitos del negocio. Las implementaciones pasan de la organización de integración a UAT con menor frecuencia, quizá una vez por sprint. Los mejores equipos lo hacen a diario o semanalmente, pero la frecuencia varía bastante según el tamaño de la empresa, el sector, el caso de uso de Salesforce, etc.

Mantener esta estructura sencilla ayuda a evitar que lleguen cambios no deseados a producción y permite que tu equipo entregue funcionalidades más rápido que ahora. Una vez que tengas la estructura de sandboxes adecuada, puedes seguir algunas de estas otras mejores prácticas para lograr un rendimiento aún mejor.

Envía cambios a integración con frecuencia

Enviar cambios a integración con frecuencia evita muchos problemas posteriores. Hace que las revisiones de código sean más eficaces, reduce los conflictos y las interferencias no deseadas, agiliza y simplifica las implementaciones, y fomenta que el equipo siga las mejores prácticas ágiles al entregar pequeñas mejoras con frecuencia.

Los cambios del administrador o desarrollador deben pasar al sandbox de integración lo antes posible. Imagina a un administrador que tiene decenas de tickets abiertos para este lanzamiento. Quizá un ticket requiera un cambio en un campo personalizado y una regla de flujo de trabajo, mientras que otro requiera cambios en el diseño de página y un campo nuevo.

En muchos equipos, el administrador simplemente realiza todos sus cambios sin un orden definido. Luego, quizá una vez cada dos semanas, intenta enviar todo lo que ha estado trabajando en una sola implementación o conjunto de cambios. Esto lleva al temido enfoque de las hojas de cálculo y a los pasos manuales propensos a errores para compilar conjuntos de cambios que abarcan grandes volúmenes de trabajo.

LOS MEJORES EQUIPOS REVISAN CADA ASPECTO DE SU SISTEMA. PORQUE LOS METADATOS DECLARATIVOS AFECTAN LA EXPERIENCIA DEL USUARIO TANTO COMO EL CÓDIGO Apex.

Los mejores equipos evitan esto haciendo que el administrador o desarrollador envíe cambios con la mayor frecuencia posible. Idealmente, 2-3 veces al día. En estos equipos, el administrador actualiza el campo y la regla de flujo de trabajo y los envía de inmediato. En cuanto se termina un ticket, los cambios se envían al entorno de integración.

Esto permite probar y revisar pequeños grupos de cambios. Como solo hay unos pocos cambios, es probable que la implementación se complete sin problemas. La revisión de código también es muy rápida porque hay poco que revisar. Así es mucho más probable que el equipo siga el proceso de revisión de código.

Muchos gerentes insisten en las revisiones de código porque saben que son una buena idea. Pero terminan dejándolas de lado porque son engorrosas y difíciles de realizar. Los commits más pequeños son más fáciles de entender y analizar. Si tu conjunto de cambios incluye 100 diferencias, resulta difícil determinar qué dependencias están involucradas y si el código está realmente listo para el lanzamiento o cumple con los estándares.

Por lo general, cuando los equipos hacen este tipo de «revisiones de código» extensas, en realidad no las revisan en absoluto. Simplemente envían los cambios y esperan que todo salga bien.

Revisión de código

Se ha escrito sobre las revisiones de código aquí y aquí y aquí. Sin duda, son una buena idea. Permiten que otra persona revise los cambios. El objetivo más importante que escuchamos de las partes interesadas en Salesforce es evitar interrupciones y errores en su instancia. Ambos resultan extremadamente costosos.

Cuando Salesforce deja de funcionar, los ingresos se detienen, los pedidos no se completan y los camiones se paran. Salesforce es esencial para las operaciones de la mayoría de las organizaciones que lo usan. Y tampoco es barato (como probablemente sabes). Por eso vale la pena dedicar tiempo a comprender los cambios, registrar sus motivos y obtener la aprobación de otra persona.

La revisión de código debe realizarse justo antes de implementar el cambio en el entorno de integración. Si se hace a tiempo, será menos necesario revisar durante las pruebas de aceptación del usuario (UAT), cuando los cambios empiezan a ser bastante grandes.

Usar una herramienta como Bitbucket, GitHub o VSTS (o, porque tenemos nuestra preferencia, Blue Canvas) facilita que las personas vean qué cambios se proponen y dejen comentarios sobre ellos.

Aunque la llamamos revisión de «código», en Salesforce debería ser una revisión de «cambios». Debe incluir los cambios declarativos de metadatos, como los realizados en objetos y campos, no solo el código Apex. Los equipos mediocres tienen revisiones de código para Apex. Los mejores equipos revisan cada aspecto de su sistema, porque los metadatos declarativos afectan la experiencia del usuario tanto como el código Apex.
Pregúntale a tu equipo: ¿están revisando los cambios de metadatos en sus revisiones de código?

Estas revisiones de código o de cambios también fomentan la colaboración y la comprensión de tu base de código. Son una estrategia de mitigación de riesgos.

Imagina que alguien de tu equipo es responsable de una funcionalidad clave. Trabajó intensamente en ella y la entregó a lo largo de tres sprints, con noches de desvelo y muchas jornadas largas durante las semanas previas al lanzamiento. Una vez implementada, se toma unas merecidas vacaciones. 2 días después, mientras disfruta de unas piñas coladas en una playa de Bora Bora, se descubre un problema. Al equipo de ventas no le gusta el cambio o este no está dando el resultado esperado. Nadie tiene idea de cómo funciona ni de cuáles componentes de metadatos son importantes y cuáles no. Revertirlo resulta imposible hasta que esa persona regrese en dos semanas.

TENER LA CAPACIDAD DE RECUPERAR TUS CAMBIOS DEMUESTRA QUE HAS CONSIDERADO EL VALOR QUE TIENE PARA TU NEGOCIO MANTENER OPERATIVA TU INSTANCIA DE Salesforce Y PERMITE QUE TU EQUIPO AVANCE RÁPIDO SIN CAUSAR PROBLEMAS.

Si se hubiera hecho una revisión de código, otra persona sería responsable de comprenderlo. Eso significa que tendrías a alguien más en el equipo que podría ayudarte a revertirlo mientras quien lo creó disfruta de sus vacaciones.

Lo mismo aplica si trabajas con consultores. Es bueno que tu equipo comprenda los cambios que hacen los consultores y cómo afectan a todas las partes de tu sistema.

Por último, las revisiones de código ofrecen cierto nivel de implementaciones de Salesforce basadas en permisos. Puedes tener la tranquilidad de que hay un proceso detrás de los cambios en Salesforce y de que solo los revisores de confianza pueden implementarlos.

Respalda tus metadatos de Salesforce

Hablando de reversiones, nos sigue sorprendiendo que, dada la inversión en licencias de Salesforce, productos complementarios, salarios de desarrolladores y administradores de Salesforce, y la importancia de su disponibilidad para los clientes, tan pocos equipos tomen una medida relativamente sencilla y económica: respaldar sus metadatos de Salesforce.

Poder revertir tu código de Salesforce brinda mucha tranquilidad y permite que tu equipo avance con decisión y confianza, en lugar de actuar con miedo.

‍

El control de versiones es la mejor manera de respaldar tus metadatos. Como mínimo, también podrías descargarlos en un archivo zip todos los días.

Conocemos equipos que literalmente le pagan a su administrador para aplicar el método del zip todos los días. Creen que es la forma más rentable de respaldar sus metadatos. No coincidimos con esa lógica en sí (el costo potencial de una interrupción importante y el tiempo invertido superan por mucho el beneficio de hacerlo así), ¡pero reconocemos su mérito por tomar alguna medida!

Los equipos mediocres usan un script de Ant para extraer sus metadatos y registrarlos en Git todos los días. Es un enfoque bastante rudimentario y tiene un alto costo de mantenimiento, pero se acerca a lo que hacen los mejores equipos.

Los mejores equipos usan el control de versiones tal como fue concebido. Salesforce puede complicarlo, pero la inversión vale la pena. Por supuesto, podrías obtener este beneficio con una herramienta como Blue Canvas para respaldar continuamente tus metadatos de Salesforce (y evitar por completo las dificultades y los costos), aunque reconocemos nuevamente nuestra preferencia.

Como mínimo, no podemos dejar de recomendarte que tengas alguna estrategia de respaldo para los metadatos de Salesforce. Salesforce facilita demasiado la realización de cambios no deseados. El sistema es tan complejo que las personas suelen verse tentadas a hacer cambios directamente en producción, o pueden enviar fácilmente un conjunto de cambios que borre el trabajo de otra persona (consulta el desafortunado tuit anterior).

Poder recuperar tus cambios demuestra que has considerado el valor que tiene para el negocio mantener disponible tu instancia de Salesforce y permite que tu equipo avance rápido sin provocar fallas.

Comprende Salesforce DX... aunque no lo uses

Salesforce DX está a la vanguardia de la experiencia de desarrollo para Salesforce. Está disponible desde hace unos 2 años y, aunque no es perfecto, es muy importante comprenderlo.

No te preocupes: hemos encontrado muy pocos equipos que realmente estén usando Salesforce DX hoy. Los que lo hacen suelen trabajar en proyectos nuevos, donde es fácil configurar DX desde el inicio. Estos equipos también suelen contar con desarrolladores altamente capacitados que vienen de otras plataformas, como .NET, y están acostumbrados a trabajar con herramientas como TFS o VSTS.

Las aplicaciones heredadas generalmente no pueden admitir ni usar Salesforce DX de manera efectiva.

Fuente: https://developer.salesforce.com/platform/dx

De hecho, no recomendaríamos siquiera intentar usar Salesforce DX con aplicaciones heredadas. Pasa por alto demasiados aspectos clave de Salesforce. Por ejemplo, propone Desarrollo basado en el código fuente sin embargo, no reconoce que la organización es y siempre será la fuente de verdad. Mientras sea posible editarla directamente, seguirá siéndolo. (De hecho, Blue Canvas existe para resolver precisamente este problema, ¡pero eso es tema para otro artículo!)

Aun así, comprender Salesforce DX permite a los equipos ver hacia dónde se dirige Salesforce: a tratarlo como una verdadera plataforma de desarrollo, al igual que .NET, Java o Node.js.

Los mejores equipos siguen de cerca Salesforce DX y comprenden su hoja de ruta, sus fortalezas y sus limitaciones. Además, se preparan para aprovecharlo cuando sus herramientas maduren.

Afina tus herramientas: refactoriza y elimina

El hábito 7 de «Los hábitos de la gente altamente efectiva» es «Afilar la sierra». Esto significa que las personas más efectivas reconocen que no son perfectas y buscan constantemente mejorar tanto a sí mismas como sus procesos. Lo mismo ocurre con los equipos de Salesforce de mejor desempeño.

Los mejores equipos de Salesforce dedican tiempo a analizar sus procesos desde una perspectiva general y a evaluar si están lo más optimizados posible. Prestan atención a las nuevas herramientas y siguen tendencias como Salesforce DX.

También dedican tiempo a reducir la deuda técnica y refactorizar el código. Eliminan clases y desencadenadores de Apex que no se usan mediante cambios destructivos. Construyen pensando en el futuro y entienden que, especialmente en las organizaciones más grandes, los cambios que hacen hoy podrían seguir ejecutándose en Salesforce dentro de diez años. Por eso, dedicar unos minutos adicionales a revisar el código y a mantener y limpiar la base de código y los metadatos vale la pena.

‍