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

Utilizar el desarrollo de paquetes para obtener versiones más flexibles

Objetivos de aprendizaje

Después de completar esta unidad, podrá:
  • Identificar las principales diferencias entre el desarrollo de paquetes y el desarrollo de conjuntos de cambios.
  • Describir en qué consiste una versión de paquete y cómo ayuda a gestionar los cambios en su organización.
  • Resumir por qué no tiene que realizar manualmente el seguimiento de los cambios de configuración al utilizar el modelo de desarrollo de paquetes.

Esta unidad describe por qué Calvin y sus colegas deciden cambiar de los modelos de desarrollo de conjuntos de cambios al desarrollo de paquetes. Otros equipos pueden encontrar interesantes distintos aspectos del desarrollo de paquetes. Conforme avance en esta unidad, considere los cambios que haría para su equipo, así como los aspectos del desarrollo de paquetes que le resultan más interesantes. Al final de este módulo, realizaremos ejercicios prácticos para que pueda aprender el proceso y tomar las decisiones más fundamentadas y que mejor se adapten a su caso.

Desafíos de gestión de cambios de los conjuntos de cambios

En Zephyrus, el número de proyectos y colaboradores de cada versión de la organización de producción no para de aumentar. Esto es muy bueno para los usuarios. La aplicación consistente de la compañía de los pasos de ALM optimiza la implementación de las solicitudes de mejora y minimiza las interrupciones.

Coordinar todos los cambios sin relación alguna entre sí y de tantos equipos distintos se está convirtiendo en un problema para Calvin. Las versiones son cada vez mayores y más complejas. Una de las preocupaciones de Calvin es que la dificultad que implica agregar y probar los cambios para todos los proyectos de cada versión repercuta en funciones de las que depende la plantilla de Zephyrus.

Con tantos cambios que coordinar y seguir en cada versión, Calvin se da cuenta de que sería preferible dedicar el tiempo a hacer los cambios. También cree que los equipos que se dedican a personalizar Salesforce en Zephyrus podrían ser más productivos si dedicaran menos tiempo a coordinar los cambios con los de otros proyectos.

¿Contenedor único o varios contenedores?

En Salesforce Trailblazer Community, Calvin pide a los demás miembros consejo acerca de cómo gestionar tantos proyectos en cada versión. Estos le informan de la existencia de un nuevo modelo de desarrollo de Salesforce que ofrece mayor flexibilidad para la gestión de versiones. Dicho modelo se denomina desarrollo de paquetes.

En el desarrollo de paquetes, las distintas personalizaciones se gestionan como paquetes separados, no como una única versión de cambios para la organización. ¿Recuerda que en el desarrollo de conjuntos de cambios la gestión de conjuntos de cambios de varios proyectos se realizaba como si fuesen a un único contenedor? Cuando las versiones son tan complejos que requieren gestionar la organización como varios contenedores, es el momento de cambiar al modelo de desarrollo de paquetes. Si su equipo ya compila artefactos de la versión modulares en otras plataformas, se dará cuenta de que existen similitudes con respecto al trabajo con el desarrollo de paquetes.

Por ejemplo, es posible que un paquete de Zephyrus contenga algunas de las personalizaciones que se indican a continuación.

  • Aplicaciones de Force.com personalizadas que se crearon internamente.
  • Extensiones de Sales Cloud, Service Cloud, etc.
  • Extensiones de una aplicación de AppExchange.
  • Actualizaciones de las funciones y las bibliotecas compartidas.

Cuando se trabaja en un modelo de desarrollo de paquetes, se compila un artefacto de la versión que puede probar y lanzar de manera independiente a los artefactos de otros proyectos. En lugar de un conjunto de cambios relacionado con la producción, su equipo crea un paquete que contiene todos los metadatos relevantes. Los metadatos del paquete incluyen componentes que se cambiaron y que no se cambiaron.

La organización de actualizaciones de metadatos por paquetes también le ayuda a crear un mejor modelo mental de la estructuración de los metadatos de su organización. Si desea gestionar su organización como varios contenedores, cada paquete representará a uno de dichos contenedores.

