Salesforce B2C Commerce y devOps

Atlassian… Salesforce… Microsoft… Tres editores, tres gigantes y ofertas de productos fundamentalmente diferentes. Diferentes sí, pero en Madagence hemos querido llevar el proceso de aproximación tecnológica entre estos tres monstruos hasta el final. 

Implementar un proyecto de comercio electrónico bajo Salesforce Commerce Cloud B2C requiere organización, rigor, pero también (sobre todo) escalabilidad, visibilidad y agilidad. 

PREÁMBULO 

En este artículo, le presentaremos una forma de integrar los servicios Atlassian (Jira & Bitbucket principalmente) y Office 365 (Teams principalmente) en un proyecto de Salesforce Commerce Cloud B2C. Aquí hablaremos de integración continua, automatización de proyectos y versión. 

Nuestros objetivos de diseño de integración entre Atlassian, Microsoft y Salesforce en Madagence han sido los siguientes: 

• Facilitar la vida diaria de nuestros colaboradores (Desarrolladores, Líderes Técnicos y Jefes de Proyecto) 
• Aumentar la legibilidad técnica de los proyectos (Versionning, Despliegue, etc.) para el conjunto de los actores no técnicos de los proyectos 
• Dejar de perder tiempo en acciones de bajo valor 

En este artículo hablaremos de «cómo hacerlo». Efectivamente, cualquier método es potencialmente inaplicable a un contexto dado; también es, sin duda, criticable. Para terminar, esta forma de hacer es sin duda mejorable. Por eso redactamos este artículo; para avanzar con la comunidad ;). 

Madagence

Madagence es una agencia de desarrollo experta en comercio electrónico. Ahora somos socios e integradores de Salesforce Commerce Cloud B2C. Nuestra experiencia tecnológica está garantizada hoy por un equipo de Makers (colaboradores) especializados y certificados en esta plataforma (Arquitectos, Líderes técnicos, etc.). 

Creemos en el mercado y en las innovaciones que Salesforce Commerce Cloud B2C ofrece a través de esta nube dedicada a la cadena de valor de comercio electrónico de nuestros clientes. 

Todos los proyectos implementados en Madagence se construyen con el Framework Agile Scrum. No implementamos el Framework Scrum de forma híbrida o parcial; lo integramos en su estado de arte el más completo. Más que un simple método de gestión de proyectos, la agilidad es un verdadero Mindset de la empresa y de nuestros colaboradores. 

REVISIÓN DE LOS OBJETIVOS 

Objetivo 1 : Facilitar la vida cotidiana de nuestros colaboradores (Desarrolladores, Líderes técnicos y Jefes de Proyecto) 

Objetivo 2 : Aumentar la legibilidad técnica de los proyectos (Versionning, Despliegue, etc.) para el conjunto de los agentes no técnicos de los proyectos 

Objetivo 3 : Dejar de perder tiempo en acciones de bajo valor añadido 

OBJETIVO 1: FACILITAR LA VIDA COTIDIANA 

¿Qué es lo que no le gusta hacer a un Desarrollador? ¿Qué es lo que no le gusta hacer a un Líder Técnico? ¿Qué es lo que no le gusta hacer a un Gerente de Proyecto? Tres preguntas tontas, tres preguntas que cuando se aportan respuestas y luego soluciones, permiten ahorrar tiempo. 

Lo que el Desarrollador no le gusta hacer: 

• Actualizar sus tickets de viaje. 
• Indicar sus tiempos de desarrollo 

Lo que el Líder Técnico no le gusta hacer: 

• [.. ] IDEM Desarrollador [.] 
• Pasar más tiempo desplegando que codificando 
• Pasar horas actualizando conjuntos de datos entre entornos (IMPEX) 

Lo que el Jefe de Proyecto no le gusta hacer: 

• Primer punto, lo más importante, no le gusta hacer lo que los demás deberían haber hecho 😉 
• Convertirse en arqueólogo para saber qué ticket está desplegado (o no) 
• Seguir el resto de su trabajo de forma manual 
• No saber cuándo puede iniciar su receta 

