Gatear, caminar, correr: las fases del desarrollo en Salesforce
Establecer un mejor proceso de gestión de versiones de Salesforce lleva tiempo. Un enfoque por fases incluye el control de versiones básico, la integración continua, las pruebas y Salesforce DX.
Por Randalyn Hill-Coffer·Revisado por el equipo de Blue Canvas··5 min de lecturaEn este artículo, descubre el enfoque por fases para la gestión de versiones de Salesforce, desde el control de versiones básico hasta la integración continua, las pruebas y, finalmente, Salesforce DX. También aprendí sobre los desafíos de implementar DevOps en Salesforce y cómo herramientas como Blue Canvas pueden simplificar el proceso.
Estas son nuestras 5 conclusiones clave:
1. El control de versiones básico es esencial para que cualquier equipo de desarrollo de Salesforce evite incidentes graves.
2. La integración continua y la gestión de sandboxes pueden mejorar la seguridad de las implementaciones y la gestión de dependencias.
3. Las pruebas automatizadas son una inversión valiosa para cualquier equipo que haya implementado con éxito la Fase 2.
4. Salesforce DX es una parte clave de los planes futuros de Salesforce, pero implementarlo requiere una base sólida de integración continua y control de versiones.
5. Herramientas como Blue Canvas pueden simplificar el proceso de DevOps para los equipos de desarrollo de Salesforce.
Hablamos con equipos de desarrollo de Salesforce de todo tipo. Algunos son proveedores independientes de software con estructuras muy ágiles que han migrado sus procesos a Salesforce DX. Otros apenas están comenzando con scripts de Ant y control de versiones. Y otros nunca han oído hablar del control de versiones y solo buscan una forma sencilla de mejorar su proceso de gestión de versiones. En todos los equipos parece cumplirse una regla universal: establecer un mejor proceso de gestión de versiones de Salesforce lleva tiempo.

Los equipos de desarrollo de software de todo el mundo enfrentan dificultades con DevOps. Por eso existen innumerables documentos técnicos y decenas de empresas de integración continua que intentan reemplazar a Jenkins. Incluso equipos de élite como los de Google invirtieron enormes cantidades de tiempo, energía y recursos en establecer un ciclo de vida de desarrollo de software que funcione.
Lamentablemente, Salesforce no facilita este proceso. Configurar la integración continua y el control de versiones para Salesforce presenta desafíos particulares. Esto se debe en gran medida a las fortalezas de Salesforce: su interfaz declarativa y su facilidad de uso para una amplia variedad de perfiles de desarrolladores y administradores.
Pasar a CI/CD también es difícil porque no se trata simplemente de una solución. Requiere capacitación y la formación de nuevos hábitos. Es un proceso. E implementar procesos nuevos no sucede de la noche a la mañana.
Como muchos de nuestros clientes acuden a nosotros en busca de mejores prácticas de Salesforce, pensamos que sería útil hablar sobre el enfoque por fases que han adoptado nuestros clientes más exitosos.
Fase 1: Control de versiones básico
Muchos equipos no cuentan con respaldo de metadatos ni control de versiones. Esto es un problema grave y debe tratarse como una emergencia. Si no tienes ningún tipo de respaldo de metadatos, ¿qué harás si un desarrollador sobrescribe el código de otro? ¿Qué harás si publicas un error y necesitas revertir los cambios en producción? Implementar una solución básica de respaldo de metadatos es la fase 1 para cualquier equipo de desarrollo de Salesforce. Con un respaldo de metadatos, puedes tener la tranquilidad de saber que tu equipo está protegido frente a incidentes graves. Te permitirá dormir mejor por las noches.
También es un buen punto de partida porque es relativamente fácil de configurar. Con herramientas como Blue Canvas, puedes tener tus metadatos respaldados en minutos. Es un proceso de cuatro clics. No se requiere capacitación ni cambios en tus procesos. Así, puedes obtener las ventajas del respaldo y la seguridad sin pedirle a tu equipo que aprenda un flujo completamente nuevo. Lo ideal es que este respaldo sea en tiempo real, ya que te permitirá volver a estados anteriores.

