Tanto si estás aquí porque tienes un error al desplegar una solución como si simplemente estás por curiosidad, considero que este artículo va a servirte para comprender mejor como funcionan las soluciones y los despliegues. Así que empecemos.
En PowerPlatform y en general en la programación es una buena práctica trabajar en un entorno de desarrollo (DEV), después pasar los desarrollos a otro de test (UAT) donde se prueban y si todo funciona correctamente pasarlo a producción (PRO).
Para pasar estos desarrollos de un entorno a otro usaremos soluciones (ya sea a mano o con una pipeline), que pueden ser administradas o NO administradas. Como el objetivo de este artículo no es explicar las soluciones si no ver fallos típicos al desplegar y como arreglarlos, solo diré que las soluciones NO administradas son las que deberíamos usar en DEV y donde podemos modificar sus elementos y las NO administradas las que deberíamos usar en UAT y PRO y donde NO deberíamos modificar sus elementos (ya que se generaría una capa no administrada por encima).
Primer error típico. Faltan dependencias.
¿Qué es esto? Pues como su propio nombre indica significa que falta algún elemento necesario. Pongamos un ejemplo.
Creas una Aplicación que se conecta a 100 tablas de DV. Si tanto la App como las tablas están en la misma solución no deberías tener problemas para subir el desarrollo de DEV a UAT. Pero puede ser que lo tengas en soluciones separas, lo cual, es una buena práctica, ya que ayuda a mantener todo más organizado (por ejemplo, las tablas por un lado y las aplicaciones por otro) y reduce los tiempos de despliegue.
Ya que, si tenemos una canvas app que se conecta a 100 tablas y cambiamos un color en un texto de la aplicación, subir la solución solo con la canvas puede llevarnos 1 minuto, pero subir una solución con la app + las 100 tablas podría llevarnos 1h, una barbaridad para un cambio tan pequeño.
Por tanto vemos que separar los elementos en soluciones más pequeñas es bueno, pero siempre que se haga de manera lógica, pues si no, podríamos tener problemas de dependencias. Como voy a mostrar ahora.
Supongamos que tenemos 2 soluciones. La solución 1 con la aplicación y la solución 2 con las tablas. Si intentamos subir la solución con la aplicación primero, nos dará un error de dependencias, puesto que la aplicación se conecta a esas 100 tablas que en UAT no están, Como solventamos esto, sube primero las tablas y luego sube la aplicación
¿Fácil verdad? Aunque no lo es tanto cuando tienes decenas de variables de entorno, apps, flujos, scripts, tablas, etc. Pero entendiendo esto y leyendo los errores que da el sistema seguro que podrás solucionarlo.
Segundo error típico. Nombres iguales
Seguramente no te hayas planteado como funciona el tema de los despliegues, pero si miras el historial de despliegues veras que cuando subes una versión nueva de una solución se producen una serie de pasos.
Qué no son más que añadir los cambios nuevos y luego borrar los viejos. Y aquí el orden es muy importante como vamos a ver en este ejemplo.
Quieres cambiar un campo llamado Comunidad_Autónoma de tipo String por un campo de tipo optionSet. Pero DV no permite cambiar el tipo de campo, por lo que deberás borrar el campo y crear otro. Intentas borrarlo y… ERROR hay dependencias. Vale, fácil, ves donde se usaba ese campo y lo quitas, borras el campo y ahora sí se ha borrado, perfecto.
Creas el campo nuevo, lo añades en los lugares donde se usaba el antiguo. Subes la solución y… ERROR además relacionado con el campo Comunidad_Autónoma. Pero ¿Cómo es esto posible si te has asegurado de que no haya dependencias?
Como he escrito antes al subir una solución primero se crea y luego se borra, por tanto si has creado un campo con el mismo nombre, su nombre interno será el mismo y en PowerPlatform eso no se permite. Para ello tienes 2 soluciones.
1 SOLUCIÓN RÁPIDA
Al crear el campo nuevo le pones un nombre distinto y luego le cambias el nombre para mostrar para que sea el mismo. Problema, el nombre lógico (el que se pone al crearse, sin espacios, sin tildes, todo en minúsculas, etc.) será distinto y si ese campo se usaba o en otros sitios pueden darse errores que, aunque no hayan saltado como dependencias, están ahí, por lo que no lo recomiendo si no estás muy seguro de donde se está usando ese campo.
2 SOLUCIÓN CON EL MISMO NOMBRE
En este caso primero deberás borrar el campo y sus dependencias en todos los entornos y luego subir el campo nuevo. IMPORTANTE cuando digo borrar el campo de todos los entornos no me refiero a ir a DEV, UAT y PRO y borrarlo (ya que si la solución es administrada generaríamos capas no administradas). Si no a borrarlo en DEV subir la solución sin ese campo a UAT y a PRO. Luego añadirlo el campo nuevo a DEV y volver a subir esa solución a UAT y PRO. Ahora como ya no existe ningún campo con ese mismo nombre, no te debería dar ningún error.
Y eso es todo. Espero que este artículo te haya sido de ayuda. Un saludo.