Gestión de proyectos complejos de Salesforce con ramas de funcionalidad

Este artículo te presentará el concepto de “historia de usuario” aplicado al desarrollo en Salesforce para agilizar la gestión de versiones para administradores, analistas de negocio y desarrolladores. Explicaremos cómo funciona, su ciclo de vida y cómo se integra en tus flujos de trabajo actuales para mejorar la organización y la velocidad sin agregar complejidad.

Estas son nuestras 5 conclusiones clave:

• Las “Historias” de Blue Canvas funcionan como tickets o elementos de trabajo y ofrecen un sistema unificado que conecta el control de versiones, los cambios de código, las revisiones de código y las versiones publicadas.
• Una historia incluye un título, una descripción y varios componentes, lo que crea un contexto que se documenta por sí solo a lo largo del tiempo en tu organización de Salesforce.
• Blue Canvas registra automáticamente los cambios realizados en Salesforce como commits en una rama de Git, lo que simplifica la implementación entre organizaciones.
• Las historias se pueden enviar a validación y revisión de código, lo que mejora el control de calidad mientras se documenta el proceso de negocio.
• Se pueden agrupar varias historias en una versión, lo que favorece una mejor organización, ciclos de publicación más rápidos y reversiones más seguras si son necesarias.

Los equipos de Salesforce tienen mucho trabajo. En todo momento hay múltiples proyectos de distintas partes interesadas de la empresa. Y cada proyecto es complejo y tiene muchas piezas en movimiento. El negocio avanza a un ritmo impredecible, por lo que puede ser difícil aportar previsibilidad al proceso de gestión de versiones de Salesforce.

Para mejorar la previsibilidad, la velocidad y la medición, la mayoría de los equipos ágiles de software aprovechan el control de versiones y, en particular, las ramas de funcionalidad. Las ramas de funcionalidad permiten a los equipos trabajar en múltiples elementos de trabajo o tickets en paralelo. Con ellas, puedes guardar temporalmente tus cambios y cambiar de contexto a lo largo del día. Están diseñadas para simplificar la gestión de proyectos y hacerla más eficaz.

Sin embargo, como hemos explicado en detalle, lograr que un flujo de Git adecuado funcione con Salesforce puede ser complicado. Y cuando incorporas a administradores y analistas de negocio, el panorama se complica aún más. Esto significa que adoptar ramas de funcionalidad con el flujo tradicional de Git es casi imposible para la mayoría de los equipos.

Pero no es necesario: existen otros modelos de ramificación que funcionan como herramientas potentes para gestionar proyectos complejos. Blue Canvas ha desarrollado un nuevo concepto de ramificación que realmente funciona para administradores de Salesforce, analistas de negocio y desarrolladores, sin agregar complejidad ni costos adicionales, como la capacitación para usar nuevas herramientas de línea de comandos.

Lo hacemos con nuestro concepto de “Historias”, que te permite agrupar cambios en paquetes virtuales que se pueden enviar en múltiples direcciones a distintos entornos.

¿Qué es una historia de usuario en el desarrollo de Salesforce?

Una historia abarca muchas cosas. Pero, básicamente, puedes pensar en ella como un ticket o un elemento de trabajo en una herramienta de gestión del ciclo de vida de aplicaciones como Jira o VSTS. Comienza con un título y una descripción del trabajo por realizar.

Como Blue Canvas también funciona como una herramienta de control de versiones también puedes aprovechar Git para fijar distintos componentes al ticket mientras trabajas. Esto te permite crear y mantener el contexto en tu organización a lo largo del tiempo de una forma que se documenta por sí sola.

La historia también tiene muchos otros metadatos asociados para la organización y el seguimiento, como un historial de comentarios y acciones (ideal para revisiones de código de metadatos de Salesforce y auditorías SOX). También incluye información sobre el origen y el destino de la implementación, cuándo se realizó, quién la ejecutó y quién la aprobó.

El ciclo de vida de una historia de usuario

Las historias se convierten en la unidad básica de los cambios en tu organización de Salesforce.