Una versión de paquete es una instantánea fija del contenido del paquete y de los metadatos relacionados. La versión del paquete le permite gestionar las diferencias existentes cada vez que se lanza o implementa un conjunto de cambios específico que se agrega a un paquete. Si introduce cambios de metadatos en un paquete que ya se implementó, debe actualizar la versión del paquete actual a la versión de paquete más reciente.

Calvin está entusiasmado con el incremento de productividad que reporta el cambio al desarrollo de paquetes. Por ello le muestra el caso a Ernesto, el director general, y a los directores de otros departamentos responsables de la creación de personalizaciones de Salesforce. Calvin se centra en tres puntos principales.

  • Creación de un seguimiento de auditoría claro del cambio que sufren los metadatos con el tiempo.
  • Aumento de la productividad al no tener que invertir tiempo en el seguimiento de los cambios de configuración.
  • Incremento de la flexibilidad en el lanzamiento de versiones, ya que cada paquete se puede desarrollar, probar y lanzar de manera independiente a los paquetes de otros proyectos.

Su origen de confianza son los metadatos de origen

En el desarrollo de paquetes, su origen de confianza son los metadatos de su proyecto de paquete. Esto facilita la integración en un VCS y puede ayudar a su equipo a gestionar los cambios de proyecto que realicen.

En el desarrollo de conjuntos de cambios, el origen de confianza es una combinación de los metadatos presentes en el entorno y en la última compilación del conjunto de cambios. Por sí mismo, un conjunto de cambios no puede mostrar una imagen completa, puesto solo incluye el contenido que se cambió, es decir, las diferencias.

Despídase del seguimiento manual de los cambios de configuración

En el desarrollo de paquetes encontrará un entorno de desarrollo denominado organizaciones borrador. Las organizaciones borrador desempeñan una función importante para reducir los cambios cuyo seguimiento deben realizar Calvin y su equipo en cada versión.

Las organizaciones borrador son organizaciones vacías (sin metadatos ni datos) fáciles de crear y eliminar según las necesidades. Puede configurar organizaciones borrador con distintas versiones de Salesforce y diferentes funciones y preferencias. Es más, puede volver a utilizar el archivo de definición de organización borrador con otros miembros del equipo, ya que forma parte del proyecto integrado en VCS. De este modo, le resultará más sencillo a todo su equipo trabajar con la misma configuración de organización pese a que cada miembro tendrá su propio entorno de desarrollo.

Cuando utilice organizaciones borrador para el desarrollo, primero debe enviar el origen de su proyecto en VCS para sincronizar la organización borrador con los mismos metadatos. Si planea utilizar la configuración para el desarrollo, se realizará un seguimiento automático de todos los cambios que realice. Puede desglosar las modificaciones que realice, incluirlas en su proyecto y utilizar su VCS para confirmar todos los cambios.

Sugerencia

Sugerencia

¿Cómo sabe Calvin qué componentes son compatibles con el seguimiento de origen? El reporte Cobertura de metadatos le muestra los tipos de metadatos que son compatibles con el seguimiento de origen, 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.

Cada paquete tiene su propio ritmo

En el desarrollo de paquetes, puede seguir distintas programaciones de lanzamiento para cada paquete. Los paquetes se utilizan para segmentar la propiedad de los metadatos de la organización. De este modo, cada proyecto tiene su propio paquete además de paquetes dependientes. Es posible gestionar la actualización de segmentos individuales de manera independiente en cada versión de paquete posterior, lo que le permite mantener programaciones de lanzamiento separadas.

¿Qué es la dependencia de paquete? Un componente de metadatos solo puede estar en un paquete al mismo tiempo.me. Si más de un paquete necesita el mismo componente, puede diseñar una estrategia de paquete modular para dicho componente. Un paquete que contiene uno o varios componentes de metadatos compartidos por varios paquetes es una dependencia de paquete.

Cada paquete (junto con las dependencias de paquete) puede probarse de manera aislada al resto de metadatos de la organización. El aislamiento de metadatos en paquetes es lo que le ofrece la flexibilidad para crear versiones de estos conjuntos de metadatos (paquetes) de forma independiente. Esto también le ofrece la flexibilidad suficiente para lanzar los paquetes de manera independiente.

¿Qué es lo siguiente?

Cada uno de los tres modelos de desarrollo tiene su propio módulo en Trailhead. Con cada módulo aprenderá a crear personalizaciones para Salesforce utilizando dicho modelo de desarrollo.