Files
motor-de-encuestas/sprints/sprint-4/PASO_0_PRESERVACION.md
markosbenitez 5987502664 feat(schema): esquema declarativo + seed v3 del formulario [4B]
Extiende questions con instance_generator/instance_of/hint.
Instrumento v3 completo (10 secciones, 50 preguntas) como datos declarativos.
Operadores de flujo para multiple_choice: contains, eq_sole.
Flujo del formulario en el esquema, no en presentación (ADR-005).
Seed solo reemplaza catálogo; no toca evidencia de consentimiento (ADR-003).
2026-06-22 21:05:11 -03:00

95 lines
2.7 KiB
Markdown

# PASO 0 — Preservación de v2.1.0 antes de arrancar Sprint 4
> Ejecutar ANTES de tocar nada de v3. Estos pasos preservan el estado actual
> estable como punto de retorno seguro.
---
## Objetivo
1. Crear tag `v2.1.0` sobre el commit actual de `main`.
2. Crear rama `v2.1.0-stable` que preserva el código de v2.
3. Generar un dump de la base de datos de producción y versionarlo en esa rama.
4. Crear `CHANGELOG.md` en `main`.
5. Dejar `main` listo para desarrollo de v3.
---
## Secuencia de comandos
### 1. Asegurarse de estar en main actualizado
```bash
git checkout main
git pull origin main
git status # debe estar limpio
```
### 2. Crear el tag de la versión estable actual
```bash
git tag -a v2.1.0 -m "Versión 2.1.0 — formulario lineal, dashboard multitenante, instrumento v2.1"
git push origin v2.1.0
```
### 3. Crear la rama de preservación
```bash
git checkout -b v2.1.0-stable
git push -u origin v2.1.0-stable
```
### 4. Generar el dump de la base de datos (en el VPS)
```bash
# En el VPS inq-mart-2:
docker exec supabase-db pg_dump -U postgres --clean --if-exists postgres \
| gzip > ~/dump_v2.1.0_$(date +%Y%m%d).sql.gz
# Verificar tamaño
ls -lh ~/dump_v2.1.0_*.sql.gz
```
### 5. Traer el dump a la máquina local y agregarlo a la rama
```bash
# En tu Mac, desde el repo, estando en la rama v2.1.0-stable:
mkdir -p db-snapshots
scp administrator@172.20.5.11:~/dump_v2.1.0_*.sql.gz db-snapshots/
git add db-snapshots/
git commit -m "chore(v2.1.0): snapshot de base de datos de producción
Dump completo de la DB de producción al momento del corte v2.1.0.
Incluye: 3 organizaciones, 3 surveys, 132 questions, 15 responses, ~500 answers.
Preservado antes de iniciar el desarrollo de v3 (wizard)."
git push origin v2.1.0-stable
```
### 6. Volver a main y crear el CHANGELOG
```bash
git checkout main
# Crear CHANGELOG.md (contenido en el archivo adjunto)
git add CHANGELOG.md
git commit -m "docs: agregar CHANGELOG con versionado semántico
Establece la convención SemVer para el proyecto.
v2.1.0 documentada como versión estable actual.
v3.0.0 (wizard) marcada como en desarrollo."
git push origin main
```
---
## Verificación final
```bash
git tag -l # debe mostrar v2.1.0
git branch -a # debe mostrar main y v2.1.0-stable
git log --oneline -3 # en main, último commit es el CHANGELOG
```
A partir de acá, todo el trabajo de v3 va en `main`. La rama `v2.1.0-stable`
queda congelada como referencia y punto de retorno.
---
## Nota sobre el dump
El dump en `db-snapshots/` permite recrear la DB de v2.1.0 si fuera necesario
volver atrás. Para restaurarlo:
```bash
gunzip -c dump_v2.1.0_YYYYMMDD.sql.gz | docker exec -i supabase-db psql -U postgres -d postgres
```