Conversaciones de pasillo en Dreamforce ‘17

Con este artículo, conoce las principales conclusiones de Dreamforce 2017, como el entusiasmo por Salesforce DX, los desafíos de integrar el control de versiones y la integración continua para Salesforce, y nuevas ideas para simplificar el flujo de desarrollo.

Estas son nuestras 5 conclusiones clave:

1. Salesforce DX fue el principal tema de conversación en Dreamforce y generó un entusiasmo generalizado por su rumbo y sus beneficios.

2. Integrar el control de versiones y la integración continua para Salesforce puede ser un desafío, pero soluciones como los commits automáticos en Git y un servicio alojado como Blue Canvas pueden simplificar el proceso.

3. Es posible que se necesite un nuevo flujo de desarrollo para Salesforce, con ideas como tener un sandbox para cada lanzamiento de funcionalidades.

4. Los registros de auditoría y el cumplimiento de SOX están cobrando mayor importancia para los equipos de desarrollo de Salesforce.

5. myTrailhead es una nueva y prometedora funcionalidad que se enfoca en la capacitación de clientes y podría tener un gran impacto en su éxito.

‍

Pasamos una semana increíble en Dreamforce. Esa conferencia transmite una energía especial. Este año hubo más aprendizaje que nunca. Nos preguntábamos si la incorporación de TrailheaDX como evento anual reduciría la calidad del contenido para desarrolladores. Pero nos sorprendió gratamente sentir que Dreamforce tuvo más contenido para desarrolladores del que recordamos del año pasado.

Antes de llegar a Dreamforce, teníamos algunas preguntas importantes que queríamos responder. Alex visitó el blog de Salesforce Ben para hablar sobre las 3 grandes preguntas para desarrolladores en Dreamforce. Algunas de nuestras preguntas se respondieron, pero, por supuesto, al final surgieron más.

Porque lo mejor de Dreamforce es el intercambio de ideas. Siempre obtenemos el mayor valor de esas pequeñas charlas de pasillo, de las perspectivas e ideas compartidas que surgen al escuchar en qué están trabajando los demás. Nos encantó conversar con amigos nuevos y de siempre, como Pruebas con Provar, Análisis de código, Prodly, The Welkin Suite y Illuminated Cloud. Por eso, pensamos en resumir brevemente algunas de nuestras mejores conversaciones y los temas de la semana. En las próximas semanas publicaremos más detalles sobre algunos de ellos.

Integrar Salesforce DX en un flujo de trabajo es emocionante, pero desafiante

El tema que todos tenían en mente era Salesforce DX. Hubo más de 10 sesiones al respecto y tuvo un lugar destacado en la conferencia principal para desarrolladores. Salesforce DX apareció literalmente en cada conversación que tuvimos. Hubo un entusiasmo generalizado por DX y el rumbo que está tomando. Los desarrolladores de Salesforce se sienten valorados y escuchados como no se habían sentido en años.

Muchos equipos nos preguntaron cómo podían integrar DX en su flujo de trabajo sin alterarlo demasiado. Después de todo, las organizaciones temporales requieren una nueva estructura de directorios que dificulta un poco el trabajo con los sandboxes existentes. Y capacitar a los administradores para que usen el control de versiones regularmente ha sido un desafío durante los últimos años.

Actualmente, la mayoría de los equipos hacen una de estas dos cosas: a.) No usan ningún control de versiones. O b.) Intentan configurar scripts de Ant para hacer una copia de seguridad semanal de los cambios en Git. Los problemas de a.) son evidentes. El problema de b.) es que no obtienes información de muy buena calidad.

Dedicamos nuestras conversaciones de pasillo a mostrar nuestra próxima integración de Salesforce DX con Blue Canvas. Les mostramos a nuestros clientes y amigos cómo pronto podrán crear una organización temporal desde la interfaz de Blue Canvas. Luego podrás cargar en ella los metadatos de tu sandbox y usarla como una rama de desarrollo para una funcionalidad. Cuando estés listo, podrás volver a integrar los metadatos en el sandbox, tal como lo harías con ramas normales. Recibimos buenos comentarios sobre nuestra demostración y pronto publicaremos más información al respecto.

