DEV Community: MILTON H FLORES CHINO

Pruebas de API con Newman: de 0 a 121 aserciones en un pipeline que despliega en Vercel

MILTON H FLORES CHINO — Sun, 15 Nov 2026 07:08:05 +0000

Actividad Grupal 2: API Testing: Calidad y Pruebas de Software (SI-784), Universidad Privada de Tacna.
Autores: Milton H. Flores Chino y Manuel Andre Dongo Palza.

Repositorio: https://github.com/miltom123/si784-grupal2-api-testing
API en producción: https://si784-api-envios.vercel.app
Video (≤ 5 min): https://youtu.be/XAjGJB6H0Fw

El problema

Probar una API "a mano" con Postman sirve el primer día. Al tercer cambio ya nadie repite los 20 clics, y los errores llegan a producción. Para este trabajo nos pusimos una regla simple: ningún cambio llega a producción si no pasan las pruebas, y las mismas pruebas se repiten contra la URL pública después de desplegar.

Para eso construimos una API pequeña y la probamos con dos herramientas:

Newman, la versión de línea de comandos de Postman. Cubre las pruebas funcionales y de contrato, y es el tema de este artículo.
k6 para las pruebas de carga. Mi compañero Manuel lo explica en su artículo.

La API bajo prueba

Es una API REST sin estado que cotiza envíos entre departamentos del Perú. Está hecha con Node.js 20 y Hono.

Método	Ruta	Qué hace
GET	`/v1/health`	Estado y versión
GET	`/v1/departamentos?zona=`	25 departamentos con su zona
GET	`/v1/departamentos/{codigo}`	Un departamento (404 si no existe)
POST	`/v1/cotizaciones`	Calcula el precio del envío
GET	`/v1/openapi.json`	Contrato OpenAPI 3

Las reglas de negocio tienen suficientes detalles para que valga la pena probarlas:

Tarifa base de S/ 8 en la misma zona y S/ 12 entre zonas.
S/ 2.50 por cada 0.5 kg iniciado.
Recargo de selva, servicio express ×1.6 y seguro del 1 %.
IGV del 18 %.

Los errores siempre tienen la misma forma:

{ "error": { "code": "VALIDACION", "message": "...", "campo": "pesoKg" } }

Pruébala tú mismo:

curl -X POST https://si784-api-envios.vercel.app/v1/cotizaciones \
  -H "Content-Type: application/json" \
  -d '{"origen":"TAC","destino":"ARE","pesoKg":2.3}'

Por qué Newman

La colección es un archivo JSON versionado en el repositorio, junto al código que prueba.
Corre en cualquier CI con npx newman run, sin abrir Postman.
Tiene reporteros de consola, JUnit y HTML (newman-reporter-htmlextra), así los resultados quedan como artefactos del pipeline.
La misma colección se ejecuta contra localhost y contra producción. Solo cambia la variable baseUrl.

Diseño de la colección: 22 peticiones en 4 carpetas

En vez de editar a mano un JSON de 1000 líneas, la colección se genera con un script (generar-coleccion.mjs) a partir de una lista legible de casos. Las aserciones que se repiten se escriben una sola vez:

const cotizacionValida = [
  status(200),
  `pm.test('cumple el esquema de cotización', () => pm.response.to.have.jsonSchema(${s(esquemaCotizacion)}));`,
  `pm.test('IGV es el 18 % del subtotal', () => { const d = pm.response.json().desglose; pm.expect(d.igv).to.be.closeTo(d.subtotal * 0.18, 0.011); });`,
  `pm.test('total = subtotal + IGV', () => { const r = pm.response.json(); pm.expect(r.total).to.be.closeTo(r.desglose.subtotal + r.desglose.igv, 0.011); });`
];

Las cuatro carpetas siguen técnicas clásicas de diseño de casos:

Salud y catálogo. Health check, listado, filtro por zona en minúsculas, zona inválida (400) y departamento inexistente (404).
Cotizaciones válidas (partición de equivalencia). Misma zona, distinta zona con express, y selva con valor declarado. Cada caso verifica montos exactos: por ejemplo, Tacna → Arequipa con 2.3 kg debe costar S/ 16.82.
Valores límite. 0.1 kg y 50 kg se aceptan; 0.09 kg, 50.01 kg y un valor declarado de 10 001 devuelven 422.
Errores y robustez. Campos faltantes, tipo incorrecto ("2" en lugar de 2), JSON mal formado (400), Content-Type: text/plain (415) y ruta inexistente (404).

