Concebir una nueva fuente única de información
Objetivos de aprendizaje
Después de completar esta unidad, podrá:
- Describir en qué se diferencian los modelos para el desarrollo de organizaciones del desarrollo modular de paquetes.
- Enumerar las ventajas del desarrollo de paquetes.
- Describir las características principales de un paquete.
El mundo es una organización
Un famoso actor, o quizás fue un visionario de Salesforce, dijo una vez: "El mundo es una organización". Tradicionalmente, el centro de este mundo en concreto ha sido su organización de producción, y muchas de sus tareas de desarrollo han tenido lugar dentro de un sandbox o una organización de producción. Si es socio de AppExchange, su mundo es un poquito diferente. Sin embargo, las herramientas que se presentan en esta unidad también están a su disposición, así que siga leyendo.
Forma tradicional de gestionar el cambio
Si ha completado el módulo Modelo de desarrollo de organizaciones, es posible que recuerde a Calvin Green, el administrador de Zephyrus Relocation Services. La complejidad de la organización de producción ha crecido junto con Zephyrus. Para gestionar este crecimiento, Calvin ha comenzado a adoptar herramientas de desarrollo modernas de Salesforce para gestionar el ciclo de vida de las aplicaciones de su equipo.
Veamos cómo podría trabajar su equipo de desarrollo con el modelo de desarrollo de organizaciones.
Imagínese que es líder de desarrollo en una empresa de alta tecnología que avanza a un ritmo acelerado. Para la próxima publicación, necesita personalizar la aplicación básica de CRM y desarrollar una aplicación interna para la empresa. El primer paso de desarrollo es asegurarse de conseguir la instantánea más actualizada de la organización de producción. En el modelo basado en organizaciones, la organización de producción es la principal fuente de información para todo el código, la configuración y las personalizaciones.
Independientemente de lo que vaya a desarrollar, hay que crear implementaciones que vayan a encajar con la organización de producción. Como puede observar en el diagrama, aunque tenga varios equipos trabajando en proyectos de desarrollo distintos, estos desarrollan y publican sus actualizaciones con el mismo sistema. Todo se incluye en un archivo de tipo package.xml
.
Supongamos que trabaja en dos proyectos nuevos para la publicación de la primera versión:
(1) Proyecto |
(1) Desarrollo |
(2) API de metadatos (package.xml) |
---|---|---|
Extensiones/personalizaciones de CRM (primera versión) |
Objeto personalizado (agregar) Campo personalizado (agregar) Formato de página (agregar) Flujo de trabajo (agregar) |
Clase de Apex: 1 Página de Visualforce: 1 Objeto personalizado: 2 Campo personalizado: 2 Formato de página: 1 Flujo de trabajo: 1 |
Aplicación Time Off Manager (primera versión) |
Objeto personalizado (agregar) Campo personalizado (agregar) Clase de Apex (agregar) Página de Visualforce (agregar) |
(3) Se publica todo junto en la organización de producción. |
En la segunda versión, se centra en realizar algunos cambios menores. Sin embargo, sigue publicando e implementando ambos proyectos a la vez en la organización de producción:
(1) Proyecto |
(1) Desarrollo |
(2) API de metadatos (package.xml) |
---|---|---|
Extensiones/personalizaciones de CRM (primera versión) |
Objeto personalizado (actualizar) Flujo de trabajo (actualizar) |
Página de Visualforce: 1 Objeto personalizado: 2 Flujo de trabajo: 1 |
Aplicación Time Off Manager (primera versión) |
Objeto personalizado (actualizar) Página de Visualforce (actualizar) |
(3) Se publica todo junto en la organización de producción. |
Los desarrolladores y gestores de publicación ven la organización como un conjunto entremezclado de código y personalizaciones. Para volver al inicio, vuelva a mirar el diagrama. La implementación final no se centra únicamente en la aplicación Time Off Manager o las extensiones de CRM, sino que incluye todos los cambios de la organización.
A medida que desarrolla, tiene que controlar los cambios para asegurarse de que sabe qué es necesario implementar en la organización de producción. Los cambios se entremezclan con lo que los demás han cambiado, así que este proceso puede ser complejo y, de algún modo, manual. Si utiliza un sistema de control de código fuente en este proceso, se reflejará en este la misma sensación de código y personalizaciones entremezclados. El repositorio del código fuente se alinea con la organización y no solo con una parte (por ejemplo, la aplicación Time Off Manager).
Pero, ¿qué ocurre si se da cuenta de que esta mezcla es demasiado compleja y necesita una mejor forma de gestionar el cambio? ¿Quiere seguir un modelo de desarrollo más tradicional para entregar y publicar aplicaciones y soluciones?
Gestionar el cambio mediante el desarrollo de paquetes
A medida Zephyrus sigue creciendo, sus publicaciones de versiones son cada vez más complejos. Al tener múltiples equipos de desarrollo y administradores de Salesforce, Calvin quería encontrar la forma de desacoplar proyectos de ese enorme tren de publicación de versiones. El modelo de desarrollo de paquetes permite optimizar todo el ciclo de vida de desarrollo, y presenta ventajas como las siguientes:
- Mejora del desarrollo y la colaboración en equipo.
- Proceso de desarrollo en módulos con la especificación de las dependencias entre paquetes.
- Sistema de control de versiones para gestionar el cambio.
- Posibilidad de hacer pruebas automáticas y disfrutar de una integración continua.
- Ciclo de publicación de versiones más ágil y eficiente.
- Sincronización mejorada del sistema de control de versiones (VCS) gracias al seguimiento de los cambios en las funciones de configuración.
- Mayor visibilidad y claridad de la gestión de cambios en la organización de producción.
¿Qué significa todo esto? En lugar de desarrollar código y personalizaciones para la organización, crea un paquete (un conjunto lógico de código). Un paquete es un artefacto de publicación que es un conjunto de código y personalizaciones que guardan relación.
El grupo de componentes dentro de un paquete puede representar muchas cosas. El paquete puede ser un conjunto de personalizaciones creadas para ayudar a un equipo de ventas. Puede estar formado por componentes Lightning, objetos y flujos de trabajo para una aplicación que se va a desarrollar en la organización. También puede estar formado por las extensiones que desarrolla en torno a un paquete gestionado que ha instalado desde AppExchange.
Con este nuevo proceso, podrá estructurar la organización en un conjunto de paquetes. Al organizar el código fuente y los metadatos en paquetes, podrá comprender más fácilmente las relaciones que hay entre los componentes de metadatos de su organización. Cuanto más crezca la organización, más importante se vuelve este proceso, así que es fundamental planificarlo con antelación y estar siempre pensando en cómo estructurar la organización.
Un VCS es el mejor amigo de un desarrollador y juega un papel fundamental en el ciclo de vida de desarrollo de paquetes. Todo el código fuente de los paquetes se almacena en un repositorio de control del código fuente, donde se conserva la única fuente de información válida. A partir de ese código fuente, se crean organizaciones (de desarrollo) de cero para trabajar específicamente en su paquete. Ofrecemos también funciones de seguimiento de cambios para supervisar lo que ha creado, actualizado y eliminado en la organización de desarrollo. Puede extraer fácilmente el código fuente modificado en su sistema de archivos y comprobarlo en el VCS.
El desarrollo de paquetes ofrece más flexibilidad a la hora de gestionar equipos y publicaciones de versiones. Puede asignar equipos a un paquete concreto. Los equipos de desarrollo podrán desarrollar de forma independiente y trabajar en la publicación de ese paquete, y no en la publicación de actualizaciones para la organización. Con este modelo ágil, podrá hacer publicaciones independientes con más frecuencia, tal y como puede ver en el flujo de desarrollo, creación e implementación.
Tenemos un tipo especial de paquete para nuestros clientes empresariales al que llamamos paquete desbloqueado, y que es especialmente útil para aplicaciones empresariales internas.
Por qué los paquetes desbloqueados ofrecen flexibilidad
Veamos por qué los paquetes desbloqueados pueden cambiar la forma en que publicamos la personalización del sistema de CRM y la aplicación Time Off Manager.
En este ejemplo, para el primer lanzamiento, va a crear dos proyectos nuevos. Los dos están en la versión 1.0 y se pueden crear y luego implementar en la organización de producción de forma independiente desde la API de metadatos.
(1) Desarrollo |
(2) Creación |
(3) Publicación (package.xml) |
---|---|---|
Extensiones/personalizaciones de CRM (versión 1.0) |
Objeto personalizado (agregar) Campo personalizado (agregar) Formato de página (agregar) Flujo de trabajo (agregar) |
Objeto personalizado: 1 Campo personalizado: 1 Formato de página: 1 Flujo de trabajo: 1 |
Aplicación Time Off Manager (versión 1.0) |
Objeto personalizado (agregar) Campo personalizado (agregar) Clase de Apex (agregar) Página de Apex (agregar) |
Clase de Apex: 1 Página de Apex: 1 Objeto personalizado: 1 Campo personalizado: 1 |
Para la siguiente publicación, puede crear e implementar de nuevo cada versión del paquete de forma independiente en la organización de producción. De esta manera, podrá mantener versiones distintas de cada artefacto de publicación (paquete).
(4) Desarrollo |
(5) Creación |
(6) Publicación (package.xml) |
---|---|---|
Extensiones/personalizaciones de CRM (versión 1.1) |
Objeto personalizado (actualizar) Flujo de trabajo (actualizar) |
Objeto personalizado: 1 Campo personalizado (sin cambios) Formato de página (sin cambios) Flujo de trabajo: 1 |
Aplicación Time Off Manager (versión 2.0) |
Objeto personalizado (actualizar) Página de Apex (actualizar) |
Clase de Apex (sin cambios) Página de Apex: 1 Objeto personalizado: 1 Campo personalizado (sin cambios) |
Este proceso también se aplica a CI y CD. El desarrollo de paquetes permite crear planes de pruebas diseñados específicamente para el proyecto. Puede automatizar el plan de pruebas para asegurar un nivel continuo de calidad mediante la ejecución de pruebas a través de múltiples entornos a medida que se modifica el código fuente desde el VCS.
Recursos
- Guía del desarrollador: Referencia de comandos de Salesforce CLI
- Guía del desarrollador: Guía del desarrollador de Salesforce DX
- Trailhead: Inicio rápido: Salesforce DX
- Trailhead: Unlocked Packages for Customers (Paquetes desbloqueados para clientes)