Control de versiones y administradores de Salesforce

Salesforce MVP Peter Knolle tiene uno de los mejores blogs de Salesforce que existen. Es perspicaz y completo, y ofrece una excelente perspectiva sobre una amplia variedad de temas que afectan a los desarrolladores de Salesforce. El blog suele tomar prácticas y temas normalmente ajenos al ecosistema de Salesforce e incorporarlos al ciclo de vida del desarrollo en Salesforce. Por ejemplo, su publicación sobre Consejos destacados de Javascript para desarrolladores de Visualforce.

En cuanto se anunció Salesforce DX, compartió una lista detallada de reflexiones y expectativas sobre DX y lo que significa. Nos encanta el artículo porque resume muchos de los principales desafíos del desarrollo en Salesforce y una lista de soluciones propuestas. Esta cita al final nos llamó especialmente la atención:

“Dejé esto para el final, pero quizá sea lo más importante, porque todos deben seguir el proceso para que funcione. ¿Cómo se integrarán los administradores en los procesos de control de código fuente e integración continua? Usar herramientas de control de versiones como Git o SVN y configurar herramientas de integración continua como Bamboo o Jenkins forma parte de las habilidades de un desarrollador.

Si aceptas la premisa de que todos los cambios en los metadatos son cambios de código y deben seguir los mismos procesos que los cambios de código tradicionales (es decir, Apex y VF) que permite Salesforce DX, entonces debe haber una forma de que los administradores participen.

Todo se viene abajo si los administradores hacen cambios en producción o en un entorno de pruebas y los implementan mediante conjuntos de cambios sin usar el control de versiones. Como es tan fácil hacer cambios declarativos, sea cual sea la forma de implementar este proceso, debe hacerse de modo que resulte sencillo para los administradores.”

Este es un problema real y, como dice Peter, podría ser el “más importante” que enfrentan los desarrolladores y administradores de Salesforce.

Salesforce es excelente, precisamente porque puedes hacer tanto con cambios declarativos y código. Personas con perfiles muy diversos pueden contribuir a crear aplicaciones excelentes, y la formación tecnológica no es una barrera de entrada. Los gerentes de producto y analistas de negocio que entienden el lado empresarial de la tecnología no se ven limitados por no saber programar. En cambio, pueden hacer cambios en la aplicación e incorporar sus conocimientos y experiencia en las implementaciones de Salesforce.

Lo que hace que Git y el control de código fuente sean excelentes es que constituyen una Fuente de verdad. Te permite saber quién cambió qué y cuándo en tu organización. Te permite saber exactamente en qué estado se encuentra tu base de código hoy y, lo que es crucial, cómo llegó hasta ahí. Puedes usar el control de versiones para entender cómo ha cambiado tu base de código con el tiempo.

Sin embargo, hay un problema. Con la forma en que funciona hoy el desarrollo en Salesforce, estos dos enfoques están en constante tensión. Por un lado, Salesforce es excelente porque quienes no son desarrolladores tienen suficiente libertad para hacer cambios en las aplicaciones según su experiencia. Sin embargo, esto entra en conflicto con las ventajas del control de código fuente y Git, ya que dificulta considerar el control de versiones como una fuente de verdad.

Como señala Peter, todos los metadatos son código y deben registrarse en el control de código fuente. Si alguien inicia sesión en producción y actualiza un flujo de trabajo o un campo, y eso no queda registrado en el control de código fuente, tendrás problemas con tu integración continua.

Es como iniciar sesión en un antiguo servidor FTP, hacer un cambio directamente y no registrar ningún commit.

Cómo ayuda Blue Canvas con el control de versiones de Salesforce

Blue Canvas busca resolver este llamado “problema de los administradores” de Salesforce DX. Blue Canvas monitorea continuamente tus organizaciones conectadas para detectar cambios declarativos y registrarlos automáticamente como commits en Git. Esto significa que ahora todos los cambios que hacen los administradores quedan completamente registrados en el control de versiones y, en particular, en Git. En esencia, Blue Canvas garantiza que tu control de versiones sea realmente una fuente de verdad. Visita nuestra página dedicada a esta funcionalidad para conocer más sobre el control de versiones de Salesforce con Blue Canvas.

Lo mejor de todo es que los administradores no necesitan capacitación especial. Como señala Peter:

“Usar herramientas de control de versiones como Git o SVN y configurar herramientas de integración continua como Bamboo o Jenkins forma parte de las habilidades de un desarrollador. Si aceptas la premisa de que todos los cambios en los metadatos son cambios de código y deben seguir los mismos procesos que los cambios de código tradicionales (es decir, Apex y VF) que permite Salesforce DX, entonces debe haber una forma de que los administradores participen.”

Con Blue Canvas, los administradores pueden continuar con su trabajo diario y hacer cambios como siempre a través de la interfaz de Salesforce. Los desarrolladores pueden tener la tranquilidad de que esos cambios terminarán en el control de versiones.