Tres trucos que valen la pena

1. Validar el contrato con JSON Schema, no solo el status:

pm.test('el error sigue el contrato', () => pm.response.to.have.jsonSchema(esquemaError));
pm.test('señala el campo pesoKg', () => pm.expect(pm.response.json().error.campo).to.eql('pesoKg'));

2. Aserciones a nivel de colección, que se ejecutan después de cada petición:

pm.test('responde en menos de 3 s', () => pm.expect(pm.response.responseTime).to.be.below(3000));
pm.test('responde JSON', () => pm.expect(pm.response.headers.get('Content-Type')).to.include('application/json'));

3. Comparar dos respuestas con pm.sendRequest. Probamos una propiedad del negocio, "express siempre cuesta más que estándar", lanzando una segunda petición desde el script de pruebas:

pm.sendRequest({ url: pm.environment.get('baseUrl') + '/v1/cotizaciones', method: 'POST', /* ... servicio: 'express' */ },
  (err, res) => pm.test('express > estándar', () => {
    pm.expect(res.json().total).to.be.above(pm.response.json().total);
  }));

Ejecutarla en local

npm install
npm start          # API en http://localhost:3000
npm run test:api   # newman + reportes HTML y JUnit en reports/

│              requests │   22 │   0 │
│            assertions │  121 │   0 │

El pipeline: probar → desplegar → volver a probar

El workflow de GitHub Actions (ci-cd.yml) tiene tres jobs encadenados:

git push a main
   └─▶ Job 1: unitarias + Newman + k6 smoke (contra localhost)
         └─▶ Job 2: vercel deploy --prod
               └─▶ Job 3: Newman + k6 (contra la URL pública)

Pruebas locales. Levanta la API dentro del runner y corre las pruebas unitarias (node:test), Newman y un smoke de k6.
Despliegue. Usa la CLI de Vercel con el secreto VERCEL_TOKEN. El job obtiene el dominio de producción desde la API de Vercel y lo expone como output.
Pruebas contra producción. Recibe esa URL y ejecuta la misma colección:

- name: Pruebas funcionales con Newman (producción)
  run: |
    npx newman run tests/postman/envios.postman_collection.json \
      --env-var baseUrl="$BASE_URL" \
      --reporters cli,htmlextra,junit,json \
      --reporter-htmlextra-export reports/newman-produccion.html

Con jq, el resultado JSON de Newman se convierte en una tabla del resumen de la ejecución. Así se ve sin descargar nada. Los reportes HTML quedan como artefactos.

Resultados en producción

	Ejecutadas	Fallidas
Peticiones	23 (22 + 1 `sendRequest`)	0
Aserciones	121	0

Mientras desarrollábamos, la propia corrida de Newman detectó una aserción de Content-Type que se serializaba mal al generar la colección. Por eso las aserciones exactas sobre montos usan valores redondeados a centavos y closeTo donde hay cálculos con decimales.

Lecciones

Genera la colección desde código. Los cambios se revisan en un diff legible y nadie edita a mano el JSON exportado.
Prueba el contrato, no solo el status. Un 200 con un campo de menos también es un bug.
Repite las pruebas después de desplegar. Lo que pasa en localhost puede fallar en la plataforma, por enrutamiento, cabeceras o variables de entorno.
Valores límite y errores fueron la mitad de los casos y donde aparecieron más sorpresas.

¿Y el rendimiento? Eso lo cubre k6. Lo explica mi compañero Manuel en su artículo; mientras tanto, el script está en tests/k6/carga.js.

Respaldo cifrado y restauración verificada para Azure Cosmos DB con GitHub Actions

MILTON H FLORES CHINO — Sun, 15 Nov 2026 01:23:31 +0000

Actividad Grupal 02-U2: NoSQL Backup Strategy · Base de Datos II (SI-783) · Universidad Privada de Tacna
Autor: Milton H. Flores Chino · Equipo: Yerry Maycol Tarqui Collatupa y Milton H. Flores Chino

Una copia de seguridad solo vale si se puede restaurar. Con esa idea armamos una estrategia de respaldo para una base NoSQL en Azure Cosmos DB: una app de productos en ASP.NET Core, una herramienta propia (BackupTool) que genera respaldos cifrados en Azure Blob Storage, y flujos de GitHub Actions que respaldan todos los días y restauran con verificación. Al final borramos todos los datos a propósito y los recuperamos.

