Configuración de sandboxes para la integración continua en Salesforce

Integración continua y una gestión adecuada de versiones fueron dos de los temas más destacados en Dreamforce ‘16, y muchas sesiones abordaron las mejores prácticas de desarrollo en Salesforce. Una que realmente se destacó fue del MVP de Salesforce Alex Sutherland charla Gestión de cambios con una arquitectura de sandboxes bien diseñada. Clara y práctica, esta charla es una de nuestras favoritas porque explica de forma concreta cómo configurar la infraestructura más importante que Salesforce proporciona para desarrollar en su plataforma: los sandboxes.

Gestión de cambios con una arquitectura de sandboxes bien diseñada de Alexander Sutherland

Antes de abordar la integración continua en Salesforce con herramientas como Jenkins, Bamboo y scripts de Ant, necesitamos una arquitectura de sandboxes bien diseñada. En esta publicación repasaremos la charla de Alex y compartiremos algunas ideas propias sobre cómo configurar sandboxes para la integración continua en la plataforma Force.com.

Cambios en producción

Alex es presentado por el arquitecto de éxito del cliente de Salesforce Ingo Fochler y cuenta una historia lamentablemente familiar antes de que Alex comience:

Un cliente muy grande creó una regla de validación y no la probó adecuadamente. Usaba Email-to-Case. El cambio provocó una falla en Email-to-Case y tardaron cuatro días en detectarla. Cuando lo hicieron, tenían 12,000 correos electrónicos pendientes.

Está claro que hacer cambios directamente en producción es arriesgado. Los arquitectos de éxito del cliente lo ven con demasiada frecuencia; los sandboxes pueden ayudar.

Conozco los sandboxes e incluso los uso, pero necesito repasar los detalles

A veces usamos cosas todos los días y les sacamos mucho provecho sin conocer todos sus detalles: WiFi, anestesia general, lenguaje de máquina. Para muchos, puede pasar lo mismo con los sandboxes. Sabemos en términos generales qué hacen y cómo nos ayudan, pero a menudo olvidamos qué hace cada edición y cuáles son sus limitaciones.

Todos los administradores también deberían tener sandboxes. Los llamamos sandboxes de desarrollo, pero los administradores realizan cambios de configuración que pueden afectar tu entorno de producción tanto como los cambios de código, por lo que deben tratarse de la misma manera.

La mayoría de los desarrolladores y administradores de Salesforce saben qué es un sandbox: una copia completa de la configuración de tu entorno de producción. En otras palabras, es un entorno de práctica donde puedes crear y probar cambios sin afectar a tus usuarios en producción.

Hay cuatro niveles de sandbox

Salesforce ofrece cuatro tipos de sandbox: Developer, Developer Pro, Partial Copy y Full Copy. En principio, todos funcionan de la misma manera, pero cada uno tiene reglas distintas sobre la capacidad de almacenamiento de datos y la frecuencia de actualización.

¿Por qué usar sandboxes para desarrollar en Salesforce?

Los sandboxes te permiten probar tu código y tus cambios de configuración en un entorno seguro, aislado de tus usuarios finales. Puedes ejecutar pruebas manuales y pruebas automatizadas para asegurarte de que tus cambios funcionen bien antes de pasarlos a un entorno de producción.

Como señala Alex, otra razón por la que los sandboxes son tan útiles es que te permiten trabajar en varias cosas en paralelo. Nadie trabaja en una sola funcionalidad o proyecto a la vez. Nadie recibe todos los requisitos necesarios para un proyecto o funcionalidad de una sola vez y sin cambios. Con los sandboxes, puedes aislar el trabajo en distintos entornos. (Este concepto es similar al de las «ramas de funcionalidad» en Git Flow de Atlassian para Salesforce y se analizará con más detalle más adelante).

Los sandboxes también impulsan la innovación. Dan a los desarrolladores la libertad de probar cosas nuevas, incluso ideas arriesgadas que podrían generar grandes beneficios a largo plazo, pero que no querrías llevar a producción de inmediato.

Configura tus sandboxes

Todos estamos de acuerdo en que los sandboxes son excelentes, pero ¿cómo debería usarlos un equipo de desarrollo? Como señala Alex durante esta charla, no hay motivo para que alguien con la edición Pro, Enterprise o Unlimited no tenga al menos un sandbox por desarrollador. Esto es importante para aislar el trabajo y garantizar que nadie sobrescriba el código de los demás.

También señala que todos los administradores también deberían tener sandboxes. Los llamamos sandboxes de desarrollador, pero los administradores hacen cambios de configuración que pueden afectar tu entorno de producción tanto como los cambios de código, por lo que deberían tratarse de la misma manera.

Los detalles de cómo configurarás tus sandboxes dependerán del tamaño de tu equipo de desarrollo. En su charla, Alex repasa varios tipos de configuraciones de sandbox según su complejidad.

El primer ejemplo de Alex es una arquitectura sencilla de sandboxes en la que un desarrollador tiene un sandbox Dev Edition para hacer cambios. Cuando termina, envía los cambios a otro sandbox Developer Edition de configuración, de donde pasan a un sandbox Partial Copy para las pruebas de aceptación del usuario (UAT). Luego pasan a preproducción y, por último, a producción.