OBJETIVO 2: AUMENTAR LA LEGIBILIDAD 

Mantener vivo un proyecto de comercio electrónico y todos sus componentes no es tarea fácil. En efecto, las capas necesarias para la puesta en práctica de un proyecto de este tipo son numerosas. 

La roadmap del cliente, el backlog funcional, el corte técnico, el seguimiento de los tiempos, la gestión de las prioridades, la gestión de las fuentes, la administración de los entornos; todas sus capas invitan a la multiplicidad de las herramientas. 

No es raro encontrar la hoja de ruta de un cliente en un archivo de Excel, el backlog funcional en un Word, el corte técnico en una herramienta de gestión de proyectos (Redmine, Mentis, Jira, etc.) y para terminar un sistema de versioning junto con un motor de integración continua que viven en autarquía. 

La multiplicidad de instrumentos y la falta de integración de estos últimos provocan una falta de legibilidad de los proyectos. La forma de proceder que se presenta en este artículo deberá responder a este problema. 

OBJETIVO 3: DEJAR DE PERDER TIEMPO 

Aunque la reestructuración de algunos grandes grupos trae un viento nuevo sobre la organización de las empresas. Incluso si la agilidad comienza a expandirse en las mentes. Francia como España siguen siendo países donde se aman las cosas complejas; se aman las organizaciones complejas; se construyen los procesos bien hechos y que responden al conjunto de los casos. 

En Madagence creemos en la proximidad, la flexibilidad y la simplicidad. Son los ejes a seguir en todas partes; tanto en la organización de las empresas, como en la gestión de los proyectos y la estructuración de las herramientas. 

Volviendo a nuestros proyectos de Salesforce Commerce Cloud B2C, estos son los elementos en los que consideramos que se pierde tiempo, sin valor real. Esto es, por supuesto, propio de Salesforce B2C Commerce. 

• Entrar, o incluso volver a entrar manualmente nuestros tiempos 
• Saber cuándo se llevan a cabo los despliegues 
• Saber dónde se despliegan los tickets
• Actualizar el estado de los tickets 
• Construir informes manualmente 
  • Burn-Down, Sprint Load, etc. 
  • Avance de las releases 
  • Cálculo de la velocidad
• Implementar manualmente los tickets 
• Implementar manualmente las versiones 
• Implementar manualmente los datos (IMPEX) 
• Estimar tareas de manera rápida y eficiente 
• Identificación instantánea del downtime 
• Identificación instantánea de solicitudes con prioridad 1 

La forma de proceder deberá permitir limitar la pérdida de tiempo sobre los elementos anteriormente mencionados. 

ARQUITECTURA GLOBAL 

Para comprender de manera global la arquitectura de los intercambios entre los diferentes editores. Este es el esquema de las interacciones entre estos últimos. 

Atención, esto parece un proyecto de 70 días. ¡No te preocupes! Lo implementamos en 20 días laborables gracias a las integraciones ya existentes entre las diferentes herramientas. 

La clave del éxito; tener las herramientas adecuadas: Teams, Jira, Bitbucket, SFCC-CI. Con el uso de estas 4 herramientas, pocos problemas pueden llegar a ponerse en medio de su camino. 

El despliegue de una arquitectura de este tipo es fácil de implementar cuando se tiene poca o ninguna historia. Migrar varias decenas de proyectos bajo esta arquitectura se verá como otro par de mangas. 

Keys features

No vamos a evocar en este artículo la manera de poner en práctica una arquitectura de este tipo (es nuestro pequeño secreto). Vamos a hablar de lo más importante y por lo tanto de las características que ofrece esta manera de hacer. 

Smart Commit

Al crear una rama asociada a un ticket o al realizar la primera commit. Varias acciones se inician en Jira. 

• El paso del bolleto de «To Do» a «In Progress» 
• La información de «Commit» se muestra en el ticket 