Repositorio público: https://github.com/Yerrytc/tg2-nosql-backup-yerrytc
Aplicación publicada (Azure App Service): https://app-tg2-backup-yerrytc.azurewebsites.net
Ejecuciones de GitHub Actions: https://github.com/Yerrytc/tg2-nosql-backup-yerrytc/actions
Video (4 min 32 s): https://youtu.be/zM_CLWn9cGs

Tres capas de protección

Capa	Cómo se implementa	Qué cubre
Respaldo nativo	Cosmos DB con política `Periodic`: cada 240 min, retención de 48 h (Terraform)	Recuperación administrada por Azure
Respaldo lógico propio	BackupTool exporta los documentos, los comprime, los cifra y los sube a Blob Storage	Copias bajo control del equipo, restaurables en otro contenedor
Retención	Política de ciclo de vida de Storage: borra respaldos con más de 30 días	Evita acumular copias viejas

La segunda capa es la que construimos nosotros, y es la que explico en detalle.

El formato del respaldo

BackupTool lee todos los documentos del contenedor productos, les quita los metadatos internos de Cosmos DB (_rid, _self, _etag, _attachments, _ts) y los guarda en un JSON con un manifiesto: versión, fecha, base, contenedor y cantidad de documentos. Antes de comprimir calcula el SHA-256 de ese JSON, que sirve como huella para comparar al restaurar.

Luego comprime con GZip y cifra con AES-256-GCM. La clave no se guarda: se deriva de una frase secreta con PBKDF2-SHA256 (200 000 iteraciones) y una sal aleatoria por archivo.

byte[] Cifrar(byte[] d, string clave)
{
    var sal = RandomNumberGenerator.GetBytes(16);
    var nonce = RandomNumberGenerator.GetBytes(12);
    var k = Rfc2898DeriveBytes.Pbkdf2(clave, sal, 200000, HashAlgorithmName.SHA256, 32);
    var c = new byte[d.Length];
    var tag = new byte[16];
    using var aes = new AesGcm(k, 16);
    aes.Encrypt(nonce, d, c, tag);
    return Encoding.ASCII.GetBytes("TG2B").Concat(sal).Concat(nonce).Concat(tag).Concat(c).ToArray();
}

Así queda cada archivo .json.gz.enc:

Bytes	Contenido
0–3	Firma `TG2B`
4–19	Sal de PBKDF2
20–31	Nonce de AES-GCM
32–47	Etiqueta de autenticación
48 en adelante	Datos comprimidos y cifrados

AES-GCM no solo oculta los datos: si alguien modifica un solo byte del archivo, el descifrado falla. Por eso un respaldo alterado nunca se restaura en silencio.

El archivo se sube al contenedor privado backups con la cantidad de documentos y el SHA-256 como metadatos del blob.

Restaurar y verificar

La restauración hace el camino inverso: descarga el respaldo indicado (o el más reciente), lo descifra, lo descomprime, recalcula el SHA-256 y escribe los documentos con UpsertItemAsync. Al final cuenta los documentos del contenedor de destino y lo compara con el manifiesto:

if (docs.Count != esperado || total < esperado)
    throw new Exception("La verificacion fallo: se esperaban " + esperado + " documentos");
Console.WriteLine("VERIFICACION OK: " + esperado + " documentos recuperados");

Si no coincide, el proceso termina con error y el flujo de GitHub Actions queda en rojo. Por defecto restaura en un contenedor nuevo (productos_restaurado), así se puede revisar la copia sin tocar los datos en uso.

Automatización con GitHub Actions

El repositorio tiene seis flujos: ci, infra (Terraform), deploy, backup, restore y desastre. El de respaldo corre solo todos los días:

on:
  schedule:
    - cron: '17 10 * * *'   # 10:17 UTC = 5:17 a. m. en Perú
  workflow_dispatch:

En cada ejecución inicia sesión en Azure, obtiene la llave de Cosmos DB y la cadena de conexión de Storage con la CLI, las enmascara en los registros (::add-mask::) y ejecuta BackupTool. La frase de cifrado es el secreto BACKUP_PASSPHRASE del repositorio, así que ninguna llave está en el código.

La prueba: respaldar, destruir y recuperar

1. Datos iniciales. La app publicada en Azure tenía 6 productos guardados en Cosmos DB.

