Compartir a través de

Componentes de código de Administración del ciclo de vida de la aplicación (ALM)

  • Artículo

ALM es un término que se utiliza para describir la gestión del ciclo de vida de las aplicaciones de software, que incluye desarrollo, mantenimiento y gobernanza. Más información: Administración del ciclo de vida de la aplicación (ALM) con Microsoft Power Platform.

Este artículo describe las consideraciones y estrategias para trabajar con aspectos específicos de administración del ciclo de vida desde la perspectiva de los componentes de código en Microsoft Dataverse:

  1. Consideraciones de desarrollo y depuración de ALM

  2. Estrategias de solución de componentes de código

  3. Implementar versiones y actualizaciones

  4. Consideraciones de ALM de aplicaciones de lienzo

Consideraciones de desarrollo y depuración de ALM

Al desarrollar componentes de código, seguiría los pasos que se mencionan a continuación:

  1. Crear proyecto de componente de código (pcfproj) desde una plantilla usando pac pcf init. Más información: Crear y compilar un componente de código.
  2. Implementar lógica del componente de código. Más información: Implementar un componente.
  3. Depura el componente de código utilizando el arnés de prueba local. Más información: Depurar componentes de código.
  4. Cree un proyecto de solución (cdsproj) y agregue el proyecto del componente de código como referencia. Más información: Empaquetar un componente de código
  5. Construya el componente de código en modo versión para distribución e implementación.

Cuando su componente de código esté listo para probarse dentro de una aplicación basada en modelo, una aplicación de lienzo o un portal, hay dos formas de implementar un componente de código para Dataverse:

  1. pac pcf push: esto implementa un único componente de código a la vez en una solución especificada por el parámetro --solution-unique-name , o una solución PowerAppsTools temporal cuando no se especifica ninguna solución.

  2. Usar pac solution init y msbuild para crear un proyecto de solución cdsproj que tiene referencias a uno o más componentes de código. Cada componente de código se agrega al cdsproj utilizando pac solution add-reference. Un proyecto de solución puede contener referencias a varios componentes de código, mientras que los proyectos de componentes de código solo pueden contener un único componente de código.

    El siguiente diagrama muestra la relación uno a varios entre proyectos cdsproj y pcfproj:

    Relación uno a varios entre los proyectos de cdsproj y pcfproj.

Más información: Empaquetar un componente de código

Creación de proyectos de componentes de código pcfproj

Al crear proyectos pcfproj, el JavaScript generado depende del comando utilizado para crear y el PcfBuildMode en el archivo pcfproj.

Normalmente no tendrá que implementar un componente de código en Microsoft Dataverse que se ha creado en modo de desarrollo, ya que a menudo es demasiado grande para importar y puede resultar en un rendimiento en tiempo de ejecución más lento. Más información: Depuración después de implementar en Microsoft Dataverse.

Para que pac pcf push dé como resultado una versión de lanzamiento, PcfBuildMode se establece dentro del pcfproj agregando un nuevo elemento debajo del elemento OutputPath de la siguiente manera:

<PropertyGroup>
   <Name>my-control</Name>
   <ProjectGuid>6aaf0d27-ec8b-471e-9ed4-7b3bbc35bbab</ProjectGuid>
   <OutputPath>$(MSBuildThisFileDirectory)out\controls</OutputPath>
   <PcfBuildMode>production</PcfBuildMode>
</PropertyGroup>

La siguiente tabla muestra qué comandos dan como resultado versiones de desarrollo frente a versiones de lanzamiento:

Comando de compilación usado en pcfproj Compilación de desarrollo
(solo con fines de depuración)		 Compilación de versión
npm start watch Siempre
pac pcf push Comportamiento predeterminado o cuando PcfBuildMode se establece en desarrollo en el archivo pcfproj PcfBuildMode se establece en producción en el archivo pcfproj
npm run build Comportamiento predeterminado npm run build -- --buildMode production

Más información: Empaquetar un componente de código

Creación de proyectos de solución .cdsproj

Al crearr un proyecto de solución (.cdsproj), tiene la opción de generar la salida como solución administrada o no administrada. Las soluciones administradas se utilizan para la implementación en cualquier entorno que no sea un entorno de desarrollo para esa solución. Esto incluye los entornos de pruebas, de pruebas de aceptación de usuario (UAT), SIT y de producción. Más información: Soluciones administradas y no administradas.

