@beyapsi/yapsi-database v0.1.13

📑 Índice

• 🔐 Política de control de ramas
  • 📋 Reglas comunes (main y dev)
  • 🧭 Reglas específicas por rama
    • 🔸 Rama main
    • 🔸 Rama dev
  • 🧩 Convención para nombres de ramas - Proyecto Database
  • 📝 Estrategia recomendada para generar migraciones
• 🚀 Resumen
• 📄 Database Setup
  • 🚀 Requisitos
  • 🐘 Levantar la Base de Datos con Docker
  • 🗄️ Si ya cuentas con una Base de Datos o Volumen creado

🔐 Política de control de ramas

Este repositorio implementa una estrategia de protección de ramas crítica (main y dev) orientada al control de acceso, trazabilidad y revisión colaborativa.

Las reglas se aplican mediante Branch Protection Rules y pueden reforzarse con GitHub Actions.

📋 Reglas comunes (main y dev)

• 🚫 Push directo prohibido para todos los usuarios (incluyendo administradores).
• ⚙️ Activar Require linear history para mantener un historial limpio (sin merge commits).
• 🔧 Configurar Branch Protection Rules en GitHub para asegurar cumplimiento automático.
• 🤖 Automatización recomendada con GitHub Actions:
  • Cierre automático de PRs inválidos (por origen o falta de revisiones).
  • Validación de condiciones antes del merge.

🧭 Reglas específicas por rama

🔸 Rama main

• ✅ Solo acepta Pull Requests provenientes de la rama dev.
• 🔒 Solo el administrador o propietario del repositorio puede crear y hacer merge de PRs.
• ❗ No requiere revisión formal, pero el responsable del merge debe validarlo explícitamente.
• ❌ Cualquier PR hacia main desde otra rama debe ser cerrado automáticamente.

🔸 Rama dev

• ✅ Cualquier colaborador puede abrir Pull Requests hacia esta rama.
• 🔒 Solo el administrador o propietario puede hacer merge.
• ✅ Cada PR requiere al menos una aprobación de un líder técnico antes del merge.

🧩 Convención para nombres de ramas - Proyecto Database

Usamos una nomenclatura clara y estructurada para mantener un historial limpio y trazable en la gestión de cambios relacionados con entidades, migraciones y configuración de base de datos.

📌 Reglas

• Minúsculas.
• Palabras separadas por guiones (-).
• Nombres claros, cortos y específicos.
• Prefijos siempre en inglés para mantener consistencia técnica.
• Cuando se relacione a migraciones, reflejar la acción: create, update, delete, fix.

📌 Notas: Se recomienda acumular múltiples cambios estructurales relacionados antes de generar una migración. No es necesario que cada rama tenga su propia migración.

✅ Ejemplos reales para este proyecto

📝 Estrategia recomendada para generar migraciones

Para evitar contaminación de migraciones innecesarias y tener un historial limpio, se recomienda:

✅ Acumular cambios relacionados

Es válido realizar múltiples cambios estructurales (crear entidades, agregar o modificar columnas) en varias ramas, sin generar migraciones en cada una.

La generación de migración se debe hacer cuando:

• Los cambios de estructura estén completos y revisados.
• Los cambios estén validados funcionalmente.
• Los cambios afecten el mismo contexto o módulo.

Ejemplo de flujo recomendado:

1. En la rama entity/create-user se crea la entidad User.
2. En la rama entity-update/add-phone-to-user se agrega un campo phone.
3. Una vez aprobados ambos PRs, se genera una sola migración en una rama como:

migration/add-user-entity

Que contenga ambos cambios.

❗️ Evitar migraciones innecesarias

No se recomienda generar migraciones cada vez que:

• Se haga un cambio pequeño o aislado.
• Estés en desarrollo activo de las entidades y sabes que cambiarán pronto.
• Haya cambios que pueden ser agrupados lógicamente.

✅ Casos donde sí debes generar la migración inmediatamente

• Cambios urgentes o críticos que deban aplicarse en producción.
• Cuando un cambio impacta otro microservicio que depende de la estructura.
• Cuando es un cambio probado, versionado y que no dependerá de otros.

🚀 Resumen

📄 Database Setup

Repositorio dedicado a la administración de la base de datos para el ecosistema Yapsi, utilizando PostgreSQL, TypeORM, NestJS y migraciones controladas.

🚀 Requisitos

Para correr este proyecto, asegúrate de tener instalado:

• Docker & Docker Compose
• Node.js y npm o Yarn

Instalación de dependencias:

yarn install 

🐘 Levantar la Base de Datos con Docker

Para construir y levantar la base de datos junto con la inicialización automática:

docker-compose up -d
npm run init-db

Este comando ejecutará los contenedores necesarios y creará las tablas basadas en las entidades existentes.

🗄️ Si ya cuentas con una Base de Datos o Volumen creado

Si ya tienes una base de datos existente o un volumen previamente creado:

1. Primero, dentro del contenedor, crea la base de datos con el nombre deseado.
2. Luego, en tu proyecto, ejecuta:

npm run init-db

Este comando cargará todas las entidades en la base de datos existente.

📌 Nota: Asegúrate de que el nombre de la base de datos coincida exactamente para evitar inconsistencias o errores.

⚠️ Advertencia: Este proceso no es recomendable si estás trabajando con migraciones, ya que omite el control de versiones estructurales.

📝 Esta política y guía pueden adaptarse según el contexto del proyecto y el tamaño del equipo.