2. Respaldo. backup.yml terminó en 42 s: 6 documentos, archivo productos-20261026-015040.json.gz.enc de 515 bytes y SHA-256 a719492f…dfdac08.

El archivo cifrado quedó en el contenedor privado backups:

3. Desastre simulado. desastre.yml, que solo corre si se escribe la confirmación BORRAR, eliminó todos los productos. La app quedó vacía:

4. Recuperación. restore.yml con el último respaldo y destino productos terminó en 40 s. El SHA-256 coincidió con el del respaldo original y la verificación pasó:

Los 6 productos volvieron a aparecer en la app:

Lo que aprendí

Un respaldo sin prueba de restauración es una suposición. La verificación por cantidad y SHA-256 convierte la recuperación en algo comprobable.
Cifrar antes de subir protege los datos aunque alguien acceda al contenedor, y AES-GCM además detecta archivos alterados.
Dos vías de recuperación (nativa de Azure y lógica propia) evitan depender de una sola.
Automatizar con cron quita el factor humano: el respaldo ocurre aunque nadie se acuerde.
Todo funciona con Cosmos DB serverless, App Service F1 y una cuenta de Storage pequeña, con costo mínimo.

Cumplimiento de la actividad

Requisito	Dónde
Base NoSQL	Azure Cosmos DB (API NoSQL)
Repositorio público	https://github.com/Yerrytc/tg2-nosql-backup-yerrytc
Despliegue por automatización	GitHub Actions + Terraform (`infra.yml`, `deploy.yml`, `backup.yml`, `restore.yml`)
Nube pública	Microsoft Azure: App Service, Cosmos DB y Blob Storage
Video ≤ 5 min	https://youtu.be/zM_CLWn9cGs

Reproducir un error 500 en PHP con Nuclei y GitHub Actions

MILTON H FLORES CHINO — Sun, 15 Nov 2026 00:54:47 +0000

Actividad Grupal 1 · Vulnerability Scanning Tools · Calidad y Pruebas de Software (SI-784) · Universidad Privada de Tacna
Autor: Milton H. Flores Chino · Equipo: Milton H. Flores Chino y Manuel Dongo Palza

Abrigando Corazones es una aplicación PHP de una campaña solidaria en Tacna. En la actividad de Calidad y Pruebas de Software, revisamos qué ocurre cuando el enrutador recibe un valor con un tipo distinto del esperado. Usamos Nuclei para convertir ese caso en una prueba repetible y llevarla al workflow del proyecto.

Repositorio público: https://github.com/manuelandredp-gif/abrigando-corazones
Aplicación pública: https://abrigandocorazones.site.je/impacto?i=1
Workflow de escaneo y despliegue: deploy-infinityfree.yml

Preparar el entorno de prueba

La última comprobación local se hizo el 14 de noviembre de 2026 con el commit 4dffd5e, PHP 8.4.27 y Nuclei 3.11.1. La copia se ejecutó en 127.0.0.1:8788, con correo y métricas desactivados. La web pública se usó como referencia del proyecto. Las peticiones de prueba se hicieron al servidor local.

Ejecutar el escaneo

La plantilla de Nuclei compara dos peticiones HTTP. Primero verifica que la ruta normal funcione. Después envía el parámetro url como arreglo. La coincidencia exige que ambas respuestas cumplan la condición status_code_1 == 200 && status_code_2 == 500.

Petición en el servidor local	Resultado
`GET /contacto`	HTTP 200. Se cargó la página de contacto.
`GET /?url%5B%5D=contacto`	HTTP 500. El parámetro `url` llegó como arreglo.

Nuclei registró una coincidencia. En el log de PHP apareció un TypeError en la línea 9 de app/core/Router.php. El enrutador pasa el valor de url directamente a trim(), que espera una cadena:

$rawUrl = isset($_GET['url']) ? trim($_GET['url'], '/') : '';

Ver la línea del enrutador revisada

Clasificamos el hallazgo como bajo en la plantilla porque la prueba demostró un error de servidor en esa petición, con alcance limitado al caso reproducido.

La corrección propuesta es comprobar el tipo de url antes de normalizarlo y devolver HTTP 400 al recibir un arreglo. La prueba de regresión debe mantener el 200 de la ruta válida y comprobar que desaparece el 500 en la entrada inválida.

Integrar Nuclei al flujo de publicación