En todos los commits, exigimos la normalización de los comentarios en el siguiente formato: ISSUE_KEY #time [Some amount in Jira time syntax] <Your Worklog comment text>.

Esto permite añadir una función de Time Tracking directamente a los tickets de JIRA. 

La funcionalidad de Seguimiento Temporal en JIRA permite controlar la noción de «Queda por hacer». De este modo, de un vistazo es fácil observar las tareas que toman más/menos tiempo de lo esperado. Esta funcionalidad también permite gestionar fácilmente el aterrizaje planning ya que el «Resto a hacer» está disociado de la estimación inicial. Esto nos permite extraer automáticamente una gestión de aterrizajes de nuestros lanzamientos. 

Ejemplo de una versión de prueba que sin duda será imposible de producir 😉 

Pull Request in JIRA

Durante todo su desarrollo, el desarrollador no tiene que ir a JIRA para actualizar el progreso de su ticket. La integración Bitbucket/ Jira se encarga de indexar la evolución del ticket en función del avance técnico. 

Al crear el Pull Request: 

• Cambio de estado del ticket: «In Progress» a «Developed» 
• Asignación automática de tareas a la persona encargada de la PR 

Al rechazar el Pull Request: 

• Cambio de estado del ticket: «Developed» a «To Do» 
• Asignación a la persona que creó el Pull Request 
• Notificación Teams a la persona que creó el Pull Request 

Al aceptar el Pull Request: 

• Cambio de estado del ticket: «Developed» a «Reviewed» 
• Implementación automática en el entorno de «Demo» 
• Se envía una notificación de Teams al Jefe del Proyecto Madagence para que pueda iniciar la receta

Toda la información sobre las solicitudes de Pull Request asociadas a un ticket es visible directamente en JIRA. 

Release Done in JIRA

En JIRA, la gestión de los sprints a través de las versiones ofrece una visión muy clara del avance del proyecto & técnico de los tickets presentes en el release. 

Cuando todos los tickets de una versión están en el estado «Tested», es decir, todos los tickets han sido recertidos por nuestros Jefes de Proyecto Madagence; una implementación empaquetada de todo el Release (Código Fuente + Diferencial DATA) es efectivo sobre el medio ambiente «Desarrollo». 

Para ello hemos implementado un Bitbucket Pipeline utilizando SFCC-CI. En un primer momento pasamos por el staging sin activar las versiones ni importar los datos. Luego nos desplegamos en «Development» activando la versión de código & importando los datos depositados. 

SFCC-CI y los Builds

Doblamos dos soluciones de Build que se pusieron a disposición de la plataforma Salesforce Commerce Cloud B2C. La famosa y antigua «Build Suite» y la nueva «SFCC-CI». 

Sin duda alguna; recomendamos «SFCC-CI». La utilización es más sencilla, la comprensión de la secuencia es más fácil, las mejoras de rendimiento en los edificios constatados van hasta un 70% de velocidad adicional y para terminar una implementación de 3 a 4 veces más rápida. 

A través de la solución Bitbucket Pipelines hemos implementado la suite «SFCC-CI». La lectura de la interfaz de Bitbucket Pipelines es clara, simple, eficiente. Las funciones esenciales están presentes, sin artificios que cubre el 100% de las necesidades. 

La gestión de las sucesiones de build entre los diferentes entornos está estandarizada y los despliegues entre demo, development, staging/prod son interdependientes. 

En Madagence hemos detenido el «Continious Delivery» en el entorno de «Development» porque nuestros clientes no están preparados para trabajar de esta manera en los entornos de Producción (Staging & Production). Pero en unos pocos clics la solución estaría en su lugar. 

Una vez más encontramos en JIRA, las informaciones sobre los Builds. 

Una vez más en Jira automatizamos: 

• Cuando se implementa la versión en «Development» > Cambio del estado de la versión JIRA. El cliente puede ahora iniciar su receta. 

