Probar gratis
8 min lectura Guide 759 of 877

Desarrollo Backend con GitScrum

El desarrollo backend involucra APIs, bases de datos y servicios que potencian las aplicaciones. GitScrum ayuda a los equipos a organizar trabajo de backend con requisitos técnicos claros y dependencias.

Estructura de Tareas Backend

Tareas de Desarrollo de API

ESTRUCTURA DE TAREA DE API:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│ TAREA DE API BIEN ESTRUCTURADA:                             │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BE-100: Crear Endpoint de Exportación de Usuarios       ││
│ │                                                         ││
│ │ ENDPOINT:                                               ││
│ │ POST /api/v1/exports/users                             ││
│ │                                                         ││
│ │ REQUEST:                                                 ││
│ │ {                                                        ││
│ │   "format": "csv" | "xlsx",                            ││
│ │   "filters": {                                          ││
│ │     "created_after": "fecha ISO",                      ││
│ │     "status": "active" | "inactive"                   ││
│ │   }                                                     ││
│ │ }                                                        ││
│ │                                                         ││
│ │ RESPONSE (202):                                          ││
│ │ {                                                        ││
│ │   "export_id": "uuid",                                 ││
│ │   "status": "processing",                              ││
│ │   "estimated_seconds": 30                              ││
│ │ }                                                        ││
│ │                                                         ││
│ │ ERRORES:                                                 ││
│ │ 400: Formato o filtros inválidos                       ││
│ │ 403: Sin permiso de exportación                        ││
│ │ 429: Demasiadas exportaciones pendientes               ││
│ │                                                         ││
│ │ IMPLEMENTACIÓN:                                          ││
│ │ ☐ Validar request                                      ││
│ │ ☐ Encolar job en background                            ││
│ │ ☐ Crear registro de exportación                        ││
│ │ ☐ Retornar respuesta async                            ││
│ │                                                         ││
│ │ TESTING:                                                 ││
│ │ ☐ Tests unitarios para validación                     ││
│ │ ☐ Test de integración para flujo completo             ││
│ │ ☐ Test de rate limit                                   ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ ELEMENTOS CLAVE:                                            │
│ ✅ Contrato API completo (request/response)               │
│ ✅ Casos de error documentados                            │
│ ✅ Checklist de implementación                            │
│ ✅ Requisitos de testing                                  │
└─────────────────────────────────────────────────────────────┘

Trabajo de Base de Datos

ESTRUCTURA DE TAREA DE BASE DE DATOS:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│ TAREA DE MIGRACIÓN:                                         │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BE-150: Agregar tabla exports                           ││
│ │                                                         ││
│ │ SCHEMA:                                                  ││
│ │ ┌─────────────────────────────────────────────────────┐││
│ │ │ exports                                              │││
│ │ ├─────────────────────────────────────────────────────┤││
│ │ │ id: UUID (PK)                                        │││
│ │ │ user_id: UUID (FK → users)                          │││
│ │ │ type: VARCHAR(50)                                    │││
│ │ │ format: VARCHAR(10)                                  │││
│ │ │ status: VARCHAR(20) [pending, processing, done]     │││
│ │ │ file_url: TEXT (nullable)                           │││
│ │ │ error_message: TEXT (nullable)                      │││
│ │ │ expires_at: TIMESTAMP                                │││
│ │ │ created_at: TIMESTAMP                                │││
│ │ │ updated_at: TIMESTAMP                                │││
│ │ └─────────────────────────────────────────────────────┘││
│ │                                                         ││
│ │ ÍNDICES:                                                 ││
│ │ ☐ user_id (filtrar por usuario)                       ││
│ │ ☐ status (procesar pendientes)                        ││
│ │ ☐ expires_at (job de limpieza)                        ││
│ │                                                         ││
│ │ ROLLBACK:                                                ││
│ │ DROP TABLE exports;                                    ││
│ │                                                         ││
│ │ NOTAS DE DEPLOYMENT:                                     ││
│ │ • Sin downtime esperado (tabla nueva)                  ││
│ │ • Ejecutar en staging primero                          ││
│ └─────────────────────────────────────────────────────────┘│
│                                                             │
│ CHECKLIST DE MIGRACIÓN:                                     │
│ ☐ Archivo de migración creado                            │
│ ☐ Rollback probado                                       │
│ ☐ Deployment en staging verificado                       │
│ ☐ Deployment en producción planeado                      │
└─────────────────────────────────────────────────────────────┘

Diseño de APIs

Contratos Primero

DESARROLLO CONTRACT-FIRST:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│ FLUJO DE TRABAJO:                                           │
│                                                             │
│ 1. Definir contrato (OpenAPI/Swagger)                       │
│    │                                                        │
│    ▼                                                        │
│ 2. Revisar con Frontend + Backend                           │
│    │                                                        │
│    ▼                                                        │
│ 3. Generar mocks para Frontend                              │
│    │                                                        │
│    ├── Frontend trabaja con mocks ────────────┐            │
│    │                                          │            │
│    ▼                                          │            │
│ 4. Backend implementa API real                │            │
│    │                                          │            │
│    ▼                                          ▼            │
│ 5. Integración cuando ambos listos ◄──────────┘            │
│                                                             │
│ BENEFICIOS:                                                 │
│ ├── Trabajo en paralelo                                     │
│ ├── Contrato documentado                                    │
│ ├── Menos sorpresas en integración                          │
│ └── Cambios discutidos temprano                             │
└─────────────────────────────────────────────────────────────┘

Ejemplo OpenAPI