El SolutionPackagerType está incluido en el archivo .cdsproj creado por pac solution init, pero inicialmente con marcas de comentado. Quite las marcas de comentario de la sección y configure en Administrado, No administrado o Ambas cosas.

 <!-- Solution Packager overrides, un-comment to use: SolutionPackagerType (Managed, Unmanaged, Both) -->
 <PropertyGroup>
    <SolutionPackageType>Managed</SolutionPackageType>
 </PropertyGroup>

La siguiente tabla muestra qué comando y configuración dan como resultado versiones de desarrollo frente a versiones de lanzamiento:

Comando de compilación usado en cdsproj SolutionPackageType Salida
msbuild Administrado Compilación de Desarrollo en Solución Administrada
msbuild /p:configuration=Release Administrado Compilación de Versión en Solución Administrada
msbuild No administrada Compilación de Desarrollo en Solución No administrada
msbuild /p:configuration=Release No administrada Compilación de Versión en Solución No administrada

Más información: Empaquetar un componente de código

Control de código fuente con componentes de código

Al desarrollar componentes de código, se recomienda que utilice un proveedor de control de código fuente, como Azure DevOps o GitHub. Al realizar cambios usando el control de fuente git, el archivo .gitignore proporcionado por la plantilla pac pcf init garantizará que algunos archivos no se agreguen al control de código de origen, ya que los restaura npm o se generan como parte del proceso de creación:

# <a name="dependencies"></a>dependencies
/node_modules

# <a name="generated-directory"></a>generated directory
**/generated

# <a name="output-directory"></a>output directory
/out

# <a name="msbuild-output-directories"></a>msbuild output directories
/bin
/obj

Dado que la carpeta /out se excluye, el archivo resultante bundle.js (y los recursos relacionados) creados no se agregarán al control de código fuente. Cuando los componentes de su código se compilan manualmente o como parte de una canalización de compilación automatizada,bundle.js se compilaría utilizando el código más reciente para garantizar que se incluyan todos los cambios.

Además, cuando se crea una solución, los archivos zip de la solución de asociación no se enviarán al control de código fuente. En cambio, la salida se publicaría como artefactos de liberación binaria.

Uso de SolutionPackager con componentes de código

Además de la fuente que controla pcfproj y cdsproj, Solution Packager se puede utilizar para descomprimir gradualmente una solución en sus partes respectivas como una serie de archivos XML que se pueden enviar al control de código fuente. Esto tiene la ventaja de crear una imagen completa de sus metadatos en el formato legible por personas, para que pueda realizar un seguimiento de los cambios utilizando Solicitudes de extracción o similares. Cada vez que se realiza un cambio en los metadatos de la solución del entorno, Solution Packager se utiliza para descomprimir y los cambios se pueden ver como un conjunto de cambios.

Nota

En este momento, SolutionPackager difiere de usar pac solution clone en que se puede utilizar de forma incremental para exportar cambios desde una solución Dataverse.

Si está combinando componentes de código con otros elementos de la solución, como tablas, aplicaciones controladas por modelos y aplicaciones de lienzo, normalmente no necesitaría la creación del proyecto cdsproj. En su lugar, movería los artefactos creados desde pcfproj a la carpeta del paquete de la solución antes de volver a empaquetarlo para su importación.

Una vez que se desempaqueta una solución que contiene un componente de código usando SolutionPackager /action: Extract, se verá similar a:

.
├── Controls
│   └── prefix_namespace.ControlName
│       ├── bundle.js *
│       └── css
│          └── ControlName.css *
│       ├── ControlManifest.xml *
│       └── ControlManifest.xml.data.xml
├── Entities
│   └── Contact
│       ├── FormXml
│       │   └── main
│       │       └── {3d60f361-84c5-eb11-bacc-000d3a9d0f1d}.xml
│       ├── Entity.xml
│       └── RibbonDiff.xml
└── Other
    ├── Customizations.xml
    └── Solution.xml

En la carpeta Controls, puede ver que hay subcarpetas para cada componente de código incluido en la solución. Las otras carpetas contienen componentes de solución adicionales agregados a la solución.

