Saltar a contenido

Pipeline CI/CD - Sistema de Turnos Medicos

Proposito

Diseno del pipeline de integracion continua y entrega continua. Define que pasa desde que un developer hace push hasta que el codigo esta en produccion.

1. Vision General del Pipeline

Developer Push
      |
      v
[1. Build & Lint] --fail--> Notifica al developer
      |
      v
[2. Unit Tests] --fail--> Notifica al developer
      |
      v
[3. Integration Tests] --fail--> Notifica al developer
      |
      v
[4. Security Scan] --fail--> Bloquea + notifica
      |
      v
[5. Build Artifact]
      |
      v
[6. Deploy Staging] ---> [7. Smoke Tests] --fail--> Rollback staging
      |                                       |
      v                                       v
[8. Manual Approval] <--- (solo para main)
      |
      v
[9. Deploy Production] ---> [10. Smoke Tests] --fail--> Rollback
      |
      v
[11. Notificar equipo]

2. Etapas del Pipeline

Stage 1: Build & Lint (~1 min)

# GitHub Actions example
build:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: '20'
        cache: 'npm'
    - run: npm ci
    - run: npm run lint
    - run: npm run build

Que valida: - Dependencias se instalan sin errores. - No hay errores de lint (ESLint + Prettier). - TypeScript compila sin errores.

Si falla: El developer recibe notificacion. No se ejecutan las siguientes etapas.

Stage 2: Unit Tests (~2 min)

unit-tests:
  needs: build
  runs-on: ubuntu-latest
  steps:
    - run: npm run test:unit -- --coverage
    - uses: actions/upload-artifact@v4
      with:
        name: coverage-report
        path: coverage/

Que valida: - Toda la logica de negocio pasa. - Coverage minimo: 80% en domain services.

Stage 3: Integration Tests (~5 min)

integration-tests:
  needs: build
  runs-on: ubuntu-latest
  services:
    postgres:
      image: postgres:17
      env:
        POSTGRES_DB: test_db
        POSTGRES_USER: test_user
        POSTGRES_PASSWORD: test_pass
      ports:
        - 5432:5432
  steps:
    - run: npm run migration:run -- --config test
    - run: npm run test:integration

Que valida: - Endpoints responden segun el API contract. - Queries y transacciones funcionan contra PostgreSQL real. - Migraciones se ejecutan sin errores.

Stage 4: Security Scan (~3 min)

security:
  needs: build
  runs-on: ubuntu-latest
  steps:
    - run: npm audit --audit-level=high
    - uses: github/codeql-action/analyze@v3
    - run: npx snyk test --severity-threshold=high

Que valida: - No hay dependencias con vulnerabilidades high/critical. - No hay patrones de codigo inseguros (SQL injection, XSS). - Secrets no estan hardcoded.

Si falla: Bloquea el pipeline. No se despliega con vulnerabilidades conocidas.

Stage 5: Build Artifact (~1 min)

build-artifact:
  needs: [unit-tests, integration-tests, security]
  steps:
    - run: npm run build
    - run: tar -czf app.tar.gz dist/ node_modules/ package.json
    - uses: actions/upload-artifact@v4
      with:
        name: app-artifact
        path: app.tar.gz

Stage 6: Deploy Staging (~2 min)

deploy-staging:
  needs: build-artifact
  if: github.ref == 'refs/heads/main'
  environment: staging
  steps:
    - run: |
        scp app.tar.gz staging-server:/tmp/
        ssh staging-server 'cd /app && tar -xzf /tmp/app.tar.gz && pm2 reload all'

Stage 7: Smoke Tests en Staging (~1 min)

smoke-staging:
  needs: deploy-staging
  steps:
    - run: |
        curl -f https://staging.api.example.com/health || exit 1
        curl -f https://staging.api.example.com/api/v1/specialties || exit 1

Stage 8: Manual Approval

Aprobacion manual en GitHub antes de desplegar a produccion. Solo para la rama main.

Stage 9-10: Deploy Production + Smoke

Mismo proceso que staging pero contra el servidor de produccion.

Stage 11: Notificacion

notify:
  needs: deploy-production
  steps:
    - uses: slackapi/slack-github-action@v1
      with:
        payload: |
          {"text": "Deploy exitoso: ${{ github.sha }} por ${{ github.actor }}"}

3. Estrategia de Branching

main (produccion)
  |
  +-- develop (staging)
        |
        +-- feature/FEAT-001-auth
        +-- feature/FEAT-002-bookings
        +-- fix/BUG-123-double-booking
Branch Deploy a CI completo Manual approval
feature/* No deploy Si (sin stages 6-11) No
develop Staging Si No
main Produccion Si Si

4. Rollback

Rollback automatico

Si los smoke tests fallan en produccion, se ejecuta automaticamente:

# Restaurar version anterior
ssh prod-server 'cd /app && pm2 deploy production revert 1'

Rollback manual

Si se detecta un bug en produccion despues de los smoke tests:

# Ver deploys anteriores
pm2 deploy production list

# Revertir a version especifica
pm2 deploy production revert <N>

Rollback de base de datos

Las migraciones deben ser reversibles:

# Revertir ultima migracion
npm run migration:revert

Regla critica: Nunca hagas migraciones destructivas (DROP COLUMN, DROP TABLE) en el mismo deploy que el codigo que las necesita. Usa el patron expand-contract: 1. Deploy 1: Agrega nueva columna/tabla. 2. Deploy 2: El codigo usa la nueva estructura. 3. Deploy 3 (semanas despues): Remueve la estructura vieja.

5. Tiempos Target

Etapa Target Si excede
Build + Lint < 1 min Revisar cache de dependencias
Unit Tests < 2 min Revisar tests lentos
Integration Tests < 5 min Paralelizar o reducir scope
Security Scan < 3 min Aceptable, es externo
Pipeline completo (sin approval) < 12 min
Deploy staging < 2 min
Deploy produccion < 2 min

Checklist de Completitud

  • Pipeline completo documentado
  • Cada stage con ejemplo de configuracion
  • Estrategia de branching definida
  • Rollback documentado (auto + manual + BD)
  • Tiempos target definidos
  • Revisada por otro ingeniero
  • Derivados generados (archivos de CI reales)

Archivos relacionados