VPS, nube y latencia; CI/CD con GitHub Actions.

Dónde corre un bot

La lección 7.2.1 dejó el bot en una imagen que corre igual en cualquier máquina con Docker. Esta decide qué máquina y cómo llega cada versión a ella. Hay cuatro opciones, y la pregunta que las ordena no es el precio sino el horizonte de la estrategia: cuánto vale un milisegundo para ella.

Una estrategia que rebalancea al cierre no gana nada con 50 ms menos: el precio de la orden de cierre es el mismo para todos. Una que reacciona a un cambio del libro en segundos sí, y la lección 4.3.2 midió cuánto se pierde con cada perfil de conexión. Lo que casi todas necesitan es otra cosa: que la máquina esté encendida, con IP fija (las listas blancas de IP de los brokers y exchanges la exigen, lección 4.4.5) y sin depender de la fibra de casa. Por eso el VPS es la opción por defecto y la nube se elige por la región, no por la marca:

flowchart TB
  A[Horizonte] --> B{Días u horas}
  B -->|sí| V[VPS cualquiera]
  B -->|no| C{Segundos}
  C -->|sí| R[Región del broker]
  C -->|no| K[Colocación]

Los proveedores publican dónde están sus regiones. Consultadas el 23 de octubre de 2026 en su documentación: AWS tiene us-east-1 (Norte de Virginia), eu-central-1 (Fráncfort), eu-west-2 (Londres) y eu-south-2 (España, que hay que activar expresamente); Google Cloud, us-east4 (Ashburn, Virginia), europe-west3 (Fráncfort) y europe-southwest1 (Madrid); Azure, Spain Central (Madrid); Hetzner Cloud, Falkenstein y Núremberg (Alemania), Helsinki, Ashburn, Hillsboro (Oregón) y Singapur. Los precios de AWS, Google Cloud y Azure dependen de la región, del tipo de máquina y del tráfico de salida, y cada uno tiene su calculadora oficial; la página de Hetzner Cloud anunciaba ese día planes desde 5,99 € al mes sin IVA (compartidos, «Cost-Optimized»), 6,49 € («Regular Performance») y 43,49 € con vCPU dedicadas («General Purpose»). No hay aquí recomendación de proveedor: hay una lista de preguntas (región, IP fija, precio de la salida de datos, copias, soporte) que la lección 7.2.4 completa con la continuidad.

El suelo de la latencia

Ninguna oferta comercial cambia la física. La luz en el vacío viaja a 299.792,458 km/s; en el vidrio de una fibra, a esa velocidad dividida por el índice de refracción, en torno a 1,47 (el valor que usó la lección 4.3.2): unos 204.000 km/s, dos tercios de la del vacío. La distancia mínima entre dos puntos de la Tierra es la ortodrómica, el arco de círculo máximo, que se calcula con la fórmula del semiverseno a partir de latitudes $\varphi$ y longitudes $\lambda$:

con $R \approx 6371$ km. Los lugares de la celda son ciudades donde hay mercados o regiones de nube: según ICE, sus centros de colocación dan acceso a ICE Futures en Basildon (Reino Unido) y Chicago y a la NYSE en Mahwah (Nueva Jersey)11Nota 1 · ICE, «ICE Global Network & Colocation» (https://www.ice.com/fixed-income-data-services/access-and-delivery/global-network), consultada el 23 de octubre de 2026: «ICE Colocation provides a highly deterministic path with the lowest latency to ICE Futures (Basildon, Chicago), as well as National Market System (NMS) and NYSE (Mahwah)».; Fráncfort y Ashburn son regiones de AWS, Google Cloud y Hetzner. Las coordenadas son las aproximadas del centro de cada localidad: una diferencia de unos kilómetros no cambia el resultado.

import math

C = 299_792.458                    # km/s en el vacío
N_FIBRA = 1.47
LUGAR = {
    "Madrid": (40.4168, -3.7038),
    "Fráncfort": (50.1109, 8.6821),
    "Basildon": (51.5761, 0.4887),
    "Mahwah": (41.0887, -74.1438),
    "Ashburn": (39.0438, -77.4874),
    "Chicago": (41.8781, -87.6298),
}

def ortodromica(a, b, r=6371.0):
    (f1, l1), (f2, l2) = (map(math.radians, LUGAR[x]) for x in (a, b))
    s = (math.sin((f2 - f1) / 2) ** 2
         + math.cos(f1) * math.cos(f2) * math.sin((l2 - l1) / 2) ** 2)
    return 2 * r * math.asin(math.sqrt(s))

def suelo_ms(km, n=N_FIBRA):
    return 2 * km / (C / n) * 1000   # ida y vuelta

PARES = [("Ashburn", "Mahwah"), ("Chicago", "Mahwah"),
         ("Fráncfort", "Basildon"), ("Madrid", "Fráncfort"),
         ("Madrid", "Basildon"), ("Basildon", "Mahwah"),
         ("Madrid", "Mahwah")]
SUELO = {}
print(f"{'par':<20}{'km':>7}{'vacío ms':>10}{'fibra ms':>10}")
for a, b in PARES:
    km = ortodromica(a, b)
    SUELO[(a, b)] = suelo_ms(km)
    print(f"{a + '-' + b:<20}{km:>7.0f}{suelo_ms(km, 1):>10.1f}"
          f"{SUELO[(a, b)]:>10.1f}")

par                      km  vacío ms  fibra ms
Ashburn-Mahwah          364       2.4       3.6
Chicago-Mahwah         1126       7.5      11.0
Fráncfort-Basildon      598       4.0       5.9
Madrid-Fráncfort       1446       9.6      14.2
Madrid-Basildon        1282       8.6      12.6
Basildon-Mahwah        5591      37.3      54.8
Madrid-Mahwah          5761      38.4      56.5

La figura de la cabecera ordena los pares de menor a mayor. Tres cosas que se leen en ella. Un bot en Madrid que opera en Nueva York empieza con 56,5 ms perdidos antes de hacer nada; uno en Ashburn (Virginia), con 3,6. Entre las dos orillas del Atlántico hay casi 55 ms de fibra como mínimo: ningún proveedor puede ofrecer «baja latencia transatlántica» por debajo de eso. Y la columna del vacío no es un adorno: los enlaces por radio viajan por el aire, casi a la velocidad de la luz en el vacío, y en rutas como Chicago-Nueva Jersey la diferencia entre 7,5 y 11,0 ms es la que separa a quien llega primero. Para un particular, la conclusión práctica es más modesta: el suelo dice qué mejora es imposible y cuándo moverse vale la pena.

Lo que se mide encima del suelo

Una latencia real es el suelo más todo lo demás: el cable no sigue la ortodrómica, cada router añade colas, el sistema operativo y el propio proceso añaden su parte. La lección 4.3.2 describió los seis perfiles de conexión de latencia4_rtt.parquet (datos sintéticos del curso, un ping cada 2 segundos durante 100 minutos). Aquí interesa otra cosa: cuánto se separa cada perfil de su suelo y qué hace su cola con un tiempo de espera.

import pandas as pd

lat = pd.read_parquet("latencia4_rtt.parquet")
med = lat.groupby("perfil")["rtt_us"].median() / 1000     # ms
for perfil, par in (("retail_espana_nueva_york", ("Madrid", "Mahwah")),
                    ("retail_espana_frankfurt",
                     ("Madrid", "Fráncfort"))):
    s = SUELO[par]
    print(f"{perfil:<26} mediana {med[perfil]:5.1f} ms  "
          f"suelo {s:4.1f} ms  x{med[perfil] / s:.2f}")

retail_espana_nueva_york   mediana  88.5 ms  suelo 56.5 ms  x1.57
retail_espana_frankfurt    mediana  31.1 ms  suelo 14.2 ms  x2.19

La conexión doméstica a Nueva York tarda 1,57 veces su suelo, y la de Fráncfort 2,19. Es lo habitual: la parte fija (rutas que no van en línea recta, saltos entre operadores, el último kilómetro) pesa más cuanto más corto es el trayecto. Para el tiempo de espera, sin embargo, la mediana es casi irrelevante. Un bot que envía una orden y espera la confirmación tiene que decidir cuánto esperar antes de considerarla perdida, y lo que cuenta es la cola:

PERFILES = ["retail_espana_nueva_york", "retail_espana_frankfurt",
            "vps_nueva_jersey", "nube_misma_region"]
PETICIONES_DIA = 2_000
filas = []
for p in PERFILES:
    x = lat.loc[lat["perfil"] == p, "rtt_us"] / 1000
    fila = {"perfil": p, "p99": x.quantile(0.99),
            "p99.9": x.quantile(0.999)}
    for t in (100, 200, 500):
        tarde = ((x > t) | x.isna()).mean()  # perdidos cuentan
        fila[f">{t}ms %"] = 100 * tarde
    filas.append(fila)
tab = pd.DataFrame(filas).set_index("perfil")
print(tab.round(2).to_string())
f = tab.loc["retail_espana_nueva_york", ">200ms %"] / 100
print(f"casa-NY, 200 ms: {f * PETICIONES_DIA:.0f} respuestas "
      f"tardías o perdidas al día")

                             p99   p99.9  >100ms %  >200ms %  >500ms %
perfil
retail_espana_nueva_york  126.36  506.39     16.77      0.87      0.50
retail_espana_frankfurt    45.94  184.61      0.47      0.20      0.13
vps_nueva_jersey            2.44    9.64      0.00      0.00      0.00
nube_misma_region           1.24    4.98      0.00      0.00      0.00
casa-NY, 200 ms: 17 respuestas tardías o perdidas al día

Desde casa a Nueva York, con 200 ms de espera, el 0,87 % de los mensajes llega tarde o no llega: con 2.000 peticiones al día (órdenes, cancelaciones, consultas), unas 17 veces al día el bot cree que algo se perdió. Si en cada una reenvía la orden sin clave de idempotencia, duplica la posición (es lo que pasó con R00113 y R00114 en la lección 4.5.5). Subir la espera a 500 ms lo baja al 0,50 %, del que 0,37 puntos son paquetes perdidos de verdad (11 de 3.000), y el coste es reaccionar más tarde a una desconexión real. Con 100 ms, uno de cada seis mensajes llegaría «tarde». Desde un VPS en Nueva Jersey el problema casi desaparece: ningún ping supera los 100 ms ni se pierde. Esa es la mejora que compra un VPS cerca del broker, más que el milisegundo de la mediana: una cola corta.

La regla práctica que sale de aquí: el tiempo de espera se fija con un percentil alto de la latencia medida desde la máquina donde corre el bot, no desde el portátil; se revisa cuando se cambia de proveedor o de región; y el reintento de una orden siempre consulta antes por su clave. Medir es barato: un ping cada pocos segundos a la pasarela del broker, guardado como serie temporal, es una de las métricas de la lección 7.2.3.

El camino del código al servidor

Con la máquina elegida, falta decidir cómo llega cada versión. A mano (entrar por SSH, git pull, reiniciar) funciona hasta el día en que se despliega un commit que no pasaba las pruebas, o con una dependencia distinta de la del portátil. La integración y el despliegue continuos (CI/CD) convierten ese ritual en un proceso que no se salta pasos:

flowchart TB
  P[git push] --> T[Pruebas y linter]
  T -->|verde| I[Imagen con digest]
  T -->|rojo| X[Se para]
  I --> A[Aprobación]
  A --> D[Despliegue]

GitHub Actions ejecuta ese proceso en máquinas de GitHub cada vez que pasa algo en el repositorio. Según su documentación de facturación, el uso es gratis en repositorios públicos con los runners estándar y, en privados, el plan Free incluye 2.000 minutos al mes22Nota 2 · GitHub Docs, «GitHub Actions billing» (https://docs.github.com/en/billing/concepts/product-billing/github-actions), consultada el 23 de octubre de 2026: uso gratuito en repositorios públicos con runners estándar; 2.000 minutos al mes en GitHub Free y GitHub Free for organizations, 3.000 en Pro y Team.. Un workflow es un fichero YAML en .github/workflows/. El de la lección tiene tres trabajos: pruebas (uv, linter, formato, pytest y una comprobación de los ejemplos del README, el equivalente a check:curso-code de este curso), imagen (construye y publica la imagen de la lección 7.2.1) y despliegue (actualiza el servidor). Las acciones van fijadas por el SHA completo de su commit; los SHA son los de actions/checkout v7.0.1 y astral-sh/setup-uv v10.3.2, consultados con git ls-remote en los repositorios oficiales el 23 de octubre de 2026:

from pathlib import Path

SHA = {
    "checkout": "3d3c42e5aac5ba805825da76410c181273ba90b1",
    "setup-uv": "07a047e608db84b3d8c06cd9a7c7dcc9c355c18e",
}
WORKFLOW = """\
name: ci
on:
  push:
    branches: [main]
  pull_request:
permissions:
  contents: read
jobs:
  pruebas:
    runs-on: ubuntu-24.04
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@{checkout}  # v7.0.1
      - uses: astral-sh/setup-uv@{setup-uv}  # v10.3.2
        with:
          version: "0.13.5"
          enable-cache: true
      - name: dependencias
        run: uv sync --locked
      - name: linter
        run: uv run ruff check .
      - name: pruebas
        run: uv run pytest -q
      - name: ejemplos del README
        run: uv run python -m doctest README.md
  imagen:
    needs: pruebas
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-24.04
    timeout-minutes: 20
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@{checkout}  # v7.0.1
      - name: construir y publicar
        run: ./scripts/imagen.sh
  despliegue:
    needs: imagen
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-24.04
    timeout-minutes: 10
    environment: produccion
    concurrency:
      group: despliegue
      cancel-in-progress: false
    steps:
      - uses: actions/checkout@{checkout}  # v7.0.1
      - name: desplegar por digest
        env:
          SSH_KEY: ${{{{ secrets.DEPLOY_SSH_KEY }}}}
          HOST: ${{{{ vars.DEPLOY_HOST }}}}
        run: ./scripts/desplegar.sh "$HOST"
""".format(**SHA)
Path("ci.yml").write_text(WORKFLOW)
print(len(WORKFLOW.splitlines()), "líneas")

53 líneas

Cada pieza tiene un motivo en la documentación de GitHub. permissions: contents: read en el nivel superior: el token del workflow (GITHUB_TOKEN) solo puede leer, y el trabajo imagen amplía lo justo para publicar en el registro de paquetes; en cuanto se declara un permiso, los no declarados pasan a none33Nota 3 · GitHub Docs, «Workflow syntax for GitHub Actions»: permissions, timeout-minutes («Default: 360»), needs y concurrency.. timeout-minutes, porque el valor por defecto es 360 minutos: un test colgado consumiría seis horas de cuota. needs encadena los trabajos y, si uno falla, los que lo necesitan se saltan. environment: produccion permite exigir revisores: GitHub deja configurar hasta seis personas o equipos y basta con que uno apruebe para que el trabajo siga44Nota 4 · GitHub Docs, «Deployments and environments», «Required reviewers» (https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments).. concurrency con cancel-in-progress: false impide dos despliegues a la vez sin cortar uno a medias. Y el secreto entra por env, no dentro del texto de run.

Un validador de workflows

Las reglas de seguridad de GitHub se pueden comprobar antes de hacer push. Hay una trampa al leer el YAML con PyYAML: la clave on del workflow se convierte en el booleano True, porque PyYAML sigue YAML 1.1, donde on, yes y off son booleanos. El validador lo tiene en cuenta:

import re
import yaml

SHA40 = re.compile(r"@[0-9a-f]{40}$")
EXPR = re.compile(r"\$\{\{\s*([^}]*?)\s*\}\}")
NOMBRE_SECRETO = re.compile(r"^(?!GITHUB_)[A-Za-z_][A-Za-z0-9_]*$")

def validar_workflow(texto):
    w = yaml.safe_load(texto)
    on = w.get("on", w.get(True, {}))      # PyYAML: on -> True
    out = []
    if "pull_request_target" in (on or {}):
        out.append(("-", "GA05", "pull_request_target"))
    if "permissions" not in w:
        out.append(("-", "GA02", "sin permissions en el nivel "
                                 "superior"))
    for nj, job in w["jobs"].items():
        if "timeout-minutes" not in job:
            out.append((nj, "GA03", "sin timeout-minutes (360)"))
        for st in job.get("steps", []):
            uses = st.get("uses", "")
            if uses and not SHA40.search(uses):
                out.append((nj, "GA01", f"acción sin SHA: {uses}"))
            run = st.get("run", "")
            for e in EXPR.findall(run):
                if e.startswith(("secrets.", "github.event.")):
                    out.append((nj, "GA04", f"expresión en run: {e}"))
            for e in EXPR.findall(str(st.get("env", {}))):
                if e.startswith("secrets.") and \
                        not NOMBRE_SECRETO.match(e[8:]):
                    out.append((nj, "GA08", f"nombre de secreto: {e}"))
            if "uv sync" in run and "--locked" not in run \
                    and "--frozen" not in run:
                out.append((nj, "GA07", "uv sync sin --locked"))
        if "desplieg" in nj and not ("environment" in job
                                     and "needs" in job):
            out.append((nj, "GA06", "despliegue sin environment "
                                    "o sin needs"))
    return out

INGENUO = """\
name: ci
on: [push, pull_request_target]
jobs:
  todo:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: astral-sh/setup-uv@main
      - run: uv sync && uv run pytest
      - run: echo "${{ github.event.pull_request.title }}"
  despliegue:
    runs-on: ubuntu-latest
    steps:
      - run: ./desplegar.sh ${{ secrets.DEPLOY_SSH_KEY }}
"""
print(yaml.safe_load(INGENUO).keys())
for nombre, w in (("ingenuo", INGENUO), ("bueno", WORKFLOW)):
    h = validar_workflow(w)
    print(f"{nombre}: {len(h)} hallazgos")
    for job, cod, msg in h:
        print(f"  {job:<10} {cod} {msg}")

dict_keys(['name', True, 'jobs'])
ingenuo: 10 hallazgos
  -          GA05 pull_request_target
  -          GA02 sin permissions en el nivel superior
  todo       GA03 sin timeout-minutes (360)
  todo       GA01 acción sin SHA: actions/checkout@v4
  todo       GA01 acción sin SHA: astral-sh/setup-uv@main
  todo       GA07 uv sync sin --locked
  todo       GA04 expresión en run: github.event.pull_request.title
  despliegue GA03 sin timeout-minutes (360)
  despliegue GA04 expresión en run: secrets.DEPLOY_SSH_KEY
  despliegue GA06 despliegue sin environment o sin needs
bueno: 0 hallazgos

Diez hallazgos en el ingenuo y ninguno en el bueno. Los más graves son los de las reglas GA04 y GA05. La guía de seguridad de GitHub explica la inyección de scripts: una expresión ${{ … }} dentro de run se sustituye en el texto del script antes de ejecutarlo, así que un título de pull request como a"; curl … # se ejecuta como un comando; la solución es pasar el valor a una variable de entorno intermedia55Nota 5 · GitHub Docs, «Secure use reference», secciones «Use an intermediate environment variable» y «Mitigating the risks of untrusted code checkout».. Con los secretos, el mismo patrón evita además que el valor aparezca en la línea de comandos del proceso. Y pull_request_target corre con permisos del repositorio y acceso a los secretos aunque la pull request venga de un fork: con un checkout de ese código, cualquiera puede ejecutar lo que quiera con las claves de despliegue. La guía pide evitarlo si no es imprescindible.

Sobre GA01 hay una novedad. La guía recomendaba hasta ahora fijar cada acción a un SHA completo; en octubre de 2026 documenta además un lockfile de dependencias de workflows (.github/workflows/actions.lock, generado con la extensión gh actions-lock de la CLI), en vista previa pública, que fija también las dependencias transitivas de las acciones y que GitHub presenta como la protección más fuerte para quien lo adopte66Nota 6 · GitHub Docs, «Workflow dependency lockfiles» (https://docs.github.com/en/actions/concepts/security/workflow-dependency-lockfiles), consultada el 23 de octubre de 2026: «Workflow dependency lockfiles are in public preview and subject to change».. El SHA sigue siendo la opción para quien no lo use.

Un runner local

Para ver el pipeline funcionar sin GitHub, la celda siguiente crea un repositorio de prueba con un bot mínimo (una señal de cruce de medias, su prueba y un README con un ejemplo ejecutable), lo confirma con git y ejecuta el workflow paso a paso. El runner traduce cada run a algo que se puede hacer sin red en el entorno del curso, y lo dice: uv sync --locked se reduce a comprobar que el lockfile corresponde a pyproject.toml (uv lo comprueba resolviendo de nuevo; aquí, con un hash); uv run X se ejecuta con el Python del curso; y como Ruff no está en el entorno principal, el linter se sustituye por una sola de sus reglas, la F401 (importaciones sin usar), escrita con ast. Las acciones uses y los scripts de imagen y despliegue se simulan. Git se configura con un autor de prueba, sin leer la configuración global de quien ejecuta la lección, y con fechas fijas para que los SHA sean siempre los mismos.

import ast
import hashlib
import os
import subprocess
import sys

REPO = Path("repo-ci").resolve()
GIT_ENV = {**os.environ, "GIT_CONFIG_GLOBAL": os.devnull,
           "GIT_CONFIG_NOSYSTEM": "1",
           "GIT_AUTHOR_NAME": "Curso PPT",
           "GIT_AUTHOR_EMAIL": "[email protected]",
           "GIT_COMMITTER_NAME": "Curso PPT",
           "GIT_COMMITTER_EMAIL": "[email protected]"}

def git(*args, fecha="2026-10-23T09:00:00Z"):
    env = {**GIT_ENV, "GIT_AUTHOR_DATE": fecha,
           "GIT_COMMITTER_DATE": fecha}
    r = subprocess.run(["git", *args], cwd=REPO, env=env,
                       capture_output=True, text=True, check=True)
    return r.stdout.strip()

PYPROJECT = '[project]\nname = "bot"\nversion = "0.1.0"\n'
ESTRATEGIA = '''\
def senal(precios, corta=3, larga=5):
    """1 si la media corta supera a la larga; si no, 0.

    >>> senal([1, 2, 3, 4, 5, 6])
    1
    """
    if len(precios) < larga:
        return 0
    m_c = sum(precios[-corta:]) / corta
    m_l = sum(precios[-larga:]) / larga
    return 1 if m_c > m_l else 0
'''
TEST = '''\
from estrategia import senal

def test_sube():
    assert senal([1, 2, 3, 4, 5, 6]) == 1

def test_baja():
    assert senal([6, 5, 4, 3, 2, 1]) == 0

def test_pocos_datos():
    assert senal([1, 2]) == 0
'''
README = """# Bot

    >>> from estrategia import senal
    >>> senal([10, 10, 10, 10, 11])
    1
"""
FICHEROS = {"pyproject.toml": PYPROJECT, "src/estrategia.py": ESTRATEGIA,
            "tests/test_estrategia.py": TEST, "README.md": README,
            ".github/workflows/ci.yml": WORKFLOW}
FICHEROS["uv.lock"] = ("# pyproject-sha256: " + hashlib.sha256(
    PYPROJECT.encode()).hexdigest() + "\n")
REPO.mkdir(exist_ok=True)
for ruta, texto in FICHEROS.items():
    (REPO / ruta).parent.mkdir(parents=True, exist_ok=True)
    (REPO / ruta).write_text(texto)
git("init", "-q", "-b", "main")
git("add", "-A")
git("commit", "-q", "-m", "bot inicial")
print(git("log", "--oneline"))

b22b953 bot inicial

from graphlib import TopologicalSorter

def f401(raiz):
    """Importaciones sin usar (regla F401 de Ruff), con ast."""
    malos = []
    for f in sorted(raiz.rglob("*.py")):
        arbol = ast.parse(f.read_text())
        usados = {n.id for n in ast.walk(arbol)
                  if isinstance(n, ast.Name)}
        for n in ast.walk(arbol):
            if isinstance(n, (ast.Import, ast.ImportFrom)):
                for a in n.names:
                    nombre = (a.asname or a.name).split(".")[0]
                    if nombre not in usados:
                        malos.append(f"{f.relative_to(raiz)}:"
                                     f"{n.lineno} F401 {nombre}")
    return malos

def paso(run):
    """(ok, resumen) de un `run`, traducido a algo local."""
    env = {**os.environ, "PYTHONPATH": str(REPO / "src"),
           "PYTHONDONTWRITEBYTECODE": "1"}
    if run.startswith("uv sync --locked"):
        lock = (REPO / "uv.lock").read_text()
        h = hashlib.sha256((REPO / "pyproject.toml")
                           .read_bytes()).hexdigest()
        return h in lock, "lockfile al día" if h in lock else \
            "uv.lock no corresponde a pyproject.toml"
    if run.startswith("uv run ruff check"):
        malos = f401(REPO)
        return not malos, "; ".join(malos) or "sin hallazgos"
    if run.startswith("uv run "):
        cmd = run.split()[2:]
        if cmd[0] == "pytest":
            cmd = ["python", "-m", "pytest", "-p",
                   "no:cacheprovider", *cmd[1:]]
        r = subprocess.run([sys.executable, *cmd[1:]], cwd=REPO,
                           env=env, capture_output=True, text=True)
        ult = (r.stdout.strip().splitlines() or ["ok"])[-1]
        return r.returncode == 0, re.sub(r" in [\d.]+s", "", ult)
    return True, "(simulado)"

def ejecutar(texto, ref="refs/heads/main"):
    w = yaml.safe_load(texto)
    jobs = w["jobs"]
    orden = TopologicalSorter({n: set([j["needs"]] if isinstance(
        j.get("needs"), str) else j.get("needs", []))
        for n, j in jobs.items()}).static_order()
    estado = {}
    for nj in orden:
        job = jobs[nj]
        needs = job.get("needs", [])
        needs = [needs] if isinstance(needs, str) else needs
        cond = job.get("if", "")
        m = re.fullmatch(r"github\.ref == '(.+)'", cond)
        if any(estado[n] != "ok" for n in needs) or (m and
                                                     m[1] != ref):
            estado[nj] = "saltado"
            print(f"[{nj}] saltado")
            continue
        estado[nj] = "ok"
        for st in job["steps"]:
            nombre = st.get("name") or st["uses"].split("@")[0]
            ok, res = (True, "acción simulada") if "uses" in st \
                else paso(st["run"])
            print(f"[{nj}] {nombre}: {'ok' if ok else 'FALLA'}"
                  f" · {res}")
            if not ok:
                estado[nj] = "falla"
                break
    return estado

print(ejecutar((REPO / ".github/workflows/ci.yml").read_text()))

[pruebas] actions/checkout: ok · acción simulada
[pruebas] astral-sh/setup-uv: ok · acción simulada
[pruebas] dependencias: ok · lockfile al día
[pruebas] linter: ok · sin hallazgos
[pruebas] pruebas: ok · 3 passed
[pruebas] ejemplos del README: ok · ok
[imagen] actions/checkout: ok · acción simulada
[imagen] construir y publicar: ok · (simulado)
[despliegue] actions/checkout: ok · acción simulada
[despliegue] desplegar por digest: ok · (simulado)
{'pruebas': 'ok', 'imagen': 'ok', 'despliegue': 'ok'}

Todo en verde: el lockfile corresponde, el linter no encuentra nada, las tres pruebas y el ejemplo del README pasan, y los trabajos de imagen y despliegue se ejecutan (simulados) porque el commit está en main. Ahora, dos commits rotos. El primero invierte la comparación de las medias, un error de signo de los que pasan desapercibidos en una revisión rápida; el segundo lo corrige pero deja una importación que no se usa:

def commit(ruta, texto, mensaje, fecha):
    (REPO / ruta).write_text(texto)
    git("add", "-A")
    git("commit", "-q", "-m", mensaje, fecha=fecha)
    return git("rev-parse", "--short", "HEAD")

roto = ESTRATEGIA.replace("m_c > m_l", "m_c < m_l")
print(commit("src/estrategia.py", roto, "estrategia: signo",
             "2026-10-23T10:00:00Z"))
print(ejecutar(WORKFLOW))
arreglado = "import numpy as np\n" + ESTRATEGIA
print(commit("src/estrategia.py", arreglado, "estrategia: arregla",
             "2026-10-23T11:00:00Z"))
print(ejecutar(WORKFLOW))

f304ac3
[pruebas] actions/checkout: ok · acción simulada
[pruebas] astral-sh/setup-uv: ok · acción simulada
[pruebas] dependencias: ok · lockfile al día
[pruebas] linter: ok · sin hallazgos
[pruebas] pruebas: FALLA · 2 failed, 1 passed
[imagen] saltado
[despliegue] saltado
{'pruebas': 'falla', 'imagen': 'saltado', 'despliegue': 'saltado'}
f37293f
[pruebas] actions/checkout: ok · acción simulada
[pruebas] astral-sh/setup-uv: ok · acción simulada
[pruebas] dependencias: ok · lockfile al día
[pruebas] linter: FALLA · src/estrategia.py:1 F401 np
[imagen] saltado
[despliegue] saltado
{'pruebas': 'falla', 'imagen': 'saltado', 'despliegue': 'saltado'}

El error de signo lo cazarían las pruebas y también el ejemplo del README, pero el runner se para en el primer paso que falla, como GitHub: pruebas falla en pytest (dos de tres pruebas), imagen y despliegue se saltan y el servidor sigue con la versión anterior. El segundo commit pasa las pruebas, pero la importación sin usar para el linter antes de llegar a ellas. Un linter estricto parece una molestia hasta que una importación sobrante es la pista de un cambio a medias. En una pull request (ref distinto de main) los trabajos de imagen y despliegue se saltan por su if, y solo corren las pruebas: es el ejercicio 1.

Secretos y despliegue

El trabajo de despliegue necesita una credencial para entrar en el servidor. La lección 4.4.5 trató las credenciales del broker: dónde viven, permisos mínimos y rotación. Las del pipeline siguen las mismas reglas, con tres matices propios de GitHub:

• Un secreto por propósito y con el mínimo alcance. La clave SSH de despliegue solo sirve para ese servidor y para un usuario que solo puede ejecutar el script de despliegue (command= en authorized_keys). Las claves del broker no van a GitHub: el servidor las tiene y el pipeline nunca las ve.
• Secretos de entorno. Definidos en el entorno produccion, solo los ve un trabajo que declara ese entorno, y ese trabajo puede exigir la aprobación de un revisor. GitHub tacha los secretos en los registros, y su documentación pide no usar datos estructurados (un JSON entero) como valor de un secreto para que el tachado funcione77Nota 7 · GitHub Docs, «Secrets reference» (https://docs.github.com/en/actions/reference/security/secrets)..
• Desplegar por digest. El trabajo imagen publica la imagen y anota su digest; el de despliegue le pide al servidor ese digest exacto (docker compose pull con la imagen fijada y up -d --wait), y guarda el anterior para volver atrás. La comprobación de salud de la lección 7.2.1 decide si el despliegue terminó bien.

Para un bot que opera, hay una regla más que ningún workflow trae por defecto: no se despliega con el mercado abierto ni con posiciones a medio gestionar. El trabajo de despliegue puede comprobarlo (una llamada al propio bot que diga si está en un estado seguro para parar, como el arranque conciliado de la lección 4.5.5), y el entorno protegido añade una persona que lo mira.

Los comandos reales, que en el entorno del curso no se ejecutan, serían estos:

for args in (["git", "ls-remote", "https://github.com/actions/checkout",
              "refs/tags/v7.0.1"],
             ["uv", "lock", "--check"],
             ["uvx", "ruff", "check", "."],
             ["gh", "workflow", "run", "ci", "--ref", "main"]):
    subprocess.run(args, cwd=REPO, check=True)

Ejercicios

1. Ejecuta el workflow sobre el último commit como si viniera de una pull request (ref="refs/pull/7/merge"), primero con la importación sobrante y después sin ella. ¿Qué trabajos corren?

print(ejecutar(WORKFLOW, ref="refs/pull/7/merge"))
commit("src/estrategia.py", ESTRATEGIA, "quita la importación",
       "2026-10-23T12:00:00Z")
print(ejecutar(WORKFLOW, ref="refs/pull/7/merge"))

[pruebas] actions/checkout: ok · acción simulada
[pruebas] astral-sh/setup-uv: ok · acción simulada
[pruebas] dependencias: ok · lockfile al día
[pruebas] linter: FALLA · src/estrategia.py:1 F401 np
[imagen] saltado
[despliegue] saltado
{'pruebas': 'falla', 'imagen': 'saltado', 'despliegue': 'saltado'}
[pruebas] actions/checkout: ok · acción simulada
[pruebas] astral-sh/setup-uv: ok · acción simulada
[pruebas] dependencias: ok · lockfile al día
[pruebas] linter: ok · sin hallazgos
[pruebas] pruebas: ok · 3 passed
[pruebas] ejemplos del README: ok · ok
[imagen] saltado
[despliegue] saltado
{'pruebas': 'ok', 'imagen': 'saltado', 'despliegue': 'saltado'}

2. Con latencia4_rtt.parquet, calcula para cada perfil el tiempo de espera mínimo (en ms, redondeado al alza a la decena) que deja como mucho el 0,1 % de pings por encima, sin contar los perdidos. ¿Por qué no tiene sentido usar el mismo valor para todos?

import numpy as np

for p in PERFILES:
    x = lat.loc[(lat["perfil"] == p) & ~lat["perdido"],
                "rtt_us"] / 1000
    t = np.ceil(x.quantile(0.999) / 10) * 10
    print(f"{p:<26} {t:>6.0f} ms  ({(x > t).mean():.3%} por "
          f"encima)")

retail_espana_nueva_york      510 ms  (0.100% por encima)
retail_espana_frankfurt       190 ms  (0.100% por encima)
vps_nueva_jersey               10 ms  (0.100% por encima)
nube_misma_region              10 ms  (0.100% por encima)

3. Un compañero propone desplegar automáticamente cada push a main en el servidor donde el bot opera con dinero real, «porque las pruebas ya pasan». ¿Qué añadirías antes de aceptarlo?