Al enviar esta estructura de carpetas al control de origen, excluiría los archivos marcados con un asterisco (*) arriba, porque se mostrarán cuando el proyecto pcfproj está construido para el componente correspondiente.

Los únicos archivos que se requieren son los archivos *.data.xml, ya que contienen metadatos que describen los recursos requeridos por el proceso de empaquetado. Después de que se crea cada componente de código, los archivos en la carpeta out se copian en la carpeta de control respectiva en las carpetas de SolutionPackager. Una vez que se han agregado los resultados de la compilación, las carpetas del paquete contienen todos los datos necesarios para volver a empaquetar en una solución Dataverse usando SolutionPackager /action: Pack.

Más información: Argumentos de la línea de comandos de SolutionPackager.

Estrategias de solución de componentes de código

Los componentes de código se implementan en entornos posteriores utilizando soluciones Dataverse. Una vez implementados en su entorno de desarrollo, se pueden implementar de la misma manera que otros componentes de la solución. Más información: Conceptos de solución - Power Platform.

Hay dos estrategias para implementar componentes de código dentro de las soluciones:

  1. Soluciones segmentadas: se crea un proyecto de solución utilizando pac solution init y luego usando pac solution add-reference para agregar uno o más componentes de código. Luego, esta solución se puede exportar e importar a entornos posteriores y otras soluciones segmentadas dependerán de la solución del componente de código, por lo que primero debe implementarse en ese entorno. Esto se refiere a una segmentación de la solución, porque la funcionalidad general se divide entre diferentes segmentos y capas de la solución y el marco de la solución realiza un seguimiento de las interdependencias. Si utiliza este enfoque, es probable que necesite varios entornos de desarrollo, uno para cada solución segmentada. Más información: Usar soluciones segmentadas en Power Apps.

  2. Solución única: se crea una única solución dentro de un entorno Dataverse y luego los componentes de código se agregan junto con otros componentes de la solución (como tablas, aplicaciones controladas por modelos o de lienzo) que, a su vez, hacen referencia a esos componentes de código. Esta solución se puede exportar e importar a entornos posteriores sin dependencias entre soluciones. Con este enfoque, la ramificación de código y entorno se vuelve importante para que pueda implementar una actualización en una parte de la solución sin tomar los cambios que se están realizando en otra área. Más información: Rama y estrategia de fusión con Microsoft Power Platform.

Las razones para adoptar un enfoque de solución segmentada en lugar de un enfoque de solución única mixta podrían ser:

  1. Ciclo de vida del control de versiones: desea desarrollar, implementar y controlar la versión de sus componentes de código en un ciclo de vida separado de las otras partes de su solución. Este es un escenario común en el que tiene un 'equipo de fusión', donde los fabricantes de aplicaciones están consumiendo componentes de código creados por desarrolladores. Normalmente, esto también significaría que los componentes de su código existirían en un repositorio de código diferente al de otros componentes de la solución.

  2. Uso compartido: desea compartir sus componentes de código entre múltiples entornos y, por lo tanto, no desea acoplar sus componentes de código con ningún otro componente de la solución. Esto podría ser si es un ISV o si está desarrollando un componente de código para que lo utilicen diferentes partes de su organización, cada una de las cuales tiene su propio entorno.

El siguiente diagrama muestra una descripción general del ciclo de vida de la solución para estos dos enfoques:

Estrategias de la solución.

