Infraestructura técnica compartida para aplicaciones .NET sobre Azure.

APS-Framework actúa como organización de plataforma: proporciona librerías, workflows CI/CD y herramientas de IA disponibles para cualquier organización de producto. Apoyarse en estos recursos permite a los equipos centrarse en el desarrollo de negocio sin tener que mantener infraestructura técnica transversal propia.

Además, a través del sdk-mcp-server y su mecanismo de autodiscovery, cualquier organización puede incorporar asistencia con IA directamente en el entorno de sus desarrolladores: configurando el servidor con los topics de sus propios repositorios, los agentes de IA (GitHub Copilot, Claude…) acceden al contexto real del código — contratos, documentación y ejemplos — sin salir del IDE.

Cada organización puede también optar por mantener sus propios feeds de paquetes, workflows CI/CD o herramientas, ya sea como alternativa o como extensión de lo que ofrece este repositorio.

El feed de APS-Framework es público para todas las organizaciones de la plataforma. Para añadirlo como fuente en cualquier repositorio, agregar un nuget.config en la raíz:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="NuGet official package source" value="https://api.nuget.org/v3/index.json" />
    <add key="APS-Framework" value="https://nuget.pkg.github.com/APS-Framework/index.json" />
  </packageSources>
  <packageSourceCredentials>
    <APS-Framework>
      <add key="Username" value="x" />
      <add key="ClearTextPassword" value="%APS_NUGET_TOKEN%" />
    </APS-Framework>
  </packageSourceCredentials>
</configuration>

En CI, el secret APS_NUGET_TOKEN debe ser un Classic PAT con scope read:packages sobre APS-Framework, configurado como org secret en la organización consumidora.

Los workflows de APS-Framework/.github son referenciables directamente desde cualquier repositorio de cualquier organización sin necesidad de copiarlos:

jobs:
  ci:
    uses: APS-Framework/.github/.github/workflows/nuget-ci-publish.yml@main
    secrets: inherit

Cada organización puede también definir los suyos propios o extender los de APS-Framework adaptándolos a sus convenciones.

El sdk-mcp-server expone las librerías APS.* a agentes de IA (GitHub Copilot, Claude…) directamente desde el IDE, permitiendo consultar contratos, documentación y ejemplos de cualquier SDK sin salir del chat.

El servidor se instala una sola vez por máquina y descubre automáticamente cualquier repositorio que tenga un mcp-manifest.json en su raíz, independientemente de la organización a la que pertenezca. Cada repo de producto puede conectar sus propios repos junto con los de APS-Framework en una única sesión de asistencia.

npm install -g @aps-framework/sdk-mcp-server
sdk-mcp-server  # escucha en http://127.0.0.1:7512/mcp

Añadir .vscode/mcp.json en la raíz del repo consumidor. El ejemplo siguiente descubre los SDKs de APS-Framework, los repositorios propios de la organización de producto y excluye el repo actual para que no aparezca en su propia lista de tools:

{
  "servers": {
    "aps-framework": {
      "type": "http",
      "url": "http://127.0.0.1:7512/mcp?discovery=APS-Framework:sdk&discovery=mi-org:mi-topic&exclude=mi-org/nombre-repo-actual"
    }
  }
}

El parámetro discovery acepta uno o varios topics de GitHub por organización (org:topic1,topic2). Para incluir repos de varias organizaciones, repetir el parámetro tantas veces como sea necesario. El repo desde el que se trabaja debe excluirse siempre con &exclude=org/repo.

Referencia completa: sdk-mcp-server README.