Administradores y control de versiones

Muchos equipos querían intercambiar ideas sobre cómo incorporar a los administradores y a los integrantes menos técnicos al uso del control de versiones. Lo bueno de Salesforce es que los administradores, analistas de negocios, gerentes de proyectos, contratistas, consultores y otros pueden hacer cambios en Salesforce. Pero esto dificulta que cualquier desarrollador capacite a su equipo para usar el control de versiones.

Actualmente, la mayoría de los equipos hacen una de estas dos cosas: a.) No usan ningún control de versiones. O b.) Intentan configurar scripts de Ant para hacer una copia de seguridad semanal de los cambios en Git. Los problemas de a.) son evidentes. El problema de b.) es que no obtienes información de muy buena calidad. Cuando usas Ant para enviar todo tu código de una vez, no obtienes actualizaciones detalladas sobre los cambios, no sabes quién cambió qué y no puedes volver a estados anteriores.

El objetivo de toda esta configuración era mejorar la eficiencia mediante la automatización. Sin embargo, los equipos no lograban su objetivo porque configurar la integración continua con Git y Salesforce todavía requería muchos pasos manuales.

A la gente pareció gustarle nuestra solución de tener commits automáticos en Git cada vez que un administrador realiza un cambio declarativo o de código. Esto permite que los administradores obtengan los beneficios del control de versiones y de CI sin tener que volver a capacitarlos. También te ofrece commits más detallados que facilitan las auditorías y el cumplimiento de Sox (más sobre esto después).

Cómo simplificar el flujo de trabajo con Git y la integración continua para Salesforce

Cada vez más equipos reconocen los beneficios de la integración y la entrega continuas, y bastantes tienen iniciativas corporativas en marcha para implementar el control de versiones y CI para Salesforce en 2018.

Tuvimos una conversación de pasillo con 4 o 5 equipos de Salesforce de distintos tamaños que compartían un problema similar. Trabajaban con scripts de Ant y herramientas externas de CI como Jenkins y TravisCI. Usaban GitHub o Bitbucket. Hacían todo lo posible por seguir el Flujo de desarrollo con Git para Salesforce. Eran equipos competentes, con mucho presupuesto y talento. Y, aun así, no encontraban el flujo adecuado para desarrollar en Salesforce. No a todos los integrantes del equipo les resultaba intuitivo Git. No todos recordaban seguir estrictamente el proceso.

El objetivo de toda esta configuración era mejorar la eficiencia mediante la automatización. Sin embargo, los equipos no lo lograban porque configurar CI con Git y Salesforce todavía requería muchos pasos manuales. Antes de implementar, tenías que recordar hacer un commit en Git. Necesitabas llevar tu código y tus metadatos a Git. Esto puede ser complicado según el tipo de metadatos que intentes mover. Plantillas de correo electrónico, clases de Apex, perfiles, conjuntos de permisos, reglas de flujo de trabajo y desencadenadores: todos presentan distintos desafíos, dependencias y requisitos. Una vez que alguien envía los cambios a Git, hay que implementar. Implementar sin problemas es difícil debido a esas dependencias. Si un administrador modifica una plantilla de correo electrónico y ese cambio no se registra en Git, la clase de Apex que hace referencia a ella podría no implementarse correctamente.

Muchísimos equipos tienen dificultades con esto: enviar código de Salesforce a Git y viceversa. Es realmente complicado. Les mostramos a los equipos lo que estábamos haciendo para que Git dejara de ser una preocupación en el flujo de desarrollo de Salesforce. Al vincular más estrechamente tu repositorio de Git con tus organizaciones mediante un servicio alojado, ya no tienes que realizar los pasos manuales que tantos problemas les causan a los equipos. Blue Canvas realiza commits automáticos continuos en tu repositorio. Así, nunca hay discrepancias entre Git y las organizaciones. Esto convierte tanto a Git como a la organización en una fuente de verdad y permite implementaciones más limpias.

