Muchas veces, los desarrolladores nos encontramos en situaciones en las que tenemos que implementar/probar servicios de Microsoft Azure. Una manera de probar código y hacer todas las pruebas necesarias de forma segura es crear un entorno de pruebas dentro de Azure con un tenant de desarrollo.
El entorno de pruebas es un escenario idóneo para implementar y probar código antes de ejecutarlo en un tenant de producción. Dispondrás de una suscripción para crear tu propio espacio aislado y desarrollar soluciones independientes, trabajar sobre Azure Active Directory (AAD), crear aplicaciones de Microsoft Teams, complementos de Office para Word, Excel, PowerPoint, Outlook, complementos de SharePoint, utilizar Microsoft Graph, SharePoint Framework y Power Apps, entre otros.
Vamos a seguir con este artículo basándonos en un ejemplo práctico.
Imaginemos que tenemos un cliente con una necesidad: desde su página web, los usuarios deben autenticarse y gestionar usando Azure Active Directory (AAD). Esto quiere decir que nuestro cliente dispone de un servicio de administración de acceso e identidades basado en la nube, el cual gracias a nuestro tenant de desarrollo podremos replicar (en mayor o menor medida) al entorno de nuestro cliente de una forma simple. También podremos iniciar la implementación y testing de una forma ágil, realista y segura.
Para crear un entorno de pruebas debemos acceder desde este link e ingresamos en Microsoft 365 Developer. Hacemos click en “Join now”, rellenamos los datos que se nos solicita, y una vez nos hayamos registrado dispondremos de un tenant de desarrollo con 25 licencias de prueba.
Si entramos en nuestro espacio de Office, disponemos de todas las Apps y servicios de prueba disponibles, pero nosotros nos vamos a centrar en la sección Admin, desde donde podemos acceder a la sección de administración de nuestro AAD.
Cuando hacemos click en Admin, nos redirige a la sección de administración para nuestro tenant de desarrollo, con los usuarios y grupos ya existentes creados automáticamente en el momento de la creación de dicho entorno y con la posibilidad de dirigirnos a nuestro AAD.
En el Admin Center de AAD disponemos de un Active Directory de prueba ya configurado con usuarios y grupos de ejemplo para empezar nuestra implementación y testing.
Siguiendo con nuestro ejemplo, ahora que ya disponemos de nuestro AAD de prueba, podemos centrarnos en la implementación de la autenticación y gestión de usuarios vía web usando el AAD de prueba.
Para dicha implementación usaríamos Microsoft Graph. Microsoft Graph es una API para web REST que permite tener acceso a los recursos del servicio Microsoft Cloud, servicio disponible desde nuestro entorno de test. Microsoft Graph es la puerta de enlace a los datos y la inteligencia de Microsoft 365. En relación con este ejemplo, podríamos usar esta API para obtener los usuarios de la organización, los tokens de acceso, los datos de un usuario en cuestión, su grupo y CRUD de usuarios/grupos, entre otros tipos de información.
Una vez hemos hablado de Microsoft Graph (que acabamos de describir en el apartado anterior), Graph Explorer es una herramienta que permite realizar/cumplir cómodamente solicitudes de REST API, ver las respuestas y obtener el código correspondiente para usar en la implementación del proyecto.
Encuentra más información sobre Graph Explorer en los documentos oficiales para desarrolladores de Microsoft.
Los entornos de prueba son clave para testear nuevos servicios a implementar usando la estructura de Azure. Recalco la palabra “testear”. Un entorno de pruebas, al final del día, no será capaz de replicar todos los escenarios/fallos a los que se puede enfrentar nuestra solución, por lo que es muy importante tener algo en mente: un entorno de prueba es y debe de ser siempre el primer paso hacia una meta concreta, el despliegue completo de una solución o, como mínimo, explorar las mejoras que podemos hacer para el futuro, ya sea en el proceso o nuestra aplicación.
Si nunca pasamos del entorno de pruebas, no avanzaremos en la dirección que toda empresa del sector debe. Al final del proceso, siempre debemos obtener un resultado.
Si quieres leer un poco más sobre Graph, aquí tienes el enlace, en él encontrarás además códigos de ejemplo para varias tecnologías que puedes usar como base durante la implementación.