Environments management

Obtener una representación gráfica de lo que contiene o no un entorno en un momento dado es una ganancia de legibilidad significativa. 

Una vez más JIRA nos ofrece esta posibilidad. Directamente en el ticket es posible saber dónde se encuentra (técnicamente) una solicitud. 

También es posible recuperar el historial de despliegues. 

Incluso es posible visualizar el ciclo de vida ínter-ambiente de un ticket a través de la vista que se muestra a continuación en Bitbucket. 

Para tener una vista global y no del ticket, existe otra interfaz dentro de Bitbucket. 

DATA Deployment

La gestión de datos entre entornos siempre es un rompecabezas. Todos hemos experimentado eventos como estos: 

• Actualización de una base de datos sobre un entorno de dev, no replicado en demo. 
• Actualización de contenido de prueba demo, no presente en desarrollo. 

Hemos implementado a través de SFCC-CI, una carga de los cambios en los datos a los entornos de destino. Este upload se basa en datos del entorno de origen & adjuntos al commit asociado. ¡El diferencial de los cambios realizados por el desarrollador en los datos se construye automáticamente! Solo es necesario iniciar una línea de comandos al principio y al final del desarrollo y el diferencial de datos se engancha automáticamente al código fuente. 

El ahorro de tiempo & la gestión de los efectos de los bordes es significativo en este punto. Aunque difícilmente cuantificable estimamos entre 5% y 10% el ahorro de tiempo en un equipo de proyecto en fase de BUILD.  

Priority « Highest »

Tenemos cinco niveles de prioridad en Madagence, en los que nuestros SLAs están trabajando. A través de la Jira Project Automation, hemos creado vías sencillas que permiten rastrear eficazmente las alertas sobre las solicitudes prioritarias. 

Por ejemplo, en Teams notificamos las solicitudes de prioridad 1 o «Highest». 

Automation ROI

Planificamos sprints con nuestros clientes sobre la base de un solo & indicador. El R.O.I. Este indicador permite en segundos saber las tareas que tienen la relación esfuerzo/efecto más alta. 

Este indicador se calcula automáticamente de acuerdo con una receta académica y secreta de Madagence. Esta receta la hemos implementado en Jira a través de un Script Listener (Script Runner). Este script se ejecuta cada vez que se actualizan las tareas para recalcular el ROI en vivo.

Push up / down on Issue

En JIRA hemos diseñado varios scripts para gestionar la dependencia entre las tareas principales y las tareas secundarias. 

 

Por lo tanto, cuando estimamos la complejidad de las tareas durante la planificación del poker, las estimaciones se elevan automáticamente en las Stories y luego en las Epics. 

 

De manera similar, hay un script de gestión de los estados entre tareas. Cuando se actualiza un ticket: 

• Si el ticket es una Story, entonces todos los sub tickets se indexarán automáticamente al estado de la Story 
• Si el ticket es una Tareas; entonces la Historia que contiene la Tareas se indexa al estado más pequeño de sus sub tareas 

Cosas tontas que cada día permiten ahorrar algunos minutos; cada semana algunas horas y al final de un año varias decenas de días. 

CONCLUSIÓN 

No vamos a hacer una conclusión ampliada. Hemos enumerado a continuación los objetivos que nos habíamos fijado y cuáles son las características que apuntan a este objetivo. 

Una cosa es segura. En Madagence vemos la integración continua y la automatización del proyecto como un justo equilibrio que tiene como único objetivo: un aumento de la productividad y la calidad de nuestros servicios. 

Las posibilidades son infinitas cuando las herramientas adecuadas están en su lugar, por lo que siempre hay que tener en cuenta que la integración continua & la automatización de proyectos está al servicio del proyecto y no al revés. Para estar al servicio del proyecto, estas herramientas deben ser simples en la comprensión, en el mantenimiento. 

Nuestra conclusión: La simplicidad es la clave de la adhesión, la adhesión es la clave del éxito.