Conceptos básicos de CI/CD

Q: ¿CI en main después de la fusión?

Sí. Vuelve a ejecutar las puertas en main para detectar desviaciones de fusión. Algunos equipos confían solo en PR; volver a ejecutar en main es más seguro.

Q: ¿Estrategia de Monorepo?

Filtros de ruta: paths: ['services/api/'] activan solo los flujos de trabajo afectados. Usa Turborepo o Nx para la detección de afectados.

Q: ¿Cómo encajan los despliegues de Lambda?

CI construye el artefacto zip; CD ejecuta aws lambda update-function-code con el mismo objeto S3 nombrado con SHA.

10 ejemplos para estructurar CI (validación de pull request) y CD (despliegue de lanzamiento) para servicios Node.js 24 TypeScript - 7 básicos y 3 intermedios.

Prerrequisitos

mkdir node-service && cd node-service
npm init -y
npm pkg set type=module
npm install express@5
npm install -D typescript@5.6 vitest eslint @types/node

Para detalles específicos de GitHub Actions, consulta GitHub Actions para Node y Quality Gates.

Ejemplos Básicos

1. Etapas de la Pipeline de PR

PR abierto / push
  -> instalar (npm ci)
  -> lint
  -> typecheck
  -> prueba unitaria
  -> (opcional) prueba de integración
  -> bloquear fusión si algún paso falla

La pipeline de PR demuestra que el commit es seguro para fusionar
No hay despliegue en la pipeline de PR para la mayoría de los equipos (los entornos de vista previa son opcionales)
Retroalimentación rápida: objetivo de menos de 10 minutos para las etapas unitarias

2. Etapas de la Pipeline de Lanzamiento

Etiquetar / fusionar a main
  -> instalar + probar (repetir puertas)
  -> construir (tsc / docker build)
  -> escanear imagen / auditar
  -> push de artefacto (registro / zip S3)
  -> desplegar staging
  -> prueba de humo en staging
  -> desplegar producción (aprobación manual o progresiva)

La pipeline de lanzamiento produce el artefacto desplegable
El mismo SHA de git desde la prueba hasta la producción
Consulta Mejores Prácticas de CI/CD

3. Scripts CI de `package.json`

{
  "scripts": {
    "lint": "eslint src",
    "typecheck": "tsc --noEmit",
    "test": "vitest run",
    "build": "tsc -p tsconfig.json",
    "audit:ci": "npm audit --audit-level=high"
  }
}

CI llama a scripts npm, no a comandos de herramientas dispersos en YAML
tsc --noEmit detecta errores de tipo sin emitir archivos
Fija las versiones de las herramientas en las devDependencies de package.json

4. Flujo de Trabajo Mínimo de GitHub Actions para PR

# .github/workflows/ci.yml
name: CI
on:
  pull_request:
  push:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "24"
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm run test

cache: npm acelera las instalaciones cuando el lockfile no ha cambiado
Se ejecuta en pull_request y push a main
Consulta GitHub Actions para Node

5. Ordenación para Fallar Rápido

steps:
  - run: npm ci
  - run: npm run lint      # segundos
  - run: npm run typecheck # segundos
  - run: npm run test      # minutos
  - run: npm run build     # después de que pasen las pruebas

Coloca las comprobaciones más baratas primero
No construyas Docker antes de que pasen las pruebas unitarias
Trabajos paralelos para lint vs test si el repositorio es grande

6. Separación de Entornos

Entorno	Disparador	Propósito
`ci`	Cada PR	Solo validación
`staging`	Fusionar a `main`	Integración pre-producción
`production`	Etiqueta o flujo de trabajo aprobado	Tráfico de clientes

Staging utiliza una configuración similar a la de producción con datos depurados
El despliegue en producción requiere aprobación o canary - Entrega Canary y Progresiva

7. Inmutabilidad del Artefacto

- name: Build and push image
  run: |
    IMAGE=ghcr.io/acme/api:${{ github.sha }}
    docker build -t "$IMAGE" .
    docker push "$IMAGE"

Etiqueta las imágenes con github.sha, no solo :latest
Despliega staging y producción con el mismo digest
Revertir = volver a desplegar el SHA anterior

Ejemplos Intermedios

8. Flujo de Trabajo Reutilizable

# .github/workflows/reusable-node-ci.yml
on:
  workflow_call:
    inputs:
      node-version:
        required: false
        type: string
        default: "24"
 
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
          cache: npm
      - run: npm ci
      - run: npm run lint && npm run typecheck && npm run test

