El tren de lanzamiento de Salesforce: un enfoque práctico para la gestión de lanzamiento
Publicado: 2022-03-11La gestión de versiones, como su nombre indica, es el proceso de gestión, planificación, programación y control de una compilación de software a través de diferentes etapas y entornos; incluidas las pruebas y la implementación de versiones de software (Humble & Farley, 2011).
Es un tema bastante amplio en sí mismo y solo se puede perfeccionar con el tiempo probando diferentes iteraciones con los equipos de desarrollo y haciendo coincidir las necesidades comerciales o los lanzamientos de funciones. Intentaremos cubrir las prácticas de la industria de administración de metadatos, creación de CI y administración de sandbox para administrar el tren de lanzamiento de una organización.
Pero, ¿qué es un tren de liberación?
Un tren de lanzamiento es una técnica de entrega de funciones incremental y predecible. Requiere que el desarrollador establezca un proceso formal para tomar los cambios realizados en el entorno de desarrollo y ponerlos en producción.
Un tren de lanzamiento se puede dividir en términos generales en tres segmentos:
- Gestión de metadatos
- Construcción de integración continua
- Gestión de sandbox
Gestión de metadatos
Los metadatos son datos que proporcionan información sobre otros datos. Salesforce proporciona un modelo de metadatos completo y potente a través de su API de metadatos . Los metadatos de su aplicación describen y abarcan un conjunto de métodos que brindan acceso programático al código fuente y la configuración de su organización.
La API de metadatos es la mejor manera de administrar las personalizaciones en Salesforce. Es compatible con los métodos de create , read , update y delete . Puede utilizar los conjuntos de cambios, el IDE de Force.com y la herramienta de migración Ant para migrar metadatos de una organización a otra, ya que todos proporcionan migraciones a través de la API.
Cada herramienta tiene sus propias ventajas, y hay varias cosas a considerar al elegir una:
Tabla 1: Comparación de herramientas para la migración de metadatos
| Conjuntos de cambios | IDE de Force.com | Herramienta de migración de hormigas |
|---|---|---|
| Los conjuntos de cambios son la forma de implementar componentes a través de la interfaz de usuario estándar de Salesforce. | Force.com IDE (Eclipse) está diseñado principalmente para el desarrollo de Apex, pero se puede utilizar con fines de implementación. | Ant Migration es una poderosa herramienta de línea de comandos, dedicada a migrar cambios/metadatos entre entornos. |
| Por lo general, se utiliza para una pequeña cantidad de migración de componentes. | Los desarrolladores suelen utilizar el IDE para migrar cambios al entorno de prueba o ensayo. | Ant Migration se utiliza para la migración de grandes cargas útiles y requiere conocimientos avanzados de la API de metadatos de Salesforce. |
| La conexión entre las organizaciones debe establecerse manualmente, por lo que no es adecuada para implementaciones automatizadas. | Se puede usar para implementar en cualquier organización, pero necesita algunos pasos manuales, que son propensos a errores. | Las implementaciones automáticas se pueden programar muy fácilmente. |
| Diseñado para ser utilizado por los administradores. | Dirigido a desarrolladores de Salesforce, ya que desarrollar el código es su uso principal. | Orientado a ingenieros DevOps. |
| Agregar dependencias es muy fácil y fácil de usar. | Agregar dependencias es algo fácil, ya que proporciona una interfaz de usuario de apuntar y hacer clic. | La implementación suele fallar debido a la falta de dependencias. |
| No permite cambios destructivos. | Permite conjuntos de cambios destructivos, pero el proceso es bastante tedioso. | Permite conjuntos de cambios destructivos. |
La API de metadatos es excelente para cumplir su propósito al desarrollar y migrar cambios en la plataforma Force.com. Pero hay un pequeño problema: no todos los metadatos de Salesforce son compatibles con la API de metadatos. La documentación oficial proporciona una lista de componentes no admitidos.
Si su organización está realizando cambios que no son compatibles con la API de metadatos, debe asegurarse de replicar esos cambios manualmente en la organización de destino. La mejor manera de realizar un seguimiento de estos cambios es una hoja de cálculo. Si tiene que recurrir a este enfoque, siempre es recomendable que una sola persona realice estos cambios y realice un seguimiento de los mismos.
Esta sería una buena lista general de columnas que uno podría usar para rastrear estos cambios en una hoja de cálculo:
- Nombre del componente
- Tipo de componente
- Cambio de propietario
- Descripción de la funcionalidad
- Mapeo de capacidad
- Dependencia con otros componentes
- Nombre del revisor/revisado
- URL
- Nombre/ID de la organización
- Otros comentarios
Control de Versiones e Integración Continua
La migración de cambios a producción debería ser un proceso sencillo, ya que es solo una repetición de la aplicación de cambios en el entorno de prueba y ensayo. Aún así, siempre existe la posibilidad de que las cosas vayan mal, y entonces necesitas un plan alternativo. Es muy importante mantener una copia de seguridad de los metadatos de su organización, y para eso están el control de versiones y la compilación de CI .
El control de versiones es una necesidad absoluta para cualquier organización. Permite a los desarrolladores trabajar de forma colaborativa, eficiente y segura. Administrar el desarrollo y la migración de código de múltiples desarrolladores y múltiples sandbox es un desafío en Salesforce. Salesforce también tiene su propio calendario de lanzamientos y mantenimiento. Estas actualizaciones ofrecen nuevas funciones, pero podrían introducir un cambio en la API de metadatos que podría romper su compilación de CI. Por lo tanto, aparte de las situaciones en las que los desarrolladores sobrescriben los cambios de los demás, el control de versiones lo ayuda a crear una estrategia de reversión. Tener una estrategia de reversión es imprescindible cuando su aplicación se ejecuta en Force.com.
El siguiente diagrama de flujo muestra una estructura práctica para Control de versiones y CI. Intentaremos darte una breve descripción de lo que representa el diagrama.
- Un desarrollador verificaría su cambio en el sistema de control de versiones.
- El servidor CI/Jenkins implementaría la última compilación en el espacio aislado de CI y ejecutaría clases de prueba.
- Si la implementación en el paso 2 es exitosa, los cambios se fusionan en la rama de control de calidad.
- Luego, CI implementaría la última confirmación de la rama de control de calidad en el entorno limitado de control de calidad.
- Si QA rechaza los cambios debido a fallas en las pruebas, los pasos 1 a 3 se deben realizar nuevamente hasta que QA borre los cambios.
- Una vez que los cambios pasan las pruebas de control de calidad, los cambios se fusionan en la rama maestra.
- Los cambios más recientes de la rama principal se implementan en el espacio aislado principal.
Se puede optar por agregar más sucursales según las necesidades de la organización. Pero la estructura anterior funciona bien para las estructuras de desarrollo de nivel medio a empresarial.
Gestión de Sandbox
Para aprovechar al máximo el proceso DevOps de su organización, es muy importante configurar la estructura de sandbox. Antes de profundizar mucho más, analicemos los diferentes tipos de sandboxes que nos ofrece Salesforce.
Un sandbox es una copia casi exacta de los metadatos de producción de uno. Los entornos sandbox se utilizan normalmente con fines de desarrollo, prueba, puesta en escena y formación. Hay cuatro tipos de cajas de arena, y uno debe tener la debida consideración al elegir una caja de arena. ¡Los sandboxes de copia completa pueden costar mucho dinero!
A continuación se muestra la tabla de los límites aplicados por Salesforce para diferentes entornos sandbox.
Tabla 2: Comparación de límites
| Desarrollador | Desarrollador profesional | Copia parcial | Copia completa | |
|---|---|---|---|---|
| Datos de produccion | No | No | sí | sí |
| Almacenamiento de datos | 200 MB | 1GB | 5GB (10K registros por objeto) | Datos completos |
| Período de actualización | 1 día | 1 día | 5 días | 29 Día |
Podemos ver que el precio no es la única diferencia entre las cajas de arena.
El espacio aislado del desarrollador tiene un período de actualización de un día, lo que lo hace adecuado para el desarrollo, pero solo puede alojar 200 MB de datos y no datos de producción. Como polo opuesto, los entornos limitados de copia completa tienen una copia exacta de los datos de producción; incluso los ID de registro son los mismos. Eso podría hacerlo ideal para pruebas y pruebas, pero el período de actualización de 29 días dificulta obtener los últimos metadatos y datos de producción en el espacio aislado de copia completa.
La siguiente tabla actúa como regla general para seleccionar sandboxes:
Tabla 3: Casos de uso para la selección de Sandbox
| Desarrollador | Desarrollador profesional | Copia parcial | Copia completa | |
|---|---|---|---|---|
| Desarrollo | sí | sí | No | No |
| control de calidad | sí | sí | sí | No |
| Examen de integración | No | No | sí | sí |
| Prueba de datos por lotes | No | No | sí | sí |
| Capacitación | No | No | sí | sí |
| UAT | No | No | sí | sí |
| Prueba de carga | No | No | No | sí |
| Puesta en escena | No | No | No | sí |
| Entrenamiento de usuario | No | No | No | sí |
A continuación se muestra la estructura organizativa típica que se adopta para proyectos medianos. Para los clientes de nivel empresarial, la estructura organizativa se vuelve más compleja pero, en general, sigue el modelo que se muestra a continuación.
El desarrollo de Salesforce generalmente se realiza en la zona de pruebas del desarrollador (rojo) y los cambios se mueven a la zona de pruebas de integración (verde), que suele ser una zona de pruebas de desarrollo profesional o de copia parcial. Luego, los cambios de varios entornos limitados de integración se trasladan al entorno limitado de resumen (amarillo), que debería ser un entorno limitado de copia parcial.
Si su organización tiene integraciones con el sistema de terceros que necesitan pruebas de integración y pruebas de carga para realizarlas, es necesario tener un conjunto estable de datos que no cambie de una versión a otra. Por lo tanto, es mejor tener una copia completa o un sandbox de copia parcial para ello.
Luego, estos cambios se trasladan al entorno limitado de pruebas de integración, donde se realizan las pruebas. Luego, los cambios se mueven al entorno limitado provisional, que debería ser un entorno limitado de copia completa. Todas las clases de prueba se ejecutan antes de la implementación. Se debe realizar una validación de la implementación para asegurarse de que la implementación se realice sin problemas.
Este proceso nos ayuda a asegurarnos de que los cambios pasen por múltiples rondas de pruebas y pares de ojos. Viene con una gran desventaja de requerir mucho tiempo para desarrollar, probar e implementar cambios.
Muy a menudo, existe una necesidad urgente de realizar correcciones de errores o parches. Para manejarlos rápidamente, se debe mantener un espacio aislado para desarrolladores, que empujaría los parches pequeños directamente al espacio aislado de acumulación.
Como se mencionó anteriormente, un sandbox es una réplica casi exacta de los metadatos de producción, pero no completamente. Hay una lista oficial de componentes/características que están deshabilitadas en un sandbox.
Otra cosa a tener en cuenta al actualizar un sandbox es que solo copia los metadatos y datos de producción. No hay forma de copiar los metadatos de un sandbox a otro, o incluso de crear un sandbox vacío sin configuraciones de metadatos (como organizaciones de desarrolladores gratuitas). Esto a veces se convierte en un desafío en situaciones de la vida real. Salesforce tiene planes para solucionar este problema, y es posible que esta característica pronto esté disponible de forma general.
Además, si tiene algunos datos confidenciales en producción, a los que cree que su equipo de desarrollo o prueba no debería tener acceso, puede crear plantillas de sandbox para sandboxes total o parcialmente copiados.
Qué considerar al implementar
Hemos cubierto las prácticas de la industria de la gestión del ciclo de vida de las aplicaciones en el ecosistema de Salesforce. La administración de metadatos y sandbox juega un papel muy importante en la creación de paquetes de implementación y cargas útiles. Para aplicaciones grandes y complejas de Salesforce, el control de versiones ayuda a garantizar que se realice un seguimiento de los cambios de metadatos y, al mismo tiempo, ayuda a crear una estrategia de reversión.
La gestión de sandbox es fundamental para proyectos grandes o complejos. Pero los Sandboxes son costosos en el ecosistema de Salesforce, tanto en términos de recursos financieros como de tiempo. La formulación de una estrategia para la gestión de sandbox siempre es fundamental para el proceso de gestión de versiones.
Te dejamos con algunos puntos extra que sería bueno tener en cuenta durante tu próxima implementación:
- Solo se pueden implementar 10 000 archivos, o un archivo ZIP de 39 MB, de una sola vez. Naturalmente, si la carga útil es demasiado grande, debe dividir el paquete en varias partes y luego realizar la implementación.
- Si la implementación falla debido a un error de tiempo de
request timeout, intente eliminar objetos, campos personalizados y perfiles del paquete. Estos componentes tardan más en implementarse. - Si se cambia un tipo de campo, o ha habido cambios en la jerarquía de roles, podría haber grandes retrasos debido al recálculo de los datos, lo que requeriría algo de tiempo para completarse.
- Salesforce bloquea cualquier componente que un usuario esté utilizando actualmente en el sistema. Si intentamos implementar mientras ese es el caso, la implementación fallará.
Con suerte, esta descripción general lo ayudará durante su próximo lanzamiento de Salesforce.