Versionado y Rollout¶
Estado verificado al 28 de marzo de 2026. Nota de runtime: FastFN auto-instala dependencias locales por función desde
requirements.txt/package.json; enfastfn dev --nativenecesitas runtimes instalados en host, mientras quefastfn devdepende de Docker daemon activo. FastFN soporta versiones lado-a-lado (por ejemplov2) para poder publicar cambios sin romper a los clientes existentes.
1) Estructura de carpetas¶
El versionado se representa con una subcarpeta dentro de la funcion:
2) Ejemplo de codigo¶
Default (functions/hello/handler.py):
def main(req):
name = (req.get("query") or {}).get("name", "World")
return {"message": f"Hola desde V1, {name}"}
Version v2 (functions/hello/v2/handler.py):
def main(req):
name = (req.get("query") or {}).get("name", "World")
return {"status": "success", "data": {"greeting": f"Hola desde V2, {name}"}}
3) Llamar default vs version¶
Default (si existe handler.py en la raiz):
Version:
4) Patron de rollout¶
- Publica la carpeta
v2/. - Prueba con
GET /hello@v2. - Migra clientes gradualmente.
- Elimina la version vieja cuando el trafico llegue a cero.
Diagrama de Flujo¶
flowchart LR
A["Request del cliente"] --> B["Discovery de rutas"]
B --> C["Validación de políticas y método"]
C --> D["Ejecución del handler runtime"]
D --> E["Respuesta HTTP + paridad OpenAPI"]
Objetivo¶
Alcance claro, resultado esperado y público al que aplica esta guía.
Prerrequisitos¶
- CLI de FastFN disponible
- Dependencias por modo verificadas (Docker para
fastfn dev, OpenResty+runtimes parafastfn dev --native)
Checklist de Validación¶
- Los comandos de ejemplo devuelven estados esperados
- Las rutas aparecen en OpenAPI cuando aplica
- Las referencias del final son navegables
Solución de Problemas¶
- Si un runtime cae, valida dependencias de host y endpoint de health
- Si faltan rutas, vuelve a ejecutar discovery y revisa layout de carpetas
Ver también¶
Última revisión:
28 de marzo de 2026
·
Docs en fastfn.dev