Un reconocimiento a Alex Sutherland de CRM Science.

Alex también propone una configuración más compleja que podría verse así:

Un reconocimiento a Alex Sutherland de CRM Science.

Tu configuración dependerá de tu organización y tus necesidades. Sin embargo, hay algunos principios generales que sí se aplican:

• Cada desarrollador y administrador debería tener su propio sandbox Developer Edition o Developer Edition Pro. Si tu plan lo permite (y probablemente permite más de lo que crees), deberías dejar que los desarrolladores y administradores usen distintos sandboxes para distintas funcionalidades.
• Usa un sandbox Partial Copy para realizar pruebas de aceptación del usuario en un entorno similar al de producción. Este entorno de UAT es ideal para ejecutar pruebas y garantizar que los nuevos cambios no afecten las funcionalidades existentes. También puedes tener un segundo o tercer entorno de pruebas para preproducción e integración. Podría ser un sandbox Full Copy para asegurarte de que realmente estás probando en un entorno que refleja el de producción.
• Integra los cambios con frecuencia en UAT o preproducción antes de pasarlos a producción.Los desarrolladores y administradores deberían enviar sus cambios a UAT para garantizar que funcionen bien juntos.
• Actualiza tus sandboxes con la frecuencia permitida por Salesforce. Esto es algo que muchas personas olvidan hacer. Es importante mantener los metadatos del sandbox lo más alineados posible con los de producción. En Blue Canvas, hemos hablado con usuarios que han dejado que sus sandboxes se alejen mucho de producción, lo que dificulta cada vez más implementar de forma segura con cada versión. ¿Cómo puedes probar adecuadamente tu código nuevo o tus cambios de configuración si tu entorno de producción es muy diferente de tu sandbox? Como mínimo, actualiza tus sandboxes antes de cada lanzamiento estacional de Salesforce. Así podrás asegurarte de que reflejen fielmente el entorno de producción.
• Implementa también con frecuencia. Implementar cambios pequeños con frecuencia es la mejor forma de desarrollar, porque te permite mejorar tu aplicación de manera incremental. Si algo sale mal, siempre puedes volver a la versión anterior. En cambio, si tienes ciclos de lanzamiento largos, puede ser difícil revertir los cambios o incluso identificar qué está causando el problema.
• Usa control de versiones.

¿Por qué no lo hacen más personas?

Si los beneficios de los sandboxes y de probar antes de pasar a producción son tan claros, ¿por qué no lo hace la gente?

Por un lado, hacer cambios en producción es tentadoramente fácil. Pero la mayoría de los equipos de desarrollo ya conocen las desventajas de este enfoque. Así que no se trata solo de pereza.

El principal problema es que resulta muy difícil mover código entre entornos. Si estás satisfecho con el estado de tu sandbox Developer Edition, es sorprendentemente difícil trasladar esos cambios a otro entorno. Con los conjuntos de cambios, es un proceso lento y manual. Si intentas automatizarlo con scripts de Ant y las API de Metadata y Tooling, requiere mucho trabajo de configuración y aun así se ejecuta con bastante lentitud.

Los desafíos de sincronización se presentan en ambas direcciones. No solo es difícil mover tus cambios de desarrollo a preproducción, pruebas y producción; también es complicado actualizar tu sandbox para que sus metadatos reflejen los de producción. Salesforce limita drásticamente la frecuencia con la que puedes actualizar los sandboxes (solo una vez cada 5 días y 29 días para los sandboxes Partial Copy y Full Copy, respectivamente). Además, hacerlo es un proceso lento, tedioso y manual. Quizás quieras que tus entornos de desarrollo se parezcan al de producción, pero lograrlo no es nada fácil.

Salesforce DX, Blue Canvas y el futuro

Salesforce reconoce que su enfoque actual de implementaciones presenta problemas que impiden aprovechar al máximo su oferta de sandboxes, que es realmente muy buena. Salesforce DX es un intento de Salesforce por empezar a resolver este problema.

Una de las funciones más interesantes de Salesforce DX serán las organizaciones temporales. Las organizaciones temporales son un nuevo tipo de organización que se puede crear de forma relativamente rápida y automática para los procesos de integración continua. Estas organizaciones harán que la creación de ramas por funcionalidad sea aún más práctica y atractiva para los desarrolladores.

Salesforce DX también busca resolver el problema de las implementaciones mediante actualizaciones de la CLI de Force.com y diversas API. Este cambio será bien recibido y debería facilitar la configuración de un flujo adecuado de integración continua.

Blue Canvas funcionará directamente con Salesforce DX a medida que esté disponible, para que puedas aprovechar todas las mejores funciones de DX de forma sencilla y directa.

Por último, Blue Canvas permite realizar implementaciones entre organizaciones con solo hacer clic en un botón. Blue Canvas utiliza Git internamente para que las implementaciones de Salesforce sean extremadamente rápidas. Esto permite aprovechar los sandboxes como nunca antes y hace realidad el sueño de una verdadera integración continua en Salesforce.

‍