El diagrama describe los puntos siguientes:

  1. Insertar usando PAC CLI: cuando el componente de código está listo para probarse dentro de Dataverse, pac pcf push se utiliza para implementar en un entorno de desarrollo. Esto crea una solución no administrada llamada PowerAppsTools_namespace, dónde espacio de nombres es el prefijo de espacio de nombres del proveedor de soluciones con el que implementar su componente de código. El proveedor de la solución ya debería existir en el entorno de destino y debe tener el mismo prefijo de espacio de nombres que desea utilizar para los entornos posteriores. Después de la implementación, puede agregar su componente de código a las aplicaciones de lienzo o basadas en modelos para realizar pruebas.

    Nota

    Como se describe anteriormente, es importante configurar el componente de código cdsproj para la compilación de producción, de modo que implemente el código optimizado para producción en lugar de para desarrollo.

  2. Agregar componentes de código existentes (después de la implementación de la CLI de PAC): si está utilizando el enfoque de solución única, una vez implementado, el componente de código se puede agregar a otra solución. (Esa solución debe compartir el mismo editor de soluciones que usa la solución PowerAppsTools.)

    Agregar existente.

  3. Crear un proyecto de solución no administrada: si está usando proyectos de la solución cdsproj, luego se puede construir una solución no administrada usando msbuild y despues importarla a su entorno de desarrollo.

  4. Agregar componentes de código existentes (después de la implementación del proyecto de la solución): de la misma manera que, después de pac pcf push, los componentes de código que se importan desde la creación de un proyecto de solución se pueden agregar a una solución mixta, siempre que se use el mismo prefijo de editor de soluciones.

  5. Exportar solución única como administrada: la solución de un solo componente mixto se puede exportar como administrada e importar a los entornos posteriores. Dado que los componentes de código y otros componentes de la solución se implementan en la misma solución, todos comparten la misma solución y estrategia de control de versiones.

  6. Exportar la solución segmentada de componentes de código como administrada: si está utilizando el enfoque de solución segmentada, puede exportar su proyecto de solución de componente de código como administrado a entornos posteriores.

  7. Construir una solución segmentada de componentes de código como administrada: si está usando soluciones segmentadas y no necesita una solución no administrada, puede construir el proyecto de la solución directamente como solución administrada usando msbuild /p:configuration=Release. Esto luego se puede importar a entornos que necesitan depender de sus componentes de código.

  8. Consumir solución de componente de código segmentado: una vez que los componentes de código se implementan a través de una solución segmentada administrada, se pueden construir otras soluciones, dependiendo de la solución del componente de código. Las dependencias de los componentes del código se enumerarán en la solución MissingDependencies sección de tipo 66. Más información: Seguimiento de las dependencias de los componentes de la solución.

  9. Implementar una solución segmentada de componentes de código antes que las soluciones que la usan: al importar soluciones que dependen de una solución de componente de código segmentado, la solución de componente de código debe instalarse en el entorno de destino antes de que pueda importarse.

Más información: Empaquetar y distribuir extensiones utilizando soluciones.

Componentes de código y canalizaciones de compilación automatizadas

Además de compilar e implementar manualmente sus soluciones de componentes de código, también puede compilar y empaquetar sus componentes de código utilizando canalizaciones de compilación automatizadas.

Algunas de las ventajas del uso de canalizaciones de compilación automatizadas son:

  • Son eficientes en tiempo: eliminar las tareas manuales hace que las tareas de construcción y empaquetado de su componente sean más rápidas, para que se pueda realizar con mayor regularidad, como cada vez que se registra un cambio.
  • Son repetibles: una vez que el proceso de creación esté automatizado, se realizará de la misma manera cada vez y, por lo tanto, no dependerá del miembro del equipo que realice la creación.
  • Ofrecen coherencia de versiones: cuando la canalización de compilación establece automáticamente la versión de su componente de código y la solución, puede tener la confianza de que, cuando se crea una nueva compilación, se versiona de manera consistente en relación con las versiones anteriores. Esto facilita el seguimiento de funciones, corrección de errores e implementaciones.
  • Son mantenibles: dado que todo lo que se necesita para construir su solución está contenido en el interior del control de código, siempre puede crear nuevas ramas y entornos de desarrollo revisando el código. Cuando esté listo para implementar una actualización, las solicitudes de extracción se pueden fusionar en ramas posteriores. Más información: Rama y estrategia de fusión con Microsoft Power Platform.

Como se describió anteriormente, existen dos enfoques para la administración de soluciones de componentes de código, proyectos de solución segmentados o una única solución mixta que contiene otros artefactos como aplicaciones controladas por modelos, aplicaciones de lienzo y tablas a las que se agregan los componentes de código.

