Parece que al fin ha llegado el día y todos los nuevos proyectos de LCS traen de serie entornos Tier 2+ de tipo self-service. Si quieres saber un poco más acerca de ellos puedes leer este post que escribí sobre los entornos service fabric/self-service en Microsoft Dynamics 365 for Finance and Operations.

Los dos últimos proyectos que he empezado están en self-service y también hemos tenido la migración de un cliente que estaba en la infraestructura normal. Así que ya es hora de que os avise sobre una cosa terrible…


Flujo de actualización

Entornos normales

Todos sabemos cómo se hace una actualización en los entornos normales . Creamos un Deployable Package con nuestro código (o un update de versión) , lo aplicamos a un entorno UAT desde LCS, lo marcamos como release candidate y, finalmente, aplicamos el paquete al entorno de producción. Estamos aplicando un paquete.

Digamos que tenemos un entorno sandbox y durante el fin de semana le metemos una actualización de versión. Cuando termina lo podemos marcar como release candidate para aplicar más tarde a producción. Durante la semana aplicamos otros DPs con cambios de código y los pasamos luego a producción. El siguiente fin de semana aplicamos el DP de subida de versión que aplicamos el fin de semana anterior y ya tenemos producción actualizado con nuestro código y la nueva versión.

Entornos Self-service

¿Qué pasaría si hiciéramos eso mismo en un entorno self-service? Bueno, que el día después de aplicar la subida de versión a prod nos lo pasaríamos muy bien! Nada muy dramático pero pasarías un par de horitas malas.

Si leíste mi anterior post sobre los entornos self-service ya sabrás que con los nuevos despliegues primero actualizamos un entorno sandbox igual que hacemos ahora, y cuando termina seleccionamos ese entorno para promocionarlo a producción. Cuando desplegamos un DP en UAT le damos un nombre que luego seleccionamos para aplicar los cambios a producción. ¡El estado del entorno sandbox pasa a ser el nuevo entorno de producción! Con el mismo código y versión que tenga.

Por ejemplo:

  1. Domingo: aplicamos la actualización a la versión 10.0.9 al entorno UAT. Lo llamamos AAS10.0.9Update.
  2. Martes: aplicamos un DP con código al entorno PreProd. Lo llamamos AASCode01. No actualizamos UAT.
  3. Martes: aplicamos el estado AASCode01 de PreProd al entorno de  producción.
  4. Domingo: el siguiente fin de semana, después de testear la nueva versión, seleccionamos el estado AAS10.0.9Update que desplegamos en UAT para aplicar a producción.

El lunes, después de actualizar prod a la 10.0.9 tendremos un entorno de produccion con el mismo estado que el entorno de UAT en el paso 1.

¿Por qué? Porque, como dije, lo que hacemos es promocionar estados de un entorno, no aplicamos deployable packages a producción. Cuando le hacemos un update a un entorno sandbox y le damos un nombre, estamos creando una imagen de ese estado en ese momento que se usará como el nuevo entorno de producción.

¿Y One Version?

La pasada semana del 17 de febrero los entornos self-service recibieron la opción de actualizaciones automáticas. Con la funcionalidad activada los entornos entran en la misma cadencia de actualización que un proyecto de LCS normal y hay que tener en cuenta la forma en que se pasan cambios a producción.

En resumen, sed cuidadosos con esto o acabaréis con un pequeño dolorcillo de cabeza y una subida a producción en horas de trabajo del cliente, pero por lo menos no tendréis que esperar 5 horas a que empiece el despliegue porque es un entorno self-service!

¡Suscríbete!

Recibe un correo cuando se publique un nuevo post
Author

Microsoft Dynamics 365 Finance & Operations technical architect and developer. Business Applications MVP since 2020.

Write A Comment

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

ariste.info