Implementa y opera tu experimento

Supuestos técnicos

• El runtime usa Python 3.11 sobre Linux. Los nombres de archivos distinguen mayúsculas y minúsculas.
• El proceso de la aplicación recibe la conexión a PostgreSQL mediante variables de entorno.
• El sistema de archivos del contenedor es efímero: no lo uses para conservar datos, archivos subidos o resultados.
• Una instancia atiende un experimento y es adecuada para cargas de hasta algunos cientos de participantes simultáneos. Informa con anticipación cargas mayores o patrones inusuales.

Estructura mínima

mi-experimento/
├── settings.py
├── requirements.txt
├── README.md
├── .gitignore
├── mi_app/
│   ├── __init__.py
│   └── ...
├── _static/       # opcional
└── _templates/    # opcional

No coloques un segundo proyecto oTree dentro del repositorio. El archivo settings.py debe estar en su raíz.

Configuración segura

from os import environ

ADMIN_PASSWORD = environ.get('ADMIN_PASSWORD')
SECRET_KEY = environ.get('SECRET_KEY')

# Conserva aquí SESSION_CONFIGS, SESSION_CONFIG_DEFAULTS y ROOMS.
# El laboratorio proporciona DATABASE_URL al desplegar.

• No definas DATABASE_URL, DEBUG ni AUTH_LEVEL dentro de settings.py.
• Para variables propias usa el prefijo OTREE_, léelas con environ.get() y documenta su propósito.
• Define ROOMS cuando el flujo operativo use códigos o salas permanentes.

Dependencias exactas

otree==6.x.y
psycopg2-binary==2.9.10
# añade debajo las demás dependencias realmente utilizadas

Sustituye 6.x.y por la versión exacta con la que probaste el estudio. No incluyas Procfile, runtime.txt ni Dockerfiles: el servidor construye el runtime.

Archivos que no deben viajar

.venv/
__pycache__/
*.py[cod]
*.sqlite3
.env
.otreezip
.DS_Store
exports/
participant_data/

Excluye bases locales, exportaciones, datos de participantes, secretos, entornos virtuales, cachés y binarios grandes. Los videos u otros activos pesados deben acordarse antes del despliegue.

Instala y ejecuta

python -m venv .venv
# activa el entorno virtual en tu sistema
python -m pip install -r requirements.txt
otree devserver

Corre pruebas automatizadas

otree test

Incluye bots para las rutas principales y para cualquier rama crítica. Una prueba exitosa no sustituye el recorrido manual.

Prueba como se usará

1. Crea cada SESSION_CONFIG y, si corresponde, entra mediante cada Room.
2. Recorre tratamientos y contingencias con al menos dos navegadores o perfiles independientes.
3. Verifica instrucciones, pagos, timeouts, desconexiones y reingreso.
4. Prueba los dispositivos previstos, incluido teléfono si el estudio lo permite.
5. Haz una instalación desde un clon o ZIP limpio usando solo el README.
6. Simula producción con OTREE_PRODUCTION=1 y revisa que no dependa de datos locales.

Código fuente

• Preferido: URL de un repositorio accesible al equipo del laboratorio y un tag o commit específico.
• Alternativa: ZIP completo compartido por un canal institucional seguro. Incluye el historial de Git cuando sea necesario para identificar versiones.

Ficha técnica de despliegue

1. Build. El equipo del laboratorio instala las dependencias, configura PostgreSQL y carga las variables acordadas.
2. Corrección. Si falla la construcción, el equipo investigador entrega una nueva versión; no se parchea código sin identificarlo.
3. Acceso. La URL pública y la credencial administrativa se comparten por canales separados.
4. Smoke test. El equipo investigador crea una sesión de prueba, completa los flujos y verifica la exportación.
5. Liberación. El servicio queda habilitado para las fechas y la carga informadas.

Exportación mínima después de cada sesión

• all_apps_wide: archivo longitudinal integrado de todas las aplicaciones;
• datos por aplicación: exportaciones necesarias para la estructura del estudio;
• PageTimes: tiempos de página cuando sean relevantes para calidad o diagnóstico.

Conserva para cada release: tag o commit, fecha, responsable, resumen de cambios, resultado de pruebas y decisión sobre la base de datos.

Checklist de implementación