El workflow empaqueta el commit, excluye la configuración local y verifica la sintaxis de PHP. Luego levanta la copia del paquete, ejecuta Nuclei y guarda resultados-nuclei.jsonl como artefacto de la ejecución. La preparación y el escaneo se verificaron localmente con 47 archivos PHP validados y un hallazgo reproducido.

La etapa de publicación se activa manualmente desde GitHub Actions. Está configurada para transferir el paquete a InfinityFree por FTP con TLS y comprobar en el servidor un marcador con el commit. La ejecución #2 quedó bloqueada por facturación en GitHub antes de iniciar el trabajo. La web ya estaba disponible en InfinityFree y la subida automatizada queda pendiente.

Conclusión

Lo más útil de la prueba fue poder relacionar una respuesta de la aplicación con una línea de código. La plantilla permite repetir esa comprobación cuando el equipo cambie el enrutador.

Construir y desplegar una app NoSQL con Azure Cosmos DB, Terraform y GitHub Actions

MILTON H FLORES CHINO — Sat, 14 Nov 2026 23:00:06 +0000

En el curso de Base de Datos II (Universidad Privada de Tacna) nos pidieron construir y desplegar una aplicación con una base de datos NoSQL, sin usar Redis, MongoDB, Neo4j ni Prometheus. Con mi compañero Yerry Tarqui elegimos Azure Cosmos DB (API NoSQL), una base de documentos JSON administrada, y armamos una app de tareas que se despliega sola en Azure cada vez que hacemos push.

Repositorio público: https://github.com/Yerrytc/tg1-nosql-tareas-yerrytc
App publicada: https://app-tg1-nosql-yerrytc.azurewebsites.net
Video (menos de 5 min): https://youtu.be/7J8stjhJkiA

¿Por qué Cosmos DB?

Es NoSQL de documentos: cada tarea se guarda como un JSON, sin esquema fijo.
Tiene nivel gratuito (1000 RU/s y 25 GB), suficiente para un proyecto académico.
Se consulta con una sintaxis parecida a SQL (SELECT * FROM c), así que la curva de aprendizaje es corta.
Se crea completamente desde Terraform, lo que nos permitió automatizar todo.

Arquitectura

Navegador -> Azure App Service (ASP.NET Core .NET 10) -> Azure Cosmos DB (API NoSQL)
                     ^
GitHub Actions: ci.yml (build + validate), infra.yml (Terraform), deploy.yml (dotnet publish)

Pieza	Tecnología
Backend y página web	ASP.NET Core minimal API (.NET 10)
Base de datos	Azure Cosmos DB, base `tareasdb`, contenedor `tareas`, partición `/id`
Infraestructura como código	Terraform (`azurerm` 4.x) con estado remoto en Azure Storage
Automatización	GitHub Actions
Nube pública	Azure App Service (plan F1 gratuito)

1. El modelo de datos

Un documento es una tarea. Cosmos DB necesita un id y una clave de partición; usamos el mismo id como partición porque cada tarea se lee y se escribe de forma independiente.

public class Tarea
{
    public string Id { get; set; } = Guid.NewGuid().ToString();
    public string Titulo { get; set; } = "";
    public bool Hecha { get; set; }
    public DateTime Fecha { get; set; } = DateTime.UtcNow;
}

En Cosmos DB queda así:

{ "id": "3f2c...", "titulo": "Desplegar con GitHub Actions", "hecha": false, "fecha": "2026-11-13T..." }

2. Conexión con el SDK de Cosmos DB

Instalamos el paquete Microsoft.Azure.Cosmos y, al arrancar, la app crea la base y el contenedor si no existen. El endpoint y la llave llegan por variables de entorno (Cosmos__Endpoint, Cosmos__Key), nunca están en el código.

var cfg = b.Configuration.GetSection("Cosmos");
var cli = new CosmosClient(cfg["Endpoint"], cfg["Key"], opt);
var db  = (await cli.CreateDatabaseIfNotExistsAsync(cfg["Database"] ?? "tareasdb")).Database;
var con = (await db.CreateContainerIfNotExistsAsync(cfg["Container"] ?? "tareas", "/id")).Container;

El repositorio usa las operaciones nativas de Cosmos DB:

public async Task<List<Tarea>> Listar()
{
    var q = c.GetItemQueryIterator<Tarea>("SELECT * FROM c ORDER BY c.fecha DESC");
    var r = new List<Tarea>();
    while (q.HasMoreResults)
        r.AddRange(await q.ReadNextAsync());
    return r;
}