# .github/workflows/ci.yml
jobs:
  call-ci:
    uses: ./.github/workflows/reusable-node-ci.yml

DRY en monorepos de microservicios
Cada flujo de trabajo de servicio pasa su directorio de trabajo si es necesario

9. Flujo de Trabajo de Lanzamiento con Protección de Entorno

# .github/workflows/release.yml
name: Release
on:
  push:
    tags: ["v*.*.*"]
 
jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test && npm run build
      - run: ./scripts/deploy.sh staging ${{ github.sha }}
 
  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: ./scripts/deploy.sh production ${{ github.sha }}

environment de GitHub añade revisores requeridos para producción
Staging debe pasar antes de que comience el trabajo de producción

10. Puerta de Commits Convencionales

- name: Validate commit messages on PR
  uses: wagoid/commitlint-github-action@v6

Permite semver automatizado a través de Semantic Release
Aplicar en la pipeline de PR, no solo en el momento del lanzamiento

Preguntas Frecuentes

¿Las pipelines de PR deberían desplegar en algún lugar?

Entornos de vista previa opcionales por PR - Entornos de Vista Previa. Por defecto: solo validar, desplegar al fusionar.

¿CI en main después de la fusión?

Sí. Vuelve a ejecutar las puertas en main para detectar desviaciones de fusión. Algunos equipos confían solo en PR; volver a ejecutar en main es más seguro.

¿Dónde encaja la construcción de Docker?

Pipeline de lanzamiento después de las pruebas, o pipeline de PR solo para cambios en Dockerfile con puerta de escaneo. Nunca omitas las pruebas antes de subir la imagen.

¿Estrategia de Monorepo?

Filtros de ruta: paths: ['services/api/**'] activan solo los flujos de trabajo afectados. Usa Turborepo o Nx para la detección de afectados.

¿Cómo encajan los despliegues de Lambda?

CI construye el artefacto zip; CD ejecuta aws lambda update-function-code con el mismo objeto S3 nombrado con SHA.

¿Qué pasa con los secretos en CI?

Secretos de GitHub Actions y OIDC a AWS. No hay claves de AWS de larga duración en el repositorio. Consulta Administradores de Secretos.

Relacionado

GitHub Actions para Node - matriz y caché
Quality Gates - lint, auditoría, cobertura
Semantic Release - versionado automatizado
Preview Environments - despliegues de PR
Mejores Prácticas de CI/CD - lista de verificación de la sección

Versiones de la pila: Esta página fue escrita para Node.js 24.18.0 (LTS Activo), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 y NestJS 11.

Prerrequisitos

mkdir node-service && cd node-service
npm init -y
npm pkg set type=module
npm install express@5
npm install -D typescript@5.6 vitest eslint @types/node

Para detalles específicos de GitHub Actions, consulta GitHub Actions para Node y Quality Gates.

Ejemplos Básicos

1. Etapas de la Pipeline de PR

PR abierto / push
  -> instalar (npm ci)
  -> lint
  -> typecheck
  -> prueba unitaria
  -> (opcional) prueba de integración
  -> bloquear fusión si algún paso falla

La pipeline de PR demuestra que el commit es seguro para fusionar
No hay despliegue en la pipeline de PR para la mayoría de los equipos (los entornos de vista previa son opcionales)
Retroalimentación rápida: objetivo de menos de 10 minutos para las etapas unitarias

2. Etapas de la Pipeline de Lanzamiento

Etiquetar / fusionar a main
  -> instalar + probar (repetir puertas)
  -> construir (tsc / docker build)
  -> escanear imagen / auditar
  -> push de artefacto (registro / zip S3)
  -> desplegar staging
  -> prueba de humo en staging
  -> desplegar producción (aprobación manual o progresiva)

La pipeline de lanzamiento produce el artefacto desplegable
El mismo SHA de git desde la prueba hasta la producción
Consulta Mejores Prácticas de CI/CD

3. Scripts CI de `package.json`

{
  "scripts": {
    "lint": "eslint src",
    "typecheck": "tsc --noEmit",
    "test": "vitest run",
    "build": "tsc -p tsconfig.json",
    "audit:ci": "npm audit --audit-level=high"
  }
}

CI llama a scripts npm, no a comandos de herramientas dispersos en YAML
tsc --noEmit detecta errores de tipo sin emitir archivos
Fija las versiones de las herramientas en las devDependencies de package.json

4. Flujo de Trabajo Mínimo de GitHub Actions para PR

