Una lista de tareas es un buen punto de partida para practicar NoSQL y automatización. El problema es sencillo de comprobar: creo una tarea en el navegador, la marco como hecha y vuelvo a abrir la aplicación. Si el estado se conserva, puedo seguir el recorrido desde la interfaz hasta la base de datos y comprobar qué parte del despliegue permite que todo funcione en Azure.
Esta es la experiencia del equipo para la Actividad Grupal 01 de Base de Datos II en la Universidad Privada de Tacna. El código está disponible en el repositorio público del proyecto.
1. De la interfaz a un documento en Cosmos DB
La interfaz vive en wwwroot. Desde ahí, el navegador usa la API de ASP.NET Core (.NET 10) para crear, listar, completar y eliminar tareas. La aplicación agrupa las rutas bajo /api/tareas, y TareasRepo concentra el acceso a Azure Cosmos DB for NoSQL mediante el SDK de .NET.
Cada tarea se representa como un documento. Este ejemplo ilustra los campos del modelo:
{ "id": "53316b1d-b681-41cd-8b37-079be264189f", "titulo": "Revisar el despliegue", "hecha": false, "fecha": "2026-10-24T03:31:05Z" } El contenedor tareas de la base tareasdb usa /id como clave de partición. Eso permite que el repositorio busque una tarea con su identificador y su clave de partición en una lectura puntual. La lista completa se consulta aparte, ordenada por fecha descendente. Así, la operación de abrir una tarea y la de listar todas tienen recorridos distintos en el código.
2. Terraform prepara Azure y GitHub Actions publica la aplicación
La automatización está separada en dos flujos dentro de .github/workflows:
| Flujo | Qué hace | Cuándo se ejecuta |
|---|---|---|
infra.yml | Inicializa y valida Terraform, y aplica la configuración de infra/main.tf. Esta define los recursos de Cosmos DB y Azure App Service. | Al enviar a main cambios en infra/ o en el propio flujo. También admite ejecución manual. |
deploy.yml | Prepara .NET 10, genera el paquete Release con dotnet publish, inicia sesión en Azure, despliega en App Service y consulta /health. | Al enviar a main cambios en src/ o en el propio flujo. También admite ejecución manual. |
En una primera instalación, la infraestructura debe estar lista antes de publicar el código. Después, un cambio en la aplicación puede lanzar su propio despliegue. El estado de Terraform se configura en Azure Storage. GitHub Actions obtiene las credenciales de Azure desde los secretos del repositorio, y Terraform configura la conexión a Cosmos DB en App Service.
Las ejecuciones de GitHub Actions y las capturas del repositorio documentan ambas etapas.
3. Comprobación en la nube
La aplicación se publicó en Azure App Service. En las evidencias del despliegue se ve cómo se crea una tarea, se marca como completada y se elimina. La respuesta de /api/tareas permite revisar los documentos devueltos por la API. La ruta /health devuelve el estado de la aplicación, la base utilizada y el número de tareas que se pudieron leer.
La URL corresponde al despliegue documentado. Durante la preparación de este artículo no pude verificar que la instancia siguiera respondiendo. Las capturas y el video conservan el resultado de la prueba en Azure.