Si está utilizando el proyecto de solución de componente de código segmentado, puede construir el proyecto dentro de una Canalización de Azure DevOps (utilizando Herramientas de compilación de Microsoft Power Platform) o Canalización de GitHub (utilizando Acciones de GitHub para Microsoft Power Platform). Cada componente de código de la carpeta pcfproj se agrega al control de fuente (excluyendo las carpetas generated, out y node_modules), un proyecto cdsproj se crea y se hace referencia a cada componente de código usando pac solution add-reference antes de agregar también al control de fuente. La canalización luego realizaría lo siguiente:

  1. Actualice la versión de la solución en el archivo Solution.xml para que coincida con la versión de su compilación. La versión de la solución se mantiene en el atributo ImportExportXml/Version. Consulte a continuación para obtener detalles sobre las estrategias de control de versiones.
  2. Actualice la versión del componente de código en el archivo ControlManifest.Input.xml. La versión se almacena en el atributo manifest/control/version. Esto debe hacerse para todos los proyectos pcfproj que se construyen.
  3. Ejecute una tarea MSBuild con el argumento/restore /p:configuration=Release, usando un comodín *.cdsproj. Esto compilará todos los proyectos cdsproj y sus proyectos pcfproj referenciados.
  4. Recopile el zip de la solución integrada en los artefactos de liberación de la canalización. Esta solución contendrá todos los componentes de código incluidos como referencias en el cdsproj.

Si está utilizando una solución mixta que contiene otros componentes, además de los componentes de código, esto se extraerá al control de código fuente utilizando SolutionPackager como se describió anteriormente. Su canalización luego realizaría lo siguiente:

  1. Actualice la solución y las versiones de los componentes de código de la misma manera que se describe anteriormente en los pasos 1 y 2.
  2. Instalar Herramientas de compilación de Microsoft Power Platform en la canalización de compilación usando la tarea PowerPlatformToolInstaller.
  3. Restaurar node_modules usando una tarea Npm con el comando ci.
  4. Cree componentes de código en modo de lanzamiento de producción utilizando una tarea Npm con un parámetro customCommand de run build -- --buildMode release.
  5. Copie la salida de la compilación en la carpeta del empaquetador de soluciones para el control correspondiente.
  6. Empaquete la solución usando la tarea PowerPlatformPackSolution de las herramientas de compilación de Power Platform.
  7. Recopile el zip de la solución integrada en los artefactos de liberación de la canalización.

Se recomienda que confirme los metadatos de la solución desempaquetados en el control de origen en su forma no administrada, para permitir la creación de un entorno de desarrollo en cualquier etapa posterior. (Si solo se confirmasen los metadatos de la solución administrada, sería difícil crear nuevos entornos de desarrollo). Dispone de dos opciones para hacer esto:

  1. Confirme tanto gestionado como no gestionado utilizando la opción /packagetype:Both de Solution Packager. Esto permite empaquetar en modo administrado o no administrado, pero tiene la desventaja de la duplicación dentro del código fuente, por lo que los cambios a menudo aparecerán en múltiples archivos xml, tanto en la versión administrada como no administrada.
  2. Solo compruebe el control no administado del origen (lo que da como resultado conjuntos de cambios más limpios) y luego, dentro de la canalización de compilación, importe la solución empaquetada en un entorno de compilación para que luego se pueda exportar como administrada para convertirla en un artefacto de implementación administrado.

Implementar versiones y actualizaciones

Al implementar y actualizar los componentes de su código, es importante tener una estrategia de control de versiones coherente para que pueda:

  • Realizar un seguimiento de qué versión se implementa en función de las funciones / correcciones que contiene.
  • Asegurarse de que las aplicaciones de lienzo puedan detectar que necesitan actualizarse a la última versión.
  • Asegúrese de las aplicaciones basadas en modelos invaliden su caché y carguen la nueva versión.

Una estrategia común de control de versiones es el control de versiones semántico, que tiene el formato: MAJOR.MINOR.PATCH.

Incrementando la versión PATCH

ControlManifest.Input.xml almacena la versión del componente de código en el elemento de control:

<control namespace="..." constructor="..." version="1.0.0" display-name-key="..." description-key="..." control-type="...">

Al implementar una actualización en un componente de código, la versión en el ControlManifest.Input.xml debe tener como mínimo su PARCHE (que es la última parte de la versión) incrementadO para que se detecte el cambio. Esto se puede hacer manualmente editando el atributo de la versión directamente o usando el siguiente comando para aumentar la versión del PARCHE en uno:

pac pcf version --strategy manifest

Alternativamente, para especificar un valor exacto para la parte del PARCHE (por ejemplo, como parte de una canalización de compilación automatizada) use:

pac pcf version --patchversion <PATCH VERSION>

Más información: versión pac pcf.

Cuándo incrementar la versión PRINCIPAL y SECUNDARIA