ESPECIFICACIÓN OPENAPI:
═══════════════════════

openapi: 3.0.0
info:
  title: User Exports API
  version: 1.0.0

paths:
  /api/v1/exports/users:
    post:
      summary: Crear exportación de usuarios
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                format:
                  type: string
                  enum: [csv, xlsx]
                filters:
                  type: object
                  properties:
                    created_after:
                      type: string
                      format: date-time
                    status:
                      type: string
                      enum: [active, inactive]
      responses:
        '202':
          description: Exportación iniciada
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ExportResponse'
        '400':
          description: Request inválido
        '403':
          description: Sin permiso

Coordinación Frontend-Backend

COORDINACIÓN DE EQUIPOS
═══════════════════════

TABLERO GITSCRUM:
─────────────────────────────────────────────────────────────
│ To Do      │ Backend    │ Frontend   │ Integración │ Done │
├────────────┼────────────┼────────────┼─────────────┼──────┤
│            │ BE-100     │ FE-100     │             │      │
│            │ API Export │ UI Export  │             │      │
│            │ [Carlos]   │ [María]    │             │      │
│            │            │ (usa mock) │             │      │
├────────────┼────────────┼────────────┼─────────────┼──────┤
│            │            │            │ INT-100     │      │
│            │            │            │ Integrar    │      │
│            │            │            │ Export      │      │
└────────────┴────────────┴────────────┴─────────────┴──────┘

DEPENDENCIAS EXPLÍCITAS:
├── FE-100 depende de: contrato API (definido)
├── FE-100 NO depende de: implementación real
├── INT-100 depende de: BE-100 + FE-100
└── Bloqueador real: solo contrato, no código

Manejo de Migraciones

Proceso Seguro

PROCESO DE MIGRACIÓN SEGURA
═══════════════════════════

ANTES DE CREAR MIGRACIÓN:
├── ¿Es necesario el cambio de schema?
├── ¿Hay alternativas sin migración?
├── ¿Impacto en queries existentes?
└── ¿Requiere downtime?

CREANDO MIGRACIÓN:
├── Un cambio por migración
├── Siempre incluir rollback
├── Comentarios explicando por qué
└── Nombrar descriptivamente

TESTING:
├── Ejecutar localmente primero
├── Probar rollback funciona
├── Verificar con datos similares a prod
└── Medir tiempo de ejecución

DEPLOYMENT:
┌─────────────────────────────────────────┐
│ 1. Deploy a staging                     │
│    ↓                                    │
│ 2. Verificar migración exitosa          │
│    ↓                                    │
│ 3. Ejecutar tests en staging            │
│    ↓                                    │
│ 4. Programar ventana de deploy prod     │
│    ↓                                    │
│ 5. Deploy a producción                  │
│    ↓                                    │
│ 6. Monitorear errores post-deploy       │
└─────────────────────────────────────────┘

Tipos de Migraciones

TIPOS DE CAMBIOS DE SCHEMA
══════════════════════════

BAJO RIESGO (sin downtime):
├── Agregar tabla nueva
├── Agregar columna nullable
├── Agregar índice (CONCURRENTLY)
└── Drop columna no usada

MEDIO RIESGO (requiere cuidado):
├── Agregar columna NOT NULL con default
├── Renombrar columna
├── Cambiar tipo de columna
└── Agregar constraint

ALTO RIESGO (posible downtime):
├── Drop tabla en uso
├── Cambiar primary key
├── Migración de datos masiva
└── Cambio en relaciones FK

MITIGACIÓN:
├── Hacer cambios en múltiples deploys
├── Feature flags para código
├── Expand-contract pattern
└── Blue-green deployment

Métricas Backend

DASHBOARD DE MÉTRICAS BACKEND
═════════════════════════════

APIS:
┌─────────────────────────────────────────┐
│ Endpoints en desarrollo: 3              │
│ Endpoints completados esta semana: 5    │
│ Endpoints con tests: 94%                │
│ Documentación actualizada: 100%         │
└─────────────────────────────────────────┘

BASES DE DATOS:
┌─────────────────────────────────────────┐
│ Migraciones pendientes: 2               │
│ Migraciones esta semana: 4              │
│ Rollbacks ejecutados: 0                 │
│ Tiempo promedio migración: 2.3s         │
└─────────────────────────────────────────┘

CALIDAD:
┌─────────────────────────────────────────┐
│ Cobertura de tests: 82%                 │
│ Code review promedio: 4h                │
│ Bugs backend este sprint: 3             │
│ Bugs resueltos: 5                       │
└─────────────────────────────────────────┘

Mejores Prácticas

MEJORES PRÁCTICAS BACKEND
═════════════════════════

✓ Contratos API primero
  └── Documenta antes de implementar

✓ Tareas con criterios técnicos claros
  └── Input/output/errores definidos

✓ Migraciones como tareas de primera clase
  └── Nunca apresurar cambios de DB

✓ Tests antes de PR
  └── No merge sin cobertura

✓ Documentación actualizada
  └── Swagger/OpenAPI siempre al día

✓ Dependencias explícitas
  └── Bloqueos claros en tablero

Anti-Patrones

ANTI-PATRONES A EVITAR
══════════════════════

✗ API sin documentación
  └── "Ya lo explico luego"

✗ Migraciones sin rollback
  └── Disaster recovery imposible

✗ Backend y frontend descoordinados
  └── Integración caótica

✗ Cambios de schema apresurados
  └── Bugs en producción

✗ Sin tests de API
  └── Regresiones constantes

Soluciones Relacionadas