Temas del taller de ALM
En esta unidad, veremos lo que debe considerar al completar y evaluar la plantilla del taller de administración del ciclo de vida de las aplicaciones (ALM). Estos temas están diseñados para ayudar al arquitecto de soluciones a evaluar la información recopilada durante el taller y producir los hallazgos y recomendaciones. Es importante recordar que ALM no sirve para todo. La cantidad y la sofisticación de ALM deben decidirse proyecto por proyecto. Un buen punto de partida para comprender ALM con Dynamics 365 y Microsoft Power Platform son los temas de Administración del ciclo de vida de las aplicaciones (ALM) con Microsoft Power Platform en esta página de la documentación.
Estrategia general
Es importante comprender la metodología de desarrollo que está utilizando el equipo del proyecto para producir la solución. Además, es importante comprender el número de equipos involucrados, especialmente aquellos involucrados en la realización de personalizaciones. Se debe influir en la estrategia ALM para apoyar a estos equipos y permitir que los equipos del proyecto trabajen de manera eficaz.
Aspectos clave que hay que tener en cuenta
Falta de metodología de desarrollo. Este es un mal lugar en un proyecto para "simplemente ir a por ello".
Los enfoques de cascada más tradicionales no se recomiendan con proyectos de Microsoft Power Platform y Dynamics 365. La mayoría de los equipos descubren que algún tipo de enfoque ágil o iterativo es más efectivo para entregar un proyecto con éxito.
No tener una comprensión clara de quién participará en los cambios y cómo se coordinarán es un riesgo.
¿Existe una herramienta para realizar un seguimiento de los elementos de trabajo, incluida su asignación?
Evolución de ALM
No todos los clientes automatizan por completo su proceso de ALM desde el principio. Algunos optan por el enfoque gatear, caminar, correr.
No administrado en desarrollo
Gatear:
- Exportar/importar
- Exportar/guardar en archivo
- Sistema/importar
Caminar:
- Varias soluciones sin control de código fuente
- Introducción de datos maestros
- Introducción de control de código fuente basado en soluciones
Correr:
- Introducción de la automatización con implementaciones de paquetes
- Control de versiones habilitado a través del empaquetador de soluciones
Administrado en todas partes de forma ascendente
- Compilaciones automatizadas y administración de instancias
- Azure DevOps con control de origen automatizado
Entornos
Deben crearse entornos para respaldar la estrategia de ALM que se está implementando. Como mínimo, el proyecto generalmente debe tener un entorno de desarrollo, de prueba y de producción. Estos entornos deben ser de espacio aislado o de producción, no de evaluación o comunitario. Además, considere tener un entorno de revisión para los cambios que deben aplicarse a la producción posterior a la puesta en funcionamiento.
Si se van a crear entornos en diferentes regiones geográficas, los equipos deben ser conscientes de que los entornos se actualizarán en diferentes momentos. Por ejemplo, si el desarrollo está en la región de Canadá y la producción está en la región de América del Norte, es posible que Canadá tenga características que América del Norte aún no tiene. Cuando se utilizan varias regiones geográficas, se requiere una mayor coordinación con las actualizaciones y características de Microsoft.
Cada solución de Microsoft Dataverse debe tener al menos un entorno de desarrollo que respalde a los miembros del equipo que realizan personalizaciones. Con un modelo centrado en el origen, son posibles múltiples entornos de desarrollo, pero requieren coordinación para resolver los conflictos de fusión a medida que ocurren. Los entornos de desarrollo únicos son más fáciles de administrar mediante coordinación básica, pero los entornos múltiples permiten un mayor aislamiento del desarrollador y mayor velocidad del equipo. Se debe implementar un control de acceso adecuado para garantizar que solo los miembros adecuados del equipo tengan acceso a los diferentes entornos. Esto también ayuda a garantizar que las personas no realicen cambios fuera del entorno de desarrollo asignado.
Aspectos clave que los entornos deben cumplir
¿Se ha identificado una cantidad razonable de entornos? Como mínimo, deben tener un entorno de desarrollo, de prueba y de producción. Si hay demasiados entornos sin un propósito claro, se puede generar una complejidad difícil de gestionar.
¿Están pensando en almacenar soluciones desempaquetadas en control de código fuente?
¿Se están utilizando entornos de evaluación? Si es así, corren el riesgo de que caduquen y perder personalizaciones inesperadamente.
¿Hay capacidad de almacenamiento disponible para respaldar el plan del entorno?
Control de código fuente
También es importante comprender cómo se promoverán las personalizaciones y otros activos de código desde el desarrollo a través de los diferentes entornos de prueba hasta la producción. Algo importante en este sentido es mirar lo que se considerará la fuente fiable de los activos de código y personalización. En el pasado, los proyectos se centraban en el entorno, donde el entorno de desarrollo, por ejemplo, sería la fuente fiable para las personalizaciones. En este modelo, las personalizaciones pasarían directamente de desarrollo a prueba y a producción. Los cambios se transportarían como una solución exportada desde el desarrollo.
Si está mejorando una implementación existente que se completó en el pasado, este puede ser el modelo que usaron para el proyecto original. Los nuevos proyectos deben usar el control de código fuente como fuente fiable para todas las personalizaciones y activos de código del proyecto. Por ejemplo, los repositorios de git de Azure DevOps se pueden usar para almacenar todo. Con este modelo, el equipo del proyecto verifica sus personalizaciones en el control de código fuente. La solución administrada que se implementará se generará a partir del control de código fuente y se utilizará para promover las personalizaciones para la prueba y finalmente la producción. Este enfoque hace que los entornos de desarrollo sean desechables. El otro beneficio del enfoque centrado en el control de código fuente es que mantiene información detallada de lo que se ha cambiado y facilita una estrategia de ramificación. La ramificación es esencial para permitir el servicio a una versión de producción mientras se crea la próxima versión. Además, al vincular la solicitud de incorporación de cambios o las confirmaciones a los elementos de trabajo, se crea una trazabilidad que mejora el proceso de desarrollo general.
Aspectos clave que el control de código fuente debe cumplir
Si anteriormente se utilizó un enfoque centrado en el entorno en lugar de uno centrado en el control de código fuente, ¿existe un plan para pasar al control de código fuente?
¿Se ha identificado una cantidad razonable de entornos? Como mínimo, debe haber un entorno de desarrollo, de prueba y de producción. Si hay demasiados entornos, se puede generar una complejidad difícil de gestionar.
¿Se utilizan soluciones administradas para todos los entornos distintos del desarrollo?
Soluciones
Cuando sea posible, todos los activos del proyecto que son componentes que reconocen la solución deben administrarse en una solución de Dataverse. La mayoría de los proyectos centrados en una sola línea de negocio o proceso de negocio deben utilizar una única solución personalizada. El equipo del proyecto debe asociar un editor de soluciones personalizadas que represente a la empresa o el producto que está creando y no utilizar el editor predeterminado. No utilice varios editores a menos que exista un caso de negocio para hacerlo.
Si se usan varias soluciones, deben usarse con un propósito específico que estén resolviendo. Por ejemplo, un proyecto que podría colocarse en una solución independiente es un componente reutilizable que se piensa usar varias veces. Las soluciones se pueden segmentar por línea de negocio o proceso de negocio. Estas soluciones segmentadas pueden compartir una base común, pero deben aislarse solo para sus personalizaciones y no tener dependencias entre sí. Sin embargo, esto puede conducir rápidamente a una mayor complejidad y debe evaluarse frente a los beneficios de tener soluciones separadas.
Cada solución debe tener su propio entorno de desarrollo, manteniéndolos aislados entre sí. Cuando una solución depende de otra solución, la versión administrada de la solución dependiente debe instalarse en el entorno de desarrollo. Si bien el marco de la solución admite el concepto de soluciones de parches, no se recomiendan cuando se usa un modelo centrado en el origen.
Aspectos clave que las soluciones deben cumplir
¿Se ha creado un editor personalizado con una corrección previa personalizada adecuada y el equipo no está utilizando el editor predeterminado?
¿La arquitectura de la solución propuesta utiliza un número razonable de soluciones, cada una con un propósito claro?
¿El plan del entorno respalda el número de soluciones que se utilizan en el proyecto, garantizando un aislamiento adecuado de la solución?
Plan de creación
En esta sección, analizamos cómo el equipo planea administrar la creación de soluciones utilizando múltiples entornos. Las soluciones deben componerse en el entorno de desarrollo donde se modifican sus componentes. El plan de ALM debe garantizar que los cambios solo se realicen en el entorno de desarrollo. El entorno de desarrollo debe ser el único lugar donde se utilizan las soluciones no administradas; todos los demás entornos deben tener instaladas soluciones administradas. Cada entorno de desarrollo debe tener una única solución no administrada.
Si bien existe compatibilidad para exportar soluciones e importarlas manualmente, lo ideal es que el proceso de compilación incluya algo de automatización para crear un proceso repetible.
Aspectos clave que los planes de creación deben cumplir
¿Los entornos de desarrollo contienen solo una única solución no administrada?
¿Se utilizan las soluciones administradas en todos los entornos distintos al de desarrollo?
¿Se han implementado restricciones de acceso u otros mecanismos para garantizar que las modificaciones solo tengan lugar en el desarrollo?
No todos los componentes reconocen la solución y debe haber un plan para gestionar los componentes que no lo son (por ejemplo, las visualizaciones de Power BI).
Empaquetador de soluciones
El empaquetador de soluciones debe usarse para tomar la solución no administrada en desarrollo y prepararla para almacenarla en un repositorio del control de código fuente. El empaquetador de soluciones toma el archivo de solución único y lo divide en archivos individuales que representan cada componente de la solución. Este proceso se conoce como desempaquetar la solución. Luego, la salida del empaquetador de soluciones se inserta en el repositorio de control de código fuente. Esta versión insertada en el repositorio ahora representa la fuente fiable del proyecto.
El empaquetador de soluciones también puede empaquetar la carpeta desde el control de código fuente, recreando el archivo de solución único. Así es como los archivos que se insertan en el repositorio de control de código fuente se utilizan para crear las soluciones que se importarán a los otros entornos.
Aspectos clave que los empaquetadores de soluciones deben cumplir
¿Está previsto usar un empaquetador de soluciones y un repositorio de control de código fuente?
¿La solución implementada para pruebas y producción se crea desde el repositorio de control de código fuente?
Comprobador de soluciones
Como Power Automate y Power Apps se utilizan para personalizar una implementación de Dynamics 365, cada uno ofrece sus propios comprobadores de aplicaciones en línea, que son útiles para la resolución de problemas en tiempo real. El comprobador de soluciones, sin embargo, puede ver la solución completa y realizar un análisis estático y producir una lista detallada de los problemas encontrados. (Se pueden encontrar más detalles en Usar el comprobador de soluciones para validar sus aplicaciones basadas en modelos en Power Apps).
El comprobador de soluciones debe ejecutarse regularmente en cualquier solución no administrada que esté creando en sus entornos de desarrollo. El comprobador de soluciones puede analizar los flujos de Power Apps y Power Automate, así como activos de código, como complementos que crean los desarrolladores. El equipo del proyecto puede ejecutar manualmente el comprobador de soluciones desde el portal del creador seleccionando la solución y luego ejecutando el comprobador.
El comprobador de soluciones también se puede automatizar para que se ejecute como parte de un proceso de compilación mediante tareas de canalización de PowerShell o Azure DevOps. Al automatizar la ejecución del comprobador de soluciones, puede convertirse en una parte integral del proceso de compilación e incluso se puede configurar para detener la compilación si se han producido demasiados errores. El simple hecho de ejecutar el comprobador de soluciones no es suficiente para que el equipo tenga éxito; también debe haber un plan para evaluar y resolver regularmente los problemas identificados.
Aspectos clave que los comprobadores de soluciones deben cumplir
¿Existe un plan para ejecutar el comprobador de soluciones como parte del proceso de compilación?
¿Los resultados del comprobador de soluciones se revisan e incorporan regularmente en el proceso?
¿Se ha integrado el comprobador de soluciones en la automatización de la compilación para que se ejecute sin esfuerzo manual?
Automatización de la implementación
Un área que es tan importante como parte del plan de creación es analizar qué automatización se puede usar para hacer que el proceso sea repetible. Microsoft y la comunidad proporcionan numerosas herramientas que se pueden usar para automatizar el proceso de creación. Las tareas de Azure DevOps y Microsoft Power Platform son una opción que se puede utilizar para automatizar las tareas de implementación y administración de la solución.
Por ejemplo, un equipo podría tener una canalización de Azure DevOps que extrae elementos del desarrollo los días a las 7:00 p. m. y los registra en un repositorio de git. La misma canalización también se puede utilizar para ejecutar el comprobador de soluciones, de modo que cuando el equipo entre a trabajar por la mañana, sepa de inmediato si hubo algún problema identificado en la compilación de la noche anterior.
La canalización también podría importar la solución a un entorno de creación limpio que permitirá la detección de cualquier dependencia que se haya introducido involuntariamente durante el desarrollo de ese día. Esto asegura que lo que se registra en el control de código fuente es una versión limpia lista para su implementación en otros entornos. Las canalizaciones también se pueden utilizar para automatizar las pruebas, de modo que sea solo un paso más dentro de la canalización.
Azure Pipelines también se usa para producir el artefacto de solución administrada que se usará en las canalizaciones de lanzamiento para implementar en los entornos ascendentes, como los de pruebas y producción. El mismo artefacto de solución que se utilizó en la prueba se utiliza hasta la producción. Esto asegura que no se introducen nuevos cambios sorprendentes a medida que avanza la promoción a través de la serie de entornos que terminan en el de producción. Azure Pipelines también se puede usar para crear activos de código de desarrollador a fin de garantizar que no se generen en una estación de trabajo de desarrollador local.
Las acciones de GitHub es otra opción para automatizar implementaciones.
Aspectos clave que la automatización de la implementación debe cumplir
¿Se usa Azure DevOps u otra herramienta de automatización para automatizar el proceso de creación o el equipo todavía depende del esfuerzo manual?
¿Se ha integrado el comprobador de soluciones como parte de la canalización automatizada?
¿Todos los activos de código de desarrollador se están creando a través de un proceso de compilación y no en la máquina local de un desarrollador individual?
Control de versiones
Otro elemento del plan de creación que debe revisarse es la estrategia para administrar múltiples versiones activas. De forma predeterminada, a medida que los cambios avanzan de desarrollo a prueba y a producción, representa una única secuencia de trabajo de cambios. Si se identifica un problema en producción, lo solucionaría en desarrollo y luego lo promovería a través de la serie de entornos de regreso a producción. Un solo flujo de trabajo como este funciona bien si no se realiza ningún desarrollo nuevo.
Si el equipo de desarrollo ya pasó a la versión dos en su entorno de desarrollo y luego corrige un error que se identificó en producción, a medida que la corrección se traslada a producción, también lo haría el trabajo en curso para la versión dos, porque se mezcló todo. La acción ideal es cuando el cambio se realiza en un entorno de desarrollo de secuencia de trabajo independiente que representa solo lo que ya estaba en producción y lo que se promocionó solo incluía la corrección, nada de la versión dos. Esto requiere que el equipo del proyecto planifique con anticipación y tenga una estrategia para administrar múltiples versiones activas. Podría ser tan simple como una secuencia de desarrollo activa y una secuencia de mantenimiento para respaldar la producción. Los proyectos más complejos pueden incluso tener múltiples secuencias de desarrollo activas al mismo tiempo.
Gestionar las secuencias de desarrollo y mantenimiento activas al mismo tiempo generalmente tiene lugar a través de una combinación de entornos de Dataverse y ramas de control de código fuente. Las ramas permiten tener una copia de los activos del proyecto y una forma aislada de realizar cambios en un entorno asociado a esa rama. Los cambios de una rama se pueden fusionar mediante combinación con otra rama. La estrategia de ramificación debe mantenerse lo más simple posible para evitar tener que resolver muchos conflictos durante la fusión de ramificaciones.
Aspectos clave que el control de versiones debe cumplir
¿Ha considerado el equipo cómo mantendrá el trabajo de desarrollo separado de las correcciones de errores para producción?
¿La estrategia de ramificación identificada es demasiado compleja?
¿La ramificación para el control de código fuente está coordinada con el plan del entorno?
¿Existe un proceso de administración de cambios para garantizar que las correcciones de errores vuelvan al entorno de desarrollo principal?
Estrategia de pruebas
Si bien la estrategia de prueba tiene su propio taller, el proceso de prueba en sí debe integrarse como parte de la estrategia general de ALM. Por ejemplo, si planea hacer pruebas diarias del trabajo del día anterior por parte del equipo de control de calidad, de alguna manera debe asegurarse de que el equipo de control de calidad tenga un entorno actualizado con los cambios de ayer listos para comenzar antes de que puedan comenzar las pruebas.
La automatización de las pruebas también debe considerarse y podría integrarse como parte del proceso de creación. Esto podría incluir el aprovisionamiento de un entorno de prueba, la carga de datos de prueba y la ejecución de pruebas. Los resultados de la prueba podrían usarse para controlar el progreso de las canalizaciones de compilación y evitar que continúen cuando hay errores.
Se pueden probar aplicaciones basadas en modelos de Power Apps con EasyRepro. Se pueden probar aplicaciones de lienzo de Power Apps mediante el estudio de pruebas de Power Apps. El estudio de pruebas funciona registrando acciones en la aplicación y reproduciéndolas para automatizar las pruebas. Easy Repro utiliza scripts para definir los pasos de prueba que se llevarán a cabo. Una vez registrada o generados los scripts, la prueba se puede incluir como una tarea en una canalización de Azure DevOps.
A medida que se realizan las pruebas, en última instancia, se identificarán los problemas que deberán evaluarse y solucionarse. La estrategia general de ALM debe incluir cómo documentar los problemas, y cómo clasificarlos y priorizarlos. Si un equipo de desarrollo dejara todo y corrigiera todos los errores a medida que apareciesen, sería perjudicial para el proceso general. Por lo general, un proyecto debe establecer un proceso de control de cambios para garantizar que cada problema se clasifique y se priorice en cuanto a cuándo se introducirá como solución.
Aspectos clave que hay que tener cuenta en una estrategia de pruebas
¿La estrategia ALM se alinea con la estrategia general de pruebas?
¿Existe un proceso de control de cambios para rastrear y gestionar cualquier problema que se identifique?
¿Se han integrado al menos algunas pruebas en el proceso de automatización de compilación?
Lanzamiento e implementación
Una vez compilada la solución, debe promoverse a través de los entornos de prueba a producción. Por lo general, esto implica más que simplemente importar una solución a esos entornos. Para empezar, hay que estar atento al estado inicial del entorno. Por ejemplo, para la prueba, ¿desea que comience con algunos datos de prueba estándar cada vez, o desde el punto de partida de la última ronda de pruebas? Es probable que cada entorno tenga algún tipo de datos de configuración (por ejemplo, variables de entorno) que deben configurarse al menos para la primera implementación. Para los entornos de prueba, también debe asegurarse de que no se esté hablando con los servicios de producción en la mayoría de los casos. Por lo general, no se agradece enviar un correo electrónico de prueba a todos sus clientes reales.
Aspectos clave que el lanzamiento y la implementación deben cumplir
¿Existe un plan para el aspecto de cada entorno de prueba desde la perspectiva de los datos, así como sus conexiones con cualquier servicio?
¿Se han creado las variables de entorno de la solución necesarias para garantizar que la solución se pueda adaptar a cada entorno?
Datos de referencia
La mayoría de las soluciones tienen algún tipo de datos de referencia que deben gestionarse entre los diferentes entornos. La herramienta de migración de la configuración es una herramienta que puede ayudar a exportar datos de un entorno e importarlos a otros. La herramienta de migración de configuración funciona definiendo un esquema de los datos que se exportarán, incluidos los campos y las relaciones. Cuando se ejecuta la exportación, se crea un archivo zip de datos que contiene todos los datos exportados. La herramienta de migración de la configuración también puede encargarse de importar los datos a un entorno donde el archivo de datos se puede usar con la herramienta Package Deployer. Esta herramienta es capaz de evitar duplicados mediante el uso de condiciones únicas que se han definido para cada entidad, de acuerdo con una combinación de campos. Si se encuentra un registro coincidente, el registro se actualiza; de lo contrario, se crea un nuevo registro.
Aspectos clave que los datos de referencia deben cumplir
¿Existe una comprensión clara de lo que constituyen los datos de referencia para la solución?
¿Está claro cuál es la copia maestra de los datos de referencia y dónde se almacenará y rastreará?
¿Existe un plan sobre cómo gestionar los datos de referencia entre entornos?
Package Deployer
Otra herramienta que es útil para administrar el lanzamiento y la implementación es la herramienta Package Deployer. La herramienta le permite crear un paquete que incluye múltiples soluciones, datos de la herramienta de migración de configuración y la lógica del código del desarrollador que se ejecuta antes y después de que se complete la importación del paquete. En muchos sentidos, podría pensar en Package Deployer como un asistente de instalación para Microsoft Power Platform. Package Deployer se puede ejecutar de forma interactiva para importar manualmente paquetes y datos en un entorno. Package Deployer también admite la ejecución con PowerShell, lo que permitiría la automatización y la integración en Azure Pipeline.
Aspectos clave que Package Deployer debe cumplir
- ¿Ha considerado el equipo si Package Deployer sería útil en su estrategia de implementación?
Canalizaciones de versión
Anteriormente en esta unidad, hablamos sobre la automatización del proceso de compilación, que prepararía la solución para la implementación y la crearía como un artefacto de compilación. Azure Pipeline también admite el concepto de canalizaciones de versiones para administrar la versión en uno o más entornos. Las canalizaciones de versiones están diseñadas para tomar los artefactos de compilación (por ejemplo, un archivo de solución administrada) e implementarlos en entornos de prueba o producción. Las canalizaciones de versiones pueden incorporar procesos de aprobación entre cada uno de los entornos. Las aprobaciones se pueden utilizar para coordinar la decisión de avanzar de múltiples partes interesadas a medida que la versión progresa por los niveles de entorno.
Aspectos clave que las canalizaciones de versiones deben cumplir
¿Se utiliza Azure Pipeline o una herramienta similar para implementar las soluciones compiladas entre los entornos?
Dado que el progreso de la implementación es entre los entornos, ¿cómo se gestionarían las aprobaciones?
Modelo de ejecución
Aquí es donde observamos la estrategia posterior a la puesta en marcha. Se supone que ha realizado su implementación inicial y ahora está pasando a dar servicio a lo que ha implementado y está trabajando en mejoras. A medida que los usuarios usen inevitablemente lo que usted ha creado, identificarán las cosas que desean cambiar o mejorar para que sean más productivos. El equipo del proyecto debe tener una herramienta para capturar estas solicitudes de cambio y una forma de evaluarlas, priorizarlas y categorizarlas en actualizaciones.
Por ejemplo, estos cambios podrían agruparse fácilmente en tres categorías: críticos, menores y mayores.
Mientras piensa en la administración de los cambios en curso, debe contar con procesos para hacer frente a, al menos, estos tres tipos de cambios. Los cambios críticos, por ejemplo, deben tener una forma de implementarse casi de inmediato porque impiden que los usuarios completen su trabajo. Por lo general, estos no pueden esperar a que ocurra una implementación semanal, por lo que necesita una forma de dar servicio a la producción sin esperar una compilación planificada y la implementación de la próxima actualización programada. Es importante tener un proceso para controlar estos problemas críticos, porque lo que desea evitar es tener que realizar cambios en el entorno de producción para solucionar el problema.
Aspectos clave que debe tener en cuenta con la estrategia posterior a la puesta en marcha
¿La estrategia del entorno y la ramificación de control de código fuente admiten la implementación inmediata de correcciones críticas?
¿Existe un plan para llevar cualquier trabajo pendiente anterior a la puesta en marcha a un ciclo de mantenimiento y mejora?
¿Existe un control de cambios para rastrear y clasificar los problemas identificados en la aplicación operativa?
¿Existe un proceso para garantizar que las correcciones críticas que ocurren rápidamente se incorporen al proceso de lanzamiento normal?
Ciclo de actualizaciones de Microsoft
Además de las actualizaciones que crea su equipo para mejorar o solucionar problemas, Microsoft también hace lo mismo para las aplicaciones Microsoft Power Platform y Dynamics 365. Por lo general, Microsoft lanza todas las semanas actualizaciones que normalmente no interrumpirán la experiencia del usuario. Estas actualizaciones se implementan mediante una práctica de implementación segura que minimiza cualquier impacto en sus entornos. Puede controlar cuándo se aplican estas actualizaciones a su entorno de producción a través de la herramienta de administración.
La mayoría de los cambios de aplicación de Dataverse y Dynamics 365 se implementan por región. Para asegurarse de que no hay efectos adversos en sus personalizaciones, una estrategia es para probarlas en un entorno que resida en una región que reciba las actualizaciones antes que la suya y ejecutar pruebas automatizadas allí para identificar cualquier problema. Incluso si eso no es viable, aún puede ejecutar pruebas automatizadas semanales para la funcionalidad crítica a fin de asegurarse de sus personalizaciones no se ven afectadas de manera negativa.
Actualmente, dos veces al año (abril y octubre), Microsoft lanza actualizaciones que son más importantes y pueden incluir cambios que pueden afectar a la experiencia de usuario en la aplicación existente. Estas actualizaciones se planifican con anticipación y se anuncian primero mediante un plan de lanzamiento publicado que detalla los próximos cambios. Esto sucede varios meses antes de que se aplique automáticamente la actualización real.
Como parte del proceso que conduce a la actualización automática, los administradores pueden habilitar manualmente los cambios en los entornos antes de que se apliquen automáticamente en todos ellos. Esto le permite copiar un entorno de producción a un entorno de espacio aislado que no sea de producción y realizar pruebas de los cambios antes de implementarlos en producción. Cuando la prueba se realice correctamente, le permite optar por los cambios en su propio horario, en lugar de esperar a las actualizaciones automáticas.
Aspectos clave que los ciclos de actualizaciones deben cumplir
¿Ha evaluado el equipo si necesita hacer pruebas semanales y tener planes implementados?
¿El cliente comprende el proceso de actualización y cómo puede optar por realizar pruebas dos veces al año con anticipación?
Administración de capacidad
La administración de la capacidad es importante tanto durante la implementación previa como durante la gestión del uso una vez que el proyecto está activo. La administración de la capacidad es algo más que el simple almacenamiento, sin embargo, el almacenamiento es un elemento clave. Otra capacidad que se debe supervisar son las solicitudes de API y asegurarse de que se mantiene al día con sus asignaciones de licencias y, cuando sea necesario, agregar solicitudes de API adicionales. Otros productos y complementos, incluidos AI Builder y Power Virtual Agents, también tienen capacidad, lo que se debe tener en cuenta a lo hora de administrar la capacidad general.
Desde el punto de vista de la capacidad de almacenamiento, la capacidad de Dataverse se divide en capacidad de base de datos, registro y archivo. Se realiza un seguimiento de cada uno de estos y se puede agregar almacenamiento adicional individualmente según su uso real. Para crear nuevos entornos en su inquilino, debe tener al menos 1 GB de capacidad de base de datos restante. Es importante tener esto en cuenta al crear una estrategia de ALM que incluirá varios entornos. Si su estrategia de ALM implica entornos temporales, estos solo toman capacidad cuando están realmente en uso. Pero para crearlos a través de un proceso automatizado, la capacidad debe estar disponible en el momento en que se ejecuta la automatización. De lo contrario, la automatización fallará.
Para la capacidad de la base de datos, debe estimar la capacidad inicial en función de los datos que migrará a Dataverse cuando se realice la puesta en marcha. Esto también incluye datos que pueden existir en entornos que no son de producción. Un primer paso clave en este proceso es comprender la cantidad de registros que tiene por entidad. Tan pronto como pueda migrar parte de sus datos, puede comenzar a obtener información extrapolando la carga de datos completa, según la muestra que cargue en Dataverse. Cuando pueda realizar una carga completa de los datos que planea migrar, debería poder obtener información de tamaño para ese entorno. El Centro de administración de Microsoft Power Platform proporciona herramientas que le permiten ver el uso de almacenamiento de las principales entidades. Además de la capacidad inicial, es importante pensar en el crecimiento continuo a medida que su solución se ejecuta en un entorno activo. Para las principales entidades, conocer su tasa de crecimiento puede ayudarle a determinar las necesidades de capacidad de manera continua.
El uso de la capacidad del archivo depende de cuánto utilice los archivos adjuntos y los tipos de datos de archivos de imagen en los registros. La capacidad de archivo también se usa si tiene una o más aplicaciones Insights instaladas. Estimar el almacenamiento es como la capacidad de la base de datos, y es esencial comprender la cantidad de registros y el tamaño de archivo promedio de esos registros.
El uso de la capacidad de registro depende de si utiliza la función de seguimiento de complementos y auditoría. Aunque utiliza cierta capacidad, la auditoría es una característica valiosa que se debe habilitar. La auditoría se controla en el nivel de entorno, entidad y campo, y debe habilitarse donde tenga sentido. La auditoría es valiosa en escenarios empresariales, para saber quién hizo qué cambio y para solucionar problemas en el sistema. Aproveche la característica que le permite establecer un plazo de retención si cumple con las necesidades de su negocio.
Puede supervisar su uso de almacenamiento en el Centro de administración de Microsoft Power Platform. Para obtener más información, consulte Análisis de Dataverse.
Aspectos clave que la capacidad debe cumplir
¿Tiene el equipo un buen conocimiento del volumen de registros por entidad?
¿Existe un plan para supervisar la capacidad después de la puesta en marcha inicial para garantizar que se aprovisione la capacidad adecuada?
Administración de capacidad de las solicitudes de API
Las solicitudes de API incluyen todas las solicitudes de API de los conectores, cada acción de paso de Power Automate y todo el uso de API de Dataverse. Puede encontrar una lista completa de lo que se tiene en cuenta aquí en Asignaciones y límites de solicitudes. Cada licencia que tiene para Power Apps, Power Automate y Dynamics 365 proporciona una asignación de solicitudes de API cada 24 horas. Generalmente, la asignación de licencia incluye suficientes solicitudes de API para el uso normal de las aplicaciones para las que tiene licencia. Si excede sus asignaciones de manera regular, puede comprar solicitudes de API adicionales a través de licencias complementarias. La causa más común del exceso son las integraciones o la lógica personalizada con el procesamiento masivo. A menudo, se pueden ajustar para un procesamiento más eficiente y evitar exceder las solicitudes de API. Los arquitectos de soluciones deben prestar más atención a este tipo de procesos para asegurarse de optimizar el uso de API de la mejor manera posible.
Además del seguimiento de asignación de solicitudes de API, Dataverse también implementa límites de protección del servicio. Están diseñados para garantizar una disponibilidad y un rendimiento constantes para todos los que utilizan el servicio. Nuevamente, el uso normal no debería activar la protección del servicio. Sin embargo, las integraciones de gran volumen ocasionalmente pueden tener errores debido a la activación de la protección del servicio. Los límites de protección del servicio se evalúan cada cinco minutos mediante una ventana deslizante. El uso evaluado es el número de solicitudes enviadas por un usuario, el tiempo de ejecución combinado de las solicitudes y las solicitudes simultáneas de un usuario.
Los límites de protección del servicio no pueden sobrescribirse comprando más asignaciones de licencias y se deben gestionar en las aplicaciones mediante la lógica de reintento adecuada. Puede leer más sobre los límites de protección del servicio y cómo gestionar los reintentos en Límites de la API de protección de servicio.
Aspectos clave que las solicitudes de API deben cumplir
¿El equipo ha identificado los posibles puntos de conflicto de las solicitudes de API que podrían causar problemas?
¿Se ha agregado la lógica de reintento a todas las integraciones o al trabajo masivo de API?
¿Existe un plan para supervisar el uso de API y ajustar la capacidad según sea necesario?