Empiece a realizar un seguimiento de su progreso
Inicio de Trailhead
Inicio de Trailhead

Planificar los cambios para su organización

Objetivos de aprendizaje

Después de completar esta unidad, podrá:
  • Identificar qué entorno de desarrollo utilizar en cada paso de ALM al trabajar en el modelo de desarrollo de conjuntos de cambios.
  • Crear un nuevo entorno sandbox.
  • Establecer un método para realizar un seguimiento de los cambios que se hicieron en una versión.

Introducción

Si completó el módulo Modelos de desarrollo y ciclo de vida de aplicación (si no lo hizo, recomendamos trabajarlo antes de leer este módulo), ya conoció a Calvin Green, de Zephyrus Relocation Services. En este módulo, el equipo de Zephyrus utiliza el desarrollo de conjuntos de cambios declarativos para ofrecer una de sus personalizaciones de Salesforce.

Calvin en su escritorio en Zephyrus, con una taza de café de Vetforce.

Zephyrus quiere ofrecer servicios de capacitación de idiomas a clientes que se mueven por todo el mundo. El equipo de capacitación de la compañía incluye ahora especialistas de idiomas que están desarrollando una gran variedad de tipos de cursos. Algunos clientes están empezando a aprender un nuevo idioma. Otros solo necesitan un curso para refrescar conocimientos. Otros buscan aprender un vocabulario especializado, posiblemente para su trabajo. Hay muchos factores que tener en cuenta al recomendar un curso de idiomas a un cliente.

Calvin y su equipo deciden utilizar el desarrollo de conjunto de cambios para incluir información de cursos de idiomas en su organización.

El ciclo de ALM: Planificar la versión, desarrollar, probar, crear la versión, probar la versión, publicar la versión

Anotar sus planes de lanzamiento de versión

Calvin pone por escrito sus planes de lanzamiento de versión para que las partes interesadas sepan lo que está ocurriendo, de forma que haya menos posibilidad de confusión. También observa que, a menudo, tomar notas suele sacar a la luz problemas que antes no se detectaban. Las asignaciones, los planes de pruebas, las decisiones y los eventos clave son más fáciles de evaluar de manera concreta que de forma abstracta. Y Calvin sabe que nada se graba en piedra: espera revisar el plan durante toda la versión a medida que la nueva información vaya estando disponible.

Preparar los entornos de la versión

Cuando planifique una versión, asegúrese de que los participantes en su versión pueden tener acceso a los entornos necesarios en cada paso del proceso ALM. Calvin y su equipo están utilizando el modelo de desarrollo de conjuntos de cambios, por lo que utilizan entornos sandbox optimizados para las tareas en cada paso de ALM. Recuerde: un entorno sandbox es únicamente una copia de su organización de producción en un entorno independiente. Algunos entornos sandbox no contienen datos de producción, mientras que otros contienen diversas cantidades. Así es como el equipo de Calvin utiliza los entornos sandbox en cada paso de ALM.
  • Pasos de desarrollo y prueba: Cada miembro del equipo tiene su propio sandbox de Developer para crear su personalización asignada. Los entornos sandbox de Developer no contienen datos de producción.
  • Crear la versión: Cada miembro del equipo migra sus personalizaciones desde sus sandbox de Developer correspondientes a un sandbox compartido de Developer Pro para realizar la integración. Los entornos sandbox de Developer Pro no contienen datos de producción, pero puede propagarlos con datos de prueba.
  • Probar la versión: Para la prueba de aceptación del usuario, el equipo utiliza un entorno sandbox completo para crear una réplica completa de producción. Un sandbox completo incluye los datos de producción.
  • Publicar la versión: Una vez que la versión esté en producción, el equipo puede utilizar el entorno sandbox completo que creó en el último paso para capacitar a los usuarios sin exponer los datos de producción.

Los pasos del ciclo de la aplicación son: desarrollar y probar con entornos sandbox Developer, crear la versión con un entorno sandbox Developer Pro, probar la versión con un entorno sandbox completo y publicar la versión en producción.

Crear los entornos

Calvin crea dos entornos sandbox Developer para comenzar: uno para sí mismo y otro para su colega, Ella. En estos entornos sandbox, Calvin y Ella crean y prueban sus correspondientes personalizaciones. Al crear un entorno sandbox para cada desarrollador, Calvin mantiene los cambios aislados hasta que el equipo esté listo para integrarlos.

Los entornos sandbox están disponibles en Professional Edition, Enterprise Edition, Unlimited Edition y Performance Edition. Calvin muestra a Ella cómo crear un entorno sandbox.

  1. En Configuración, ingrese Sandboxes en el cuadro Búsqueda rápida y, a continuación, seleccione Sandboxes.
  2. Haga clic en Nuevo Sandbox.
  3. Ingrese un nombre y una descripción para el entorno sandbox.
  4. Seleccione Developer para el tipo de sandbox.
  5. Haga clic en Iniciar copia.

La creación de la copia puede tardar un rato, especialmente si su organización de producción tiene muchos datos o personalizaciones. Calvin obtiene un email de notificación cuando el nuevo sandbox ha finalizado la copia.

Calvin hace lo mismo para crear un sandbox de Developer Pro para la integración y un sandbox completo para la prueba de aceptación del usuario y la capacitación del usuario.

Establecer su método de seguimiento de cambios

Al utilizar el modelo de desarrollo de conjunto de cambios, es importante realizar un seguimiento de cada cambio, especialmente de los cambios que requieren migración manual. Cuando se migra manualmente un cambio, realiza modificaciones de un entorno y vuelve a crearlas exactamente en otro entorno. Tiene que migrar manualmente un cambio si el componente que se modificó no es aún compatible con la API de metadatos.

¿Cómo sabe Calvin qué componentes son compatibles en la API de metadatos? El reporte Cobertura de metadatos le muestra qué tipos de metadatos son compatibles en la API de metadatos y otros canales de metadatos. Este reporte generado de forma dinámica es su mejor fuente para la información de cobertura de metadatos. Para acceder al reporte Cobertura de metadatos, vaya a https://developer.salesforce.com/docs/metadata-coverage.

Calvin realiza un seguimiento de todos los cambios y mejoras que solicitó el equipo de ventas. Utiliza una herramienta personalizada que permite a los desarrolladores registrar cada cambio que realicen. Para mayor seguridad, Calvin comprueba que la herramienta tiene campos para información especial sobre cada cambio en una versión, así como para los cambios que se realizan directamente en producción.

  • ¿A quién se le asigna el cambio?
  • ¿Requiere este cambio migración manual?
  • ¿Qué componente se ve afectado por este cambio?
  • ¿Qué organizaciones tienen el cambio actualmente?
  • ¿Cuándo se hizo el cambio en cada entorno?

¿Por qué realiza Calvin un seguimiento de los cambios que se realizaron en producción cuando estos no forman parte de una versión en desarrollo? Es la única forma que tiene de asegurarse de que las personalizaciones implementadas no se sobrescribirán ni cambiarán de forma inesperada el comportamiento de la organización de producción.

Prácticamente todos los cambios que hagan Calvin o Ella con la interfaz de usuario de Salesforce se registran en el seguimiento de auditoría de configuración. Calvin realiza una comprobación cruzada del registro de auditoría con el reporte en la herramienta de seguimiento de cambios del equipo para que no se pierda ningún cambio.

Para obtener más información acerca del uso del seguimiento de auditoría de configuración, consulte Monitorear los cambios de configuración en la Ayuda de Salesforce.