public async Task<Tarea> Crear(Tarea t) =>
    (await c.CreateItemAsync(t, new PartitionKey(t.Id))).Resource;

3. La API

Método	Ruta	Qué hace
GET	`/health`	estado y cantidad de tareas
GET	`/api/tareas`	lista las tareas
POST	`/api/tareas`	crea `{ "titulo": "..." }`
PUT	`/api/tareas/{id}`	actualiza título o estado
DELETE	`/api/tareas/{id}`	elimina

La página wwwroot/index.html consume esa API para agregar, marcar y eliminar tareas.

4. Infraestructura como código con Terraform

infra/main.tf crea todo lo necesario en Azure:

resource "azurerm_cosmosdb_account" "db" {
  name              = "cosmos-tg1-yerrytc"
  offer_type        = "Standard"
  kind              = "GlobalDocumentDB"
  free_tier_enabled = true
  consistency_policy { consistency_level = "Session" }
  # ...
}

resource "azurerm_cosmosdb_sql_container" "tareas" {
  name                = "tareas"
  database_name       = azurerm_cosmosdb_sql_database.tareas.name
  partition_key_paths = ["/id"]
  # ...
}

resource "azurerm_linux_web_app" "app" {
  name = "app-tg1-nosql-yerrytc"
  site_config { application_stack { dotnet_version = "10.0" } }
  app_settings = {
    Cosmos__Endpoint = azurerm_cosmosdb_account.db.endpoint
    Cosmos__Key      = azurerm_cosmosdb_account.db.primary_key
  }
}

Lo interesante es que Terraform pasa la llave de Cosmos DB directamente a la configuración de la Web App, así que nadie tiene que copiarla a mano.

5. Despliegue automatizado con GitHub Actions

Tenemos tres flujos:

ci.yml: en cada push compila el proyecto y ejecuta terraform validate.
infra.yml: cuando cambia infra/, ejecuta terraform init y terraform apply con un service principal guardado en los secretos del repositorio.
deploy.yml: cuando cambia src/, publica la app y comprueba que responde.

- run: dotnet publish src/TareasApi/TareasApi.csproj -c Release -o publicar
- uses: azure/login@v2
  with:
    creds: ${{ secrets.AZURE_CREDENTIALS }}
- uses: azure/webapps-deploy@v3
  with:
    app-name: app-tg1-nosql-yerrytc
    package: publicar
- name: probar la aplicacion publicada
  run: |
    for i in 1 2 3 4 5 6 7 8 9 10; do
      if curl -fs https://app-tg1-nosql-yerrytc.azurewebsites.net/health; then exit 0; fi
      sleep 15
    done
    exit 1

El último paso es un smoke test: si /health no responde, el flujo falla y nos enteramos al instante.

6. Resultado en la nube

Los recursos quedan en un solo grupo de recursos de Azure, y desde el Data Explorer se ven los documentos JSON que guarda la app:

La app pública funciona en https://app-tg1-nosql-yerrytc.azurewebsites.net y /health responde:

{ "estado": "ok", "base_datos": "Azure Cosmos DB", "tareas": 4 }

Lo que aprendimos

Elegir bien la clave de partición es la decisión de diseño más importante en Cosmos DB. Para una app de tareas, /id reparte la carga de forma uniforme.
Los secretos no van en el código: Terraform los entrega a App Service como configuración y GitHub los guarda como secretos cifrados.
Automatizar desde el principio ahorra tiempo: después del primer terraform apply, cada cambio llega a producción con un simple git push.
El plan F1 gratuito se "duerme" tras un rato sin uso, por eso la primera petición puede tardar unos segundos.

Cumplimiento de la actividad

Requisito	Dónde
Repositorio público	https://github.com/Yerrytc/tg1-nosql-tareas-yerrytc
Despliegue por automatización	GitHub Actions (`ci.yml`, `infra.yml`, `deploy.yml`) + Terraform
Nube pública	Microsoft Azure (App Service + Cosmos DB)
Video ≤ 5 min	https://youtu.be/7J8stjhJkiA
BD NoSQL sin Redis/MongoDB/Neo4j/Prometheus	Azure Cosmos DB (API NoSQL)

Equipo: Yerry Maycol Tarqui Collatupa y Milton H. Flores Chino — Base de Datos II, Escuela Profesional de Ingeniería de Sistemas, Universidad Privada de Tacna.