Se recomienda que la versión PRINCIPAL y SECUNDARIA de la versión del componente de código se mantenga sincronizada con la solución Dataverse que se distribuye. Por ejemplo:

  1. La versión del componente de código implementado es 1.0.0 y la versión de su solución es 1.0.0.0.
  2. Realiza una pequeña actualización en su componente de código e incrementa la versión del PARCHE en el componente de código en 1.0.1, utilizando pac pcf version --strategy manifest.
  3. Al empaquetar el componente de código para la implementación, la versión de la solución en Solution.xml se actualiza para ser 1.0.0.1, o la versión se incrementa automáticamente exportando manualmente la solución.
  4. Realiza cambios significativos en su solución, de modo que desea incrementar la versión PRINCIPAL y SECUNDARIA a 1.1.0.0.
  5. En este caso, la versión del componente de código también se puede actualizar para que sea 1.1.0.

Una solución de Dataverse tiene cuatro partes y se puede considerar como la siguiente estructura: MAJOR.MINOR.BUILD.REVISION.

Si esta usando AzureDevOps, puede configurar el control de versiones de su canalización de compilación mediante las variables de entorno Build y Rev (Número de ejecución (compilación): Azure Pipelines), y usar un script de PowerShell similar al enfoque descrito en el artículo Usar scripts de PowerShell para personalizar las canalizaciones.

Parte de la versión semántica Parte de la versión ControlManifest.Input.xml
MAJOR.MINOR.PATCH		 Parte de la versión Solution.xml
MAJOR.MINOR.BUILD.REVISION		 Versión de compilación AzureDevOps
PRINCIPAL PRINCIPAL PRINCIPAL Establecer usando la variable de canalización $(majorVersion) o utilice el último valor comprometido con el control de fuente.
SECUNDARIA SECUNDARIA SECUNDARIA Establecer usando la variable de canalización $(minorVersion) o utilice el último valor comprometido con el control de fuente.
--- --- COMPILAR $(Build.BuildId)
PATCH PATCH REVISIÓN $(Rev:r)

Consideraciones de ALM de aplicaciones de lienzo

El consumo de componentes de código en aplicaciones de lienzo es diferente del de las aplicaciones basadas en modelos. Los componentes de código deben agregarse explícitamente a la aplicación seleccionando Obtenga más componentes en el panel Insertar. Una vez que el componente de código se agrega a la aplicación de lienzo, se incluye como contenido dentro de la definición de la aplicación. Para actualizar a una nueva versión del componente de código después de su implementación (y la versión de control incrementada), el fabricante de la aplicación primero debe abrir la aplicación en Power Apps Studio y seleccionar Actualizar cuando se le solicite en el cuadro de diálogo Actualizar componentes de código. Luego, la aplicación debe guardarse y publicarse para que la nueva versión se use cuando los usuarios la ejecuten.

Actualizar componentes de código.

Si la aplicación no está actualizada o se usa Saltar, la aplicación sigue utilizando la versión anterior del componente de código aunque no exista en el entorno, ya que ha sido sobrescrita por la versión más reciente.

Dado que la aplicación contiene una copia del componente de código, es posible tener diferentes versiones de los componentes de código ejecutándose en paralelo en un solo entorno desde dentro de diferentes aplicaciones de lienzo. Sin embargo, no puede tener diferentes versiones de un componente de código ejecutándose en paralelo en la misma aplicación. Se recomienda que los fabricantes de aplicaciones actualicen sus aplicaciones a la última versión de los componentes del código cuando se implemente una nueva versión.

Nota

Aunque, en este momento, puede importar una aplicación de lienzo sin que el componente de código coincidente se implemente en ese entorno, se recomienda que siempre se asegure de que las aplicaciones estén actualizadas para usar la última versión de los componentes de código y que se implemente la misma versión en ese entorno primero o como parte de la misma solución.

Administración del ciclo de vida de la aplicación (ALM) con Microsoft Power Platform
Referencia de la API de Power Apps component framework
Crear el primer componente
Depurar componentes de código

Nota

¿Puede indicarnos sus preferencias de idioma de documentación? Realice una breve encuesta. (tenga en cuenta que esta encuesta está en inglés)

La encuesta durará unos siete minutos. No se recopilan datos personales (declaración de privacidad).