Muchos equipos intentan hacer lo correcto al incorporar un flujo de Git en Salesforce. Pero, debido a la propuesta de valor única de Salesforce, hay partes del flujo de Git que son demasiado complicadas o innecesarias; que generan más caos y burocracia que valor.

También es útil porque facilita la inclusión de administradores y personas con menos conocimientos técnicos en el flujo de desarrollo.

Un sandbox para cada lanzamiento de funcionalidades

Tuvimos una conversación muy interesante con un equipo de desarrollo de Salesforce de una gran empresa. “¿Cada desarrollador debería tener su propio sandbox? ¿Deberían tener varios entornos de pruebas de aceptación de usuarios y de preproducción?”, preguntaron.

Al final, encontramos juntos una solución que tenía mucho sentido. Se sentía el entusiasmo en la sala mientras concretábamos la idea.

“¿Qué tal si tuvieran un sandbox para cada versión?”, dijo uno de nosotros. “Ya sea una versión mensual, semanal o trimestral, simplemente configuren un sandbox para esa versión. Hagan que los desarrolladores usen sus propias organizaciones de desarrollo y sandboxes para crear funcionalidades. Que implementen continuamente pequeños bloques de metadatos en este sandbox de versión. Así podrán resolver aquí todos los conflictos de fusión, las dependencias y los problemas. De ese modo, el sandbox de versión siempre estará listo y podrá implementarse en cualquier momento. También podrán realizar pruebas muy completas aquí. Una vez que la versión esté lista, podrán implementar el sandbox de versión directamente en producción. Esto simplifica mucho las cosas”.

A todos se les iluminaron los ojos. Muchos equipos intentan hacer lo correcto al incorporar un flujo de Git en Salesforce. Pero, debido a la propuesta de valor única de Salesforce, hay partes del flujo de Git que son demasiado complicadas o innecesarias; que generan más caos y burocracia que valor. En nuestras conversaciones aprendimos que probablemente sea necesario desarrollar un nuevo flujo para Salesforce. Pronto publicaremos más sobre esto.

Registros de auditoría y cumplimiento de SOX

Salesforce ha alcanzado la madurez. Es una herramienta de desarrollo de software completa. Y, como tal, El cumplimiento de SOX y sus requisitos de separación de funciones y registros de auditoría surgieron mucho en las conversaciones. Muchos equipos buscan formas de obtener más datos sobre lo que sucede en sus organizaciones. Esto es especialmente cierto para los equipos que aprovechan los servicios profesionales o de consultoría. Los commits automáticos en Git resultaron muy atractivos para los equipos que tenían dificultades con esto. Muchos de nuestros clientes nos usan exclusivamente para este propósito.

Menos conversaciones sobre Einstein y Lightning

Muchas de las demostraciones de Salesforce ahora se realizan con Lightning, y Einstein tuvo más de 40 sesiones dedicadas. Aun así, generaron menos interés que DX. Es cierto que podríamos estar escuchando a un grupo sesgado por la naturaleza de nuestro producto, pero fue interesante. Tal vez la gente siga esperando beneficios más concretos de Einstein.

myEinstein parece interesante y promete permitir que los desarrolladores de Salesforce “creen aplicaciones más inteligentes y predictivas que aprovechen sus datos de Salesforce y resuelvan sus desafíos de negocio específicos… Así, todos podrán contar con IA personalizada para su negocio, sin necesitar un científico de datos”.

myTrailhead

Salesforce es excelente para convertir herramientas internas en funcionalidades para sus clientes. myTrailhead es un nuevo y alentador reconocimiento de que la capacitación es una parte fundamental del éxito de los clientes. Salesforce está innovando aquí de una manera muy práctica. No es tan llamativo como la IA, el aprendizaje automático o el IoT, pero hacer más accesible la capacitación de los clientes tendrá un impacto profundo en su éxito. Nos entusiasma ver cómo evoluciona esto, al igual que a muchas de las personas con las que hablamos.

‍