Los paquetes se publican en GitHub Packages (https://nuget.pkg.github.com/APS-Framework/index.json) siguiendo un flujo de versiones con RC previo a estable:

El workflow nuget-ci-publish.yml gestiona todo el ciclo: resolución de dependencias internas entre paquetes del mismo repo, cálculo automático del número de RC, empaquetado, publicación, creación de tags y generación de GitHub Releases.

Ambos secrets se configuran a nivel de organización y se propagan automáticamente a todos los repos mediante secrets: inherit en el workflow caller. GITHUB_TOKEN (token automático del runner) no funciona para consumir paquetes de otros repositorios de la organización.

Cada repositorio debe incluir un nuget.config en la raíz con las fuentes de las que tiene dependencias reales:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="NuGet official package source" value="https://api.nuget.org/v3/index.json" />
    <add key="APS-Framework" value="https://nuget.pkg.github.com/APS-Framework/index.json" />
    <add key="mi-org" value="https://nuget.pkg.github.com/mi-org/index.json" />
  </packageSources>
  <packageSourceCredentials>
    <APS-Framework>
      <add key="Username" value="x" />
      <add key="ClearTextPassword" value="%APS_NUGET_TOKEN%" />
    </APS-Framework>
    <mi-org>
      <add key="Username" value="x" />
      <add key="ClearTextPassword" value="%APS_NUGET_TOKEN%" />
    </mi-org>
  </packageSourceCredentials>
</configuration>

El key en <packageSourceCredentials> debe coincidir exactamente con el key de <packageSources>. Ambos feeds corporativos comparten la misma variable %APS_NUGET_TOKEN% — un único Classic PAT con read:packages cubre múltiples organizaciones.

En local, APS_NUGET_TOKEN se puede obtener reutilizando el token de la sesión activa de gh: gh auth token.

Guía completa: README-nuget.md — credenciales locales, configuración de un nuevo repo SDK, referencia técnica del workflow y scripts compartidos.

Los workflows se consumen con uses: APS-Framework/.github/.github/workflows/<nombre>.yml@main desde cualquier repositorio de cualquier organización.

Workflow para repositorios .NET que publican paquetes NuGet en GitHub Packages.

• En cada push a main o pull_request, ejecuta restore, build y test automáticamente.
• La publicación se lanza de forma manual con workflow_dispatch, eligiendo entre rc (pre-release) o stable.
• Soporta repositorios con uno o varios paquetes: el input packages acepta nombres separados por comas.
• Calcula versiones automáticamente a partir del <VersionPrefix> del .csproj, resuelve dependencias internas entre paquetes del mismo repo y genera tags y GitHub Releases tras cada publicación satisfactoria.

Publicar con Copilot (recomendado)

La forma más segura y cómoda de disparar una publicación es pedírselo directamente a GitHub Copilot en modo Agent:

"Publica una versión RC de los paquetes MiOrg.Pagos.Proveedor1 y MiOrg.Pagos.Proveedor2" (dos paquetes del mismo repo) "Publica la versión estable del paquete de autenticación" (repo con un solo paquete, sin necesidad de especificar nombre)

Con el MCP server configurado, Copilot conoce los paquetes disponibles en el repositorio, sus versiones actuales y el estado de las últimas publicaciones. A partir de esa información, lanza el workflow con los parámetros correctos, sin que el desarrollador tenga que recordar nombres exactos, inputs ni comandos gh workflow run.

El input packages solo es necesario en repositorios con varios paquetes — si el repositorio tiene uno solo, puede omitirse.

jobs:
  ci-publish:
    uses: APS-Framework/.github/.github/workflows/nuget-ci-publish.yml@main
    with:
      release_type: ${{ inputs.release_type || '' }}
      packages: ${{ inputs.packages || '' }}
    secrets: inherit

Referencia completa: README-nuget.md.

Un único build alimenta todos los entornos: los tests unitarios son obligatorios en el build, los integration tests actúan como gate previo a cada deploy y PRO se promueve por swap de slot.

• dotnet-build.yml: restore, build, tests unitarios (**/*UnitTest*.csproj), dotnet publish y artifact.
• azure-functions-deploy.yml: integration tests → deploy → config sync de la Function App (slot opcional).
• azure-webapp-deploy.yml: integration tests + deploy de la Web App (slot opcional).
• azure-slot-swap.yml: swap staging → production (+ config sync en Functions); re-ejecutarlo es el rollback sin redeploy.
• azure-functions-config-sync.yml: publica la URL base y la function key en App Configuration y Key Vault (uso standalone; el deploy y el swap ya lo ejecutan en su job).

El caller declara sus entornos, su orden de promoción y sus gates, y llama a los bloques: dotnet-build → azure-functions-deploy (una vez por entorno) → azure-slot-swap en PRO. Caller de referencia: CS.Level.Booking/.github/workflows/deploy.yml.

Los workflows de deploy usan OIDC (Workload Identity Federation): la identidad de Azure necesita federated credentials con el subject repo:<org>/<repo>:environment:<nombre-entorno>. Las aprobaciones por entorno (required reviewers, wait timer) se configuran como protection rules del GitHub Environment.

Guía completa (environments, vars/secrets por nivel, federated credentials y Terraform): README-deploy.md.

Container Apps no tiene deployment slots: el flujo usa revisiones + labels de tráfico.

• container-app-build.yml: tests unitarios + docker build + push al ACR (una sola vez).
• container-app-deploy.yml: integration tests + nueva revisión desde la imagen publicada. Con staging_label la revisión queda con 0% de tráfico y accesible por URL de label.
• container-app-promote.yml: mueve el 100% del tráfico al label/revisión; re-ejecutarlo con la revisión anterior es el rollback.

El caller encadena container-app-build → container-app-deploy (una vez por entorno, con staging_label en PRO) → container-app-promote.

Referencia completa: README-deploy.md.

Workflow para sincronizar documentación operativa Markdown con un vector store compartido en Azure AI Foundry.

• Sincroniza los ficheros .md que coinciden con file_filter.
• Publica cada documento con nombre canónico {docs_prefix}/{ruta/relativa}; docs_root permite recortar el prefijo repo-relativo antes de publicar.
• Converge el vector store al estado del repositorio, creando, actualizando y eliminando adjuntos gestionados por ese repo.
• Requiere confirmación explícita si el filtro resuelve más de 200 documentos.

jobs:
  sync-docs:
    uses: APS-Framework/.github/.github/workflows/sync-vector-docs.yml@main
    with:
      file_filter: ${{ vars.OPS_DOCS_FILE_FILTER }}
      docs_prefix: RSB
      docs_root: src/MyLib/ops-docs
    secrets: inherit

El caller debe definir FOUNDRY_ENDPOINT_SBX y VS_TRAINER_ID_SBX en vars, y FOUNDRY_API_KEY_SBX en secrets.

Referencia completa: README-docs.md.

• Publicación NuGet y gestión de versiones
• Convenciones de documentación
• Flujo de trabajo con Git