Borrado de Paquetes / Modelos en entornos Sandbox (SAT)

Buenas, hoy voy a escribir este post basado en una experiencia vivida hace unos días, más que nada porque es una de esas cosas que no suelen ocurrir a menudo y siempre está bien tenerlo apuntado en algún sitio para la próxima, y oye, si puedo ayudar a alguien que se encuentre con la misma duda o problema, pues bienvenido sea 🙂 .

En resumidas cuentas, se trata de la necesidad de borrar un paquete que ha sido instalado en un entorno sandbox de UAT, pero, antes de adentrarnos más en el tema, voy a hablar de algunos conceptos por si alguno de vosotros no los conoce:

Modelo: Un modelo es un grupo de elementos (metadatos y código fuente) que generalmente constituyen una solución de software distribuible e incluyen personalizaciones de una solución existente y siempre pertenecerá a una agrupación mayor, un paquete. Hay que tener bien claro que un modelo solo existe en tiempo de diseño (Visual Studio), después siempre se trabajará con paquetes.

Paquete/Package: Un paquete es una unidad mínima de despliegue y compilación de uno o más modelos. Incluye los metadatos del modelo, binarios y otros recursos asociados. Uno o más paquetes se pueden empaquetar en un paquete desplegable (Deployable Package), que es el objeto utilizado para la implementación en entornos de testing o producción.

Entorno SAT (Standard Acceptance Test): Los entornos SAT son aquellos entornos que se encuentran bajo la suscripción de Microsoft y que son generalmente utilizados como entornos de UAT (User Acceptance Test) o Golden entre otros. Estos entornos jamás tendrán el código fuente de la aplicación (ficheros XML), aunque si que podemos acceder (de momento) a ellos vía RDP y ver que tiene la misma estructura de carpetas de la aplicación (AOSService, Local Packages Directory…), aunque solo contendrá los binarios (DLLs), es decir, contiene la aplicación ya compilada, pero no nuestro código y objetos.

Ahora que ya hablamos el mismo idioma, este es el punto de partida:

Estamos ahora mismo en plena fase de desarrollo de uno de nuestros proyectos de #MSDyn365FO, y como ya sabéis, nos encontramos con una nueva forma de trabajar, por lo tanto, seguimos en proceso de perfeccionamiento de nuestras propias «best practices» en cuanto a la nomenclatura de modelos, variables, objetos… (obviamente, siempre siguiendo las recomendaciones de Microsoft).

Pues bien, partimos del siguiente escenario: Tenemos un paquete/modelo ya creado, al que llamamos AXZPrimerPaquete desde un inicio, en el que hemos creado una serie de clases y objetos. Este modelo fue creado «deprisa y corriendo» por motivos que no vienen al caso antes de comenzar la fase de desarrollo, e incluso antes de cerrar la definición de la estructura de paquetes y modelos a utilizar. Una vez creado, también lo desplegamos vía LCS en el entorno de UAT/SAT. En fin, que cuando ya estamos avanzando en todo esto, decidimos cambiar el nombre a este modelo para seguir las guías de nomenclatura definidas en su momento, por lo que creamos un nuevo package llamado AXZFirstPackage (¡sorpersa!), movemos los objetos de uno a otro y eliminamos el primero, dejando todo compilado y listo para seguir trabajando. Hasta aquí todo perfecto.

¿Qué problema nos encontramos entonces?

Seguimos trabajando en nuestros distintos entornos de desarrollo, todos están sincronizados con VSTS, todo funciona perfecto, por lo que hacemos la primera subida de desarrollos a UAT. Lanzamos la build desde VSTS, todo compila y funciona a la perfección, pero justo cuando lanzamos el despliegue al entorno de UAT… ¡¡¡Boooom!!!, nos encontramos con el siguiente error:

Exception calling «CreateRuntimeProvider» with «1» argument(s): «Runtime metadata is invalid because the same metadata artifact has been defined in multiple assemblies. \nFirst 10 conflicting names: AXZDoSomethingCool.

Tras un poco de investigación detectamos el problema:

Cuando generas el deployable package, este incluye todos los paquetes que han sufrido modificaciones desde la última build, pero en ningún momento aparece nada sobre el borrado de los mismos. Esto provoca que, el antiguo paquete AXZPrimerPaquete siga existiendo en el entorno de UAT con todos sus objetos, y cuando intentamos instalar las nuevas modificaciones, el sistema se encuentra con que queremos crear un nuevo paquete llamado AXZFirstPackage que contiene una serie de objetos que ya existen en otro modelo distinto, por lo que LCS nos dice: «ay amigo…, ¡por ahí si que no paso!».

Esto solo aplica al borrado de paquetes completos, puesto que si borramos un modelo dentro de un paquete (recordad que un paquete puede tener más de un modelo) con realizar la subida del paquete actualizado y compilado el sistema ya se encargaría de borrar el modelo en cuestión y dejarlo todo bien.

¿Cómo solucionamos este entuerto?

Pues…, a ver…, las malas lenguas dicen que intentamos borrar (con éxito😬😇) el paquete directamente accediendo al entorno de UAT…, pero, realmente lo que hicimos fue investigar un poco 🤞🏻 y dar con la solución gracias a la maravillosa comunidad con la que contamos. Así que, si os ocurre algo similar a lo que nos ocurrió a nosotros, aquí os dejo la receta mágica para solventar el problema:

1. Borrar todos los componentes del modelo y crear un paquete desplegable (deployable package) del modelo/paquete.
2. Crear un fichero de texto llamado «ModuleToRemove.txt» y meterlo dentro de la carpeta AOSService\Scripts
3. En el fichero de texto poner el nombre del paquete que queremos eliminar (AXZPrimerPaquete)
4. Subir el deployable package al biblioteca de activos de LCS
5. Aplicar el paquete en el entorno de UAT.

Espero que os sirva de ayuda tanto como nos sirvió a nosotros…, y si no tenéis que utilizarlo nunca, mucho mejor!

Hasta la próxima!