Publicación y DevOps

Pipeline en Azure DevOps

La estrategia recomendada es que las actualizaciones de CoreDocs.Tech disparen la generación del portal y que CoreDocs.Engine se use como motor compartido.

Patrón recomendado#

Opción preferida#

CoreDocs.Engine contiene el generador y ejemplos de pipeline.
CoreDocs.Tech contiene el contenido vivo.
Azure DevOps checkouta ambos repositorios en el mismo job.
El pipeline genera dist y publica un artefacto o despliega directamente.

Punto importante sobre el disparo#

Según la documentación oficial de Azure DevOps, los triggers por resources.repositories están pensados para Azure Repos y con restricciones concretas de uso entre repositorios. Si CoreDocs.Tech no está en ese escenario, la alternativa práctica es:

alojar el YAML en CoreDocs.Tech, o
disparar el pipeline del motor mediante service hook o REST cuando haya cambios

Estructura de checkout recomendada#

Mantén estas rutas dentro del agente:

$(Pipeline.Workspace)/s/CoreDocs.Engine
$(Pipeline.Workspace)/s/CoreDocs.Tech

Así content_root: "../CoreDocs.Tech/content" funciona sin tocar config.json.

Fases recomendadas#

checkout de ambos repositorios
instalación de Python y dependencias
ejecución de generator.py
publicación del artefacto
despliegue al destino elegido

Ejemplos incluidos en el repositorio del motor#

CoreDocs.Engine/examples/azure-pipelines-build-dist.yml
CoreDocs.Engine/examples/azure-pipelines-deploy-appservice.yml
CoreDocs.Engine/examples/azure-pipelines-deploy-container.yml

Pipeline mínimo de build#

Este patrón es suficiente para generar y publicar dist como artefacto:

resources:
  repositories:
    - repository: coredocstech
      type: git
      name: REEMPLAZAR_PROYECTO/CoreDocs.Tech
      trigger:
        branches:
          include:
            - main

steps:
  - checkout: self
    path: s/CoreDocs.Engine
  - checkout: coredocstech
    path: s/CoreDocs.Tech
  - task: UsePythonVersion@0
    inputs:
      versionSpec: "3.11"
  - script: |
      python -m pip install --upgrade pip
      pip install -r requirements.txt
    workingDirectory: "$(Pipeline.Workspace)/s/CoreDocs.Engine"
  - script: python generator.py
    workingDirectory: "$(Pipeline.Workspace)/s/CoreDocs.Engine"

Recomendaciones de gobierno#

no publiques dist/ de vuelta al repositorio
separa Build y Deploy en stages distintos
usa artefactos de pipeline en vez de depender del workspace del agente
define service connections distintas para pruebas y producción
protege la rama de contenido si la documentación es sensible

Estrategia sugerida para tu caso#

Para que tu compañero termine la automatización con poco riesgo, yo dejaría esta secuencia:

Pipeline de build disparado por cambios en CoreDocs.Tech.
Publicación de artefacto ZIP o carpeta dist.
Segundo stage o release para App Service.
Contenedor solo si necesitáis un runtime más controlado.