Una aplicación que funciona en desarrollo todavía necesita demostrar que utiliza las conexiones, los datos y los permisos correctos en producción. En Power Apps y Power Automate, un proceso de ALM debe controlar tanto los componentes de la solución como la configuración externa de la que dependen.
Separar desarrollo, validación y operación
Microsoft recomienda trabajar con soluciones no administradas en desarrollo y distribuirlas como administradas a ambientes de prueba y producción. La solución exportada es un artefacto de entrega; el origen debe conservarse bajo control de versiones.
Proponemos un recorrido con tres etapas: DEV para construir, UAT para validar con usuarios y PROD para operar. La aprobación debe referirse a una versión identificable y a resultados de prueba registrados.
Tres conceptos que conviene distinguir
| Elemento | Responsabilidad |
|---|---|
| Conexión | Autenticación frente al servicio conectado. |
| Referencia de conexión | Componente de solución que apunta a una conexión. |
| Variable de entorno | Parámetro cuyo valor puede cambiar según el ambiente, como el sitio o la lista de SharePoint. |
Los flujos incluidos en soluciones utilizan referencias de conexión. En Canvas Apps hay diferencias según el conector y la autenticación: Microsoft limita su uso a conexiones compartidas implícitamente, como SQL Server Authentication. No debe suponerse que el patrón de un flujo se aplica de manera idéntica a una app Canvas con SharePoint.
Agregar una app o un flujo existente a una solución tampoco garantiza su adaptación automática. Revise sus dependencias y conexiones antes de exportar.
Ejemplo propuesto: registro de solicitudes con SharePoint
El ejemplo consiste en una app Canvas que crea solicitudes y un flujo que procesa los registros. Es un ejercicio de referencia; no corresponde a una implementación probada por Enoiax.
Prerrequisitos: ambientes con Dataverse para trabajar con soluciones, acceso autorizado a Power Apps y Power Automate, sitios SharePoint de prueba y licencias aplicables a los conectores y usuarios. Verifique las condiciones del tenant; esta guía no presupone licencias ni capacidad disponibles.
- Preparar los datos externos. Cree sitios separados para DEV, UAT y PROD y una lista Solicitudes en cada uno. Mantenga iguales los nombres internos y tipos de columnas, por ejemplo Title y Estado. Documente su creación y permisos como parte del despliegue; importar la solución no debe darse por equivalente a aprovisionar SharePoint.
- Construir desde una solución en DEV. Incluya la app y el flujo. Defina variables de origen de datos para el sitio y la lista. Microsoft indica que, al agregar SharePoint como origen de una app Canvas, la pestaña Advanced permite seleccionar esas variables.
- Configurar el flujo. Use una referencia de conexión y parametrice las acciones o disparadores que apunten al sitio y a la lista. Compruebe que la identidad empleada puede acceder únicamente a los recursos necesarios.
- Preparar la entrega. Incremente la versión, revise dependencias y exporte como administrada. Evite transportar valores de DEV que deban establecerse en destino. Guarde el artefacto aprobado.
- Importar en UAT. Asigne valores del sitio y lista de UAT y la conexión correspondiente. Verifique que quien activa el flujo tenga autorización sobre las conexiones. Comparta la app y conceda acceso a los datos a los usuarios de prueba.
- Validar y promover. Tras la aceptación, utilice el mismo artefacto aprobado para producción y proporcione la configuración de PROD. Ejecute una prueba breve y supervise las primeras operaciones.
Para apps existentes, Microsoft indica que puede ser necesario quitar y volver a agregar el origen de datos para utilizar variables de entorno. Realice este cambio en desarrollo y compruebe las fórmulas afectadas.
Pruebas de aceptación sugeridas
- Crear una solicitud en UAT y comprobar que no apareció en DEV ni PROD.
- Verificar que el flujo utiliza la lista correcta y no genera registros duplicados.
- Probar con un usuario autorizado y otro sin permisos sobre los datos.
- Comprobar el comportamiento cuando falla una conexión o falta configuración.
- Registrar versión, resultado, responsable y evidencia de aprobación.
Recuperación y mantenimiento
No utilice la desinstalación de una solución administrada como una receta genérica de rollback: Microsoft advierte que puede eliminar datos de tablas y columnas incluidas. Diferencie actualización, upgrade y recuperación antes de liberar.
Como práctica operativa propuesta, conserve el artefacto anterior, documente las dependencias externas y ensaye una estrategia de recuperación compatible con el cambio. Una corrección posterior puede ser más apropiada que intentar restaurar una versión antigua. Defina además quién mantiene conexiones, accesos y alertas.
Fuentes
Esta guía desarrolla el tema planteado por M Sufiyan Uddin en LinkedIn y contrasta sus conceptos con documentación oficial. Es una práctica de gestión de aplicaciones; no un anuncio de una función nueva.