Para cada cambio, creas una historia y aportas contexto sobre el trabajo que contendrá. Esto incluye un título y una descripción. A menudo, te convendrá pegar la URL de los tickets que tengas en sistemas de gestión externos (la integración con Jira está en nuestros planes; ¡avísanos si tienes alguna solicitud!). Cuanto más pequeñas sean las unidades de cambio, mejor, porque te permiten gestionar los cambios con mayor detalle.

A veces, los desarrolladores o administradores crean un solo ticket y trabajan en él de principio a fin. Otras veces, crean varios a la vez para su sprint.

Blue Canvas te permite crear y gestionar estos tickets, además de guardarlos como borradores para que puedas retomarlos más adelante.

Agregar cambios a una historia

Mientras haces cambios en Salesforce como de costumbre, Blue Canvas los detecta en segundo plano y los registra en una rama de Git por ti. Cada cambio se registra como un commit que puedes visualizar como una diferencia respecto a otras organizaciones. Esto hace que implementar entre organizaciones sea tan sencillo como comparar diferencias de Git y crear solicitudes de incorporación de cambios.

Cuando un cambio en un componente está listo para avanzar en el flujo de implementación, puedes volver rápidamente a tu historia en borrador y fijar los cambios de esta manera:

Puedes filtrar componentes y buscar en distintos niveles.

Fijar cambios a tus historias es una propuesta de valor clave de Blue Canvas, ya que te permite vincular el qué con el porqué. La historia contiene la justificación del cambio y la revisión de código asociada. También contiene el código que se actualizó, lo que te permite documentar tu proceso de negocio en tiempo real. Así, si dentro de dos años quieres entender por qué se creó o modificó una clase, podrás ver el razonamiento detrás de ella. Esto puede reducir la deuda técnica y mantener tu organización de Salesforce en buen estado.

Envío a revisión de código y validación

Cuando estés listo, puedes enviar tu historia para validación y revisión de código. En este punto puedes establecer el nivel de pruebas que quieres ejecutar e incluso especificar cuáles quieres incluir.

Ahora puedes encontrar la historia en tu lista de historias abiertas junto con su estado. La historia ya tiene una lista de componentes asociados, un estado de compilación (es decir, si se validó correctamente), un informe de pruebas si elegiste ejecutarlas y una sección de comentarios. Otros miembros del equipo pueden consultar los informes de pruebas y las diferencias de Git incluidas en esta especie de paquete virtual y compartir sus comentarios.

Si supera la revisión de código y la validación, se puede desplegar. Blue Canvas ofrece varios tipos de permisos para personalizar quién puede aprobar despliegues y en qué entornos.

Una vez que se haya desplegado, lo verás en tu lista de despliegues anteriores.

Promover varias historias como parte de una versión

Puedes tener varias historias para un mismo lanzamiento. Aquí es donde vuelve a entrar en juego el concepto de ramas de funcionalidades o paquetes virtuales. Cuando llega el momento de hacer un lanzamiento más amplio a producción al final de un sprint, Blue Canvas te permite seleccionar varias historias y asociarlas a un lanzamiento, tal como hiciste con los componentes de cada historia.

Puedes agrupar las historias y moverlas a otros entornos, como producción o UAT:

Incluso puedes clonar historias y desplegarlas en otros sandboxes o entornos posteriores tras un lanzamiento a producción para asegurarte de que los metadatos de tus sandboxes estén sincronizados con producción.

Las historias impulsan la velocidad y una mejor organización

Usar Blue Canvas para gestionar lanzamientos simplifica mucho su organización. En lugar de lidiar con hojas de cálculo, ahora puedes conectar tu control de versiones, cambios de código, revisiones de código, lanzamientos y sistema de tickets en un único sistema basado en las mejores prácticas ágiles. Esto también crea un registro de auditoría que puedes usar para cumplir requisitos normativos o simplemente realizar auditorías generales del sistema y reducir la deuda técnica.

También puedes lanzar más rápido al dedicar menos tiempo a depurar despliegues y crear conjuntos de cambios.

Por último, puedes confiar en la seguridad de tus lanzamientos porque puedes revertir estas historias según sea necesario.