Fase 2: Integración continua
Una vez que tengas respaldos continuos de tus metadatos en Git, podrás abordar una parte más compleja de tu flujo de desarrollo: la gestión de sandboxes y la integración continua. Este paso requiere un poco más de capacitación, por lo que perfeccionarlo tomará algunos meses.
El objetivo de esta fase es evitar que se sobrescriba código y usar una herramienta de control de versiones para el desarrollo. Los desarrolladores ya no deberían enviar código a ciegas de un entorno a otro. Deberían poder confirmar que los cambios son seguros antes de enviarlos. Además, todos los cambios deberían quedar registrados en un sistema que puedas usar para depurar y revertir cambios.
En esta fase, conviene pensar con más detalle cómo quieres configurar los sandboxes para tu equipo. Nuestros clientes más exitosos terminan adoptando un modelo en el que cada desarrollador tiene su propio sandbox de desarrollo. Luego, envían continuamente pequeños cambios a un sandbox de preproducción llamado UAT. También incorporan con frecuencia en sus sandboxes de desarrollo los cambios que otros realizan en UAT. Lo ideal es que envíen e incorporen cambios varias veces al día. Este patrón de cambios pequeños y específicos hace que las implementaciones sean mucho más seguras y la gestión de dependencias sea mucho más sencilla.
Esto requiere trabajo activo por parte de tu equipo: dejar atrás los scripts de Ant y los conjuntos de cambios para adoptar un modelo basado en Git y solicitudes de incorporación de cambios. Aunque conceptualmente no es tan diferente, tomará tiempo aprender el flujo y capacitar a las personas para que sigan el proceso con disciplina, sin desviarse para hacer cambios ad hoc. (Afortunadamente, Blue Canvas incorpora automáticamente los cambios ad hoc en Git, para que nunca te alejes demasiado de tu flujo).
Blue Canvas puede simplificar este flujo de versiones basado en Git para que no tengas que dedicar tanto tiempo a la capacitación.

Fase 3: Pruebas
Las pruebas automatizadas son un componente clave de cualquier flujo de integración continua. Muchas veces, los desarrolladores acuden a nosotros y quieren implementar pruebas de inmediato. Pero hay algunos obstáculos. En primer lugar, escribir buenas pruebas lleva tiempo. Además, todavía hay mejoras fáciles de lograr antes de dar ese paso: usar el control de versiones para respaldar metadatos y las solicitudes de incorporación de cambios para las implementaciones.
En segundo lugar, las pruebas pueden ser bastante lentas. Las pruebas unitarias pueden tardar horas. Debes asegurarte de que todas tus pruebas estén escritas de manera que se completen rápido y tengan altas probabilidades de pasar, para no ralentizar tus implementaciones.
Sin embargo, una vez que tengas un buen flujo de integración continua en funcionamiento, como se explicó en la Fase 2, conviene invertir en desarrollar pruebas automatizadas e incorporarlas a tu proceso de implementación.
Esto podría consistir en una combinación de pruebas unitarias automatizadas que se ejecuten cada vez que envíes cambios a tu entorno de integración. O podrías complementar tus pruebas unitarias con pruebas de Selenium, como las que nuestros amigos de Pruebas con Provar hacen.
Las pruebas automatizadas mejoran la calidad del código y te permiten avanzar más rápido. Son una inversión valiosa para cualquier equipo que haya implementado con éxito la Fase 2.

Fase 4: Salesforce DX
Salesforce DX es una parte clave de los planes futuros de Salesforce. Alinear a tu equipo con esa dirección es, sin duda, una prioridad. Sin embargo, DX aún es nuevo y le falta camino por recorrer para estar completo. Además, DX no es un producto, sino un paradigma de desarrollo. Adoptar ese paradigma llevará tiempo. Si tienes una aplicación heredada, será difícil hacer que DX funcione, ya que las estructuras de paquetes y directorios son diferentes.
Sin embargo, una vez que implementes la integración continua y las pruebas automatizadas junto con el control de versiones, podrás evaluar lo que DX ofrece. El concepto recién lanzado de las organizaciones temporales (scratch orgs) hace posible crear ramas por funcionalidad en Salesforce por primera vez. Esto representa un gran avance y hará que tu equipo sea más productivo, ya que podrá realizar varias tareas y trabajar en distintas funcionalidades y errores en paralelo.
Trabajar con Salesforce DX y las organizaciones temporales (scratch orgs) es una excelente manera de completar tu proceso de desarrollo de Salesforce y asegurarte de estar alineado con el rumbo que Salesforce ha definido para el futuro.

Conclusión
Implementar las mejores prácticas de desarrollo de Salesforce lleva tiempo. Sin embargo, hay mejoras fáciles de lograr. Te recomendamos comenzar por ellas y luego avanzar con otros cambios.