# .github/workflows/ci.yml
name: CI
on:
  pull_request:
  push:
    branches: [main]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "24"
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm run test

cache: npm acelera las instalaciones cuando el lockfile no ha cambiado
Se ejecuta en pull_request y push a main
Consulta GitHub Actions para Node

5. Ordenación para Fallar Rápido

steps:
  - run: npm ci
  - run: npm run lint      # segundos
  - run: npm run typecheck # segundos
  - run: npm run test      # minutos
  - run: npm run build     # después de que pasen las pruebas

Coloca las comprobaciones más baratas primero
No construyas Docker antes de que pasen las pruebas unitarias
Trabajos paralelos para lint vs test si el repositorio es grande

6. Separación de Entornos

Entorno	Disparador	Propósito
`ci`	Cada PR	Solo validación
`staging`	Fusionar a `main`	Integración pre-producción
`production`	Etiqueta o flujo de trabajo aprobado	Tráfico de clientes

Staging utiliza una configuración similar a la de producción con datos depurados
El despliegue en producción requiere aprobación o canary - Entrega Canary y Progresiva

7. Inmutabilidad del Artefacto

- name: Build and push image
  run: |
    IMAGE=ghcr.io/acme/api:${{ github.sha }}
    docker build -t "$IMAGE" .
    docker push "$IMAGE"

Etiqueta las imágenes con github.sha, no solo :latest
Despliega staging y producción con el mismo digest
Revertir = volver a desplegar el SHA anterior

Ejemplos Intermedios

8. Flujo de Trabajo Reutilizable

# .github/workflows/reusable-node-ci.yml
on:
  workflow_call:
    inputs:
      node-version:
        required: false
        type: string
        default: "24"
 
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ inputs.node-version }}
          cache: npm
      - run: npm ci
      - run: npm run lint && npm run typecheck && npm run test

# .github/workflows/ci.yml
jobs:
  call-ci:
    uses: ./.github/workflows/reusable-node-ci.yml

DRY en monorepos de microservicios
Cada flujo de trabajo de servicio pasa su directorio de trabajo si es necesario

9. Flujo de Trabajo de Lanzamiento con Protección de Entorno

# .github/workflows/release.yml
name: Release
on:
  push:
    tags: ["v*.*.*"]
 
jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test && npm run build
      - run: ./scripts/deploy.sh staging ${{ github.sha }}
 
  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: ./scripts/deploy.sh production ${{ github.sha }}

environment de GitHub añade revisores requeridos para producción
Staging debe pasar antes de que comience el trabajo de producción

10. Puerta de Commits Convencionales

- name: Validate commit messages on PR
  uses: wagoid/commitlint-github-action@v6

Permite semver automatizado a través de Semantic Release
Aplicar en la pipeline de PR, no solo en el momento del lanzamiento

Preguntas Frecuentes

¿Las pipelines de PR deberían desplegar en algún lugar?

Entornos de vista previa opcionales por PR - Entornos de Vista Previa. Por defecto: solo validar, desplegar al fusionar.

¿CI en main después de la fusión?

Sí. Vuelve a ejecutar las puertas en main para detectar desviaciones de fusión. Algunos equipos confían solo en PR; volver a ejecutar en main es más seguro.

¿Dónde encaja la construcción de Docker?

Pipeline de lanzamiento después de las pruebas, o pipeline de PR solo para cambios en Dockerfile con puerta de escaneo. Nunca omitas las pruebas antes de subir la imagen.

¿Estrategia de Monorepo?

Filtros de ruta: paths: ['services/api/**'] activan solo los flujos de trabajo afectados. Usa Turborepo o Nx para la detección de afectados.

¿Cómo encajan los despliegues de Lambda?

CI construye el artefacto zip; CD ejecuta aws lambda update-function-code con el mismo objeto S3 nombrado con SHA.

¿Qué pasa con los secretos en CI?

Secretos de GitHub Actions y OIDC a AWS. No hay claves de AWS de larga duración en el repositorio. Consulta Administradores de Secretos.

Relacionado

GitHub Actions para Node - matriz y caché
Quality Gates - lint, auditoría, cobertura
Semantic Release - versionado automatizado
Preview Environments - despliegues de PR
Mejores Prácticas de CI/CD - lista de verificación de la sección

Versiones de la pila: Esta página fue escrita para Node.js 24.18.0 (LTS Activo), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 y NestJS 11.

Conceptos básicos de CI/CD

Buscar en la documentación

Conceptos básicos de CI/CD