{"id":171,"date":"2026-03-09T03:53:43","date_gmt":"2026-03-09T03:53:43","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/configuracin-de-github-actions-para-aplicaciones-p\/"},"modified":"2026-03-18T22:00:20","modified_gmt":"2026-03-18T22:00:20","slug":"configuracin-de-github-actions-para-aplicaciones-p","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/configuracin-de-github-actions-para-aplicaciones-p\/","title":{"rendered":"GitHub Actions para Python: lo que aprend\u00ed despu\u00e9s de romper producci\u00f3n tres veces"},"content":{"rendered":"

Era un viernes<\/a> a las<\/a> 4pm cuando empuj\u00e9 un cambio que parec\u00eda inofensivo a main. Sin CI configurado correctamente, el deploy<\/a> sali\u00f3 sin correr las pruebas. El error era simple \u2014 un import que funcionaba en mi m\u00e1quina pero no en el<\/a> servidor \u2014 y tres horas despu\u00e9s segu\u00eda intentando hacer rollback mientras mis compa\u00f1eros de equipo me mandaban mensajes. Somos un equipo de cinco personas, as\u00ed que “compa\u00f1eros” es un t\u00e9rmino generoso para “todos mirando el mismo dashboard rojo”.<\/p>\n

Esa noche me promet\u00ed configurar GitHub Actions<\/a> correctamente. No copiar un workflow de Stack Overflow y esperar que funcionara, sino entender qu\u00e9 hace cada parte.<\/p>\n

Esto es lo que aprend\u00ed<\/a> en las siguientes dos semanas<\/a> de prueba y error.<\/p>\n

El pipeline m\u00ednimo que realmente<\/a> funciona<\/h2>\n

Hay una versi\u00f3n del workflow de Python que circula por internet que instala dependencias sin cach\u00e9, corre pytest sin flags \u00fatiles, y usa ubuntu-latest<\/code> sin pensar. Funciona. Pero es lento y te va a cobrar minutos de GitHub Actions<\/a> innecesariamente.<\/p>\n

El setup m\u00ednimo que yo uso ahora, para un proyecto Django mediano con unas 300 pruebas:<\/p>\n

name: CI\n\non:\n  push:\n    branches: [main, develop]\n  pull_request:\n    branches: [main]\n\njobs:\n  test:\n    runs-on: ubuntu-22.04  # versi\u00f3n fija, no latest\n\n    services:\n      postgres:\n        image: postgres:15\n        env:\n          POSTGRES_PASSWORD: postgres\n          POSTGRES_DB: testdb\n        options: >-\n          --health-cmd pg_isready\n          --health-interval 10s\n          --health-timeout 5s\n          --health-retries 5\n        ports:\n          - 5432:5432\n\n    steps:\n      - uses: actions\/checkout@v4\n\n      - name: Configurar Python\n        uses: actions\/setup-python@v5\n        with:\n          python-version: "3.12"\n          cache: "pip"  # esto solo funciona si tienes requirements.txt\n\n      - name: Instalar dependencias\n        run: |\n          python -m pip install --upgrade pip\n          pip install -r requirements.txt\n          pip install -r requirements-dev.txt\n\n      - name: Correr pruebas\n        env:\n          DATABASE_URL: postgresql:\/\/postgres:postgres@localhost:5432\/testdb\n          DJANGO_SETTINGS_MODULE: myapp.settings.test\n        run: |\n          pytest --tb=short -q --cov=myapp --cov-report=term-missing\n<\/code><\/pre>\n
Dos cosas que vale la pena<\/a> se\u00f1alar. Primero, uso ubuntu-22.04<\/code> en lugar de ubuntu-latest<\/code>. Aprend\u00ed esto de mala manera cuando GitHub actualiz\u00f3 ubuntu-latest<\/code> a 24.04 en agosto pasado y una dependencia de sistema que ten\u00eda dej\u00f3 de compilar. Dos horas de debugging para darme cuenta de que el problema era el runner, no mi c\u00f3digo. Ahora fijo la versi\u00f3n y la actualizo intencionalmente.<\/p>\n
Segundo, el bloque services<\/code> para Postgres. Mucha gente usa SQLite en CI porque es m\u00e1s simple, pero si tu app usa Postgres en producci\u00f3n<\/a>, tienes que probar con Postgres. Las diferencias en comportamiento de constraints y tipos de datos<\/a> son reales. Yo usaba SQLite en CI durante seis meses y ten\u00eda pruebas que pasaban pero bugs que solo aparec\u00edan en prod. No hagas eso.<\/p>\n
Cach\u00e9: d\u00f3nde perd\u00ed dos d\u00edas sin necesidad<\/h2>\n
Okay, aqu\u00ed est\u00e1 el problema. La cach\u00e9 de pip que ves en setup-python@v5<\/code> con cache: \"pip\"<\/code> es conveniente pero tiene una limitaci\u00f3n importante: invalida la cach\u00e9 completa cuando requirements.txt<\/code> cambia. Si agregas un paquete, pierdes toda la cach\u00e9. Para proyectos<\/a> con dependencias pesadas como torch<\/code> o tensorflow<\/code>, eso es 10-15 minutos de descarga.<\/p>\n
La soluci\u00f3n que termin\u00e9 usando es hacer el hash solo del archivo de requirements:<\/p>\n
      - name: Cache de dependencias pip\n        uses: actions\/cache@v4\n        id: cache-pip\n        with:\n          path: ~\/.cache\/pip\n          key: ${{ runner.os }}-pip-${{ hashFiles('**\/requirements*.txt') }}\n          restore-keys: |\n            ${{ runner.os }}-pip-\n\n      - name: Instalar dependencias\n        if: steps.cache-pip.outputs.cache-hit != 'true'\n        run: pip install -r requirements.txt -r requirements-dev.txt\n<\/code><\/pre>\n
El restore-keys<\/code> es la parte que m\u00e1s me tard\u00e9 en entender. Cuando no hay un hit exacto de cach\u00e9, GitHub busca una cach\u00e9 parcial usando esos prefijos. As\u00ed que aunque hayas cambiado un paquete, puede reusar la mayor\u00eda de lo que<\/a> ya descarg\u00f3. En la pr\u00e1ctica, esto redujo mis tiempos de CI de 4 minutos a menos de 90 segundos en ese proyecto.<\/p>\n
Eso s\u00ed \u2014 si usas pyproject.toml<\/code> con Poetry o uv (que es lo que<\/a> yo uso ahora para proyectos<\/a> nuevos), el enfoque es diferente. Con uv espec\u00edficamente, tienes que cachear ~\/.cache\/uv<\/code> y el lockfile cambia con m\u00e1s frecuencia. Tu mileage puede variar dependiendo de qu\u00e9 tan seguido actualizas dependencias.<\/p>\n
Variables de entorno y secretos (sin el error que yo comet\u00ed)<\/h2>\n
Comet\u00ed el error cl\u00e1sico: hardcodear una API<\/a> key de prueba directamente en el<\/a> workflow YAML. No era una key de producci\u00f3n<\/a>, era de un servicio de testing, pero igual qued\u00f3 en el<\/a> historial de git p\u00fablico. No fue catastr\u00f3fico pero fue inc\u00f3modo, y me cost\u00f3 invalidar y rotar credenciales que t\u00e9cnicamente no eran cr\u00edticas.<\/p>\n
La forma correcta es usar GitHub Secrets, que seguro ya sabes \u2014 pero hay detalles que no son obvios.<\/p>\n
Primero, los secretos no est\u00e1n disponibles en pull requests de forks por razones de seguridad obvias. Si tu proyecto es open source y quieres que los contributors externos puedan correr CI, tienes que dise\u00f1ar tus pruebas para que funcionen sin secretos reales, usando mocks o servicios alternativos.<\/p>\n
Segundo, para manejar configuraci\u00f3n que var\u00eda entre ambientes (dev, staging, prod), prefiero usar variables de entorno a nivel de repository combinadas con secretos:<\/p>\n
    env:\n      # Variables que no son secretas van aqu\u00ed directamente\n      PYTHON_ENV: test\n      LOG_LEVEL: WARNING\n\n    steps:\n      - name: Correr pruebas de integraci\u00f3n\n        env:\n          # Secretos solo donde se necesitan\n          STRIPE_TEST_KEY: ${{ secrets.STRIPE_TEST_KEY }}\n          SENDGRID_API_KEY: ${{ secrets.SENDGRID_API_KEY }}\n        run: pytest tests\/integration\/\n<\/code><\/pre>\n
Poner los secretos a nivel de step en lugar de a nivel de job es una pr\u00e1ctica que adopt\u00e9 despu\u00e9s de<\/a> leer el advisory de seguridad de GitHub<\/a> sobre exposure en logs. Si uno de tus steps falla de forma inesperada, la superficie de exposici\u00f3n es menor.<\/p>\n
Algo que no esperaba encontrar: GitHub tiene “environment secrets” separados de los repository secrets. Puedes crear un environment llamado production<\/code> con sus propios secretos y requerir aprobaci\u00f3n manual antes de que un workflow lo use. Para deploys a prod, esto me parece mucho m\u00e1s sensato que dar acceso autom\u00e1tico a cualquier push que llegue a main.<\/p>\n
Matrices de prueba: m\u00e1s no siempre es mejor<\/h2>\n
\u00bfRealmente necesitas probar en Python 3.9, 3.10, 3.11 y 3.12, en Ubuntu, macOS y Windows? Hay una tentaci\u00f3n real de<\/a> armar esa matrix. Se ve profesional. Los badges se ven bien en el<\/a> README.<\/p>\n
Pero para la mayor\u00eda de aplicaciones web \u2014 y aqu\u00ed soy un poco heterodoxo \u2014 eso es excesivo. Estoy hablando de aplicaciones que t\u00fa controlas y deploys t\u00fa mismo, no de una librer\u00eda open source que otros instalan.<\/p>\n
Si deploys en Python 3.12 en Linux, prueba en Python 3.12 en Linux. Agrega 3.11 si tienes usuarios que todav\u00eda la usan. No pruebes en Windows si no deploys en Windows.<\/p>\n
Lo que s\u00ed uso matrices para:<\/p>\n
  test:\n    strategy:\n      fail-fast: false\n      matrix:\n        python-version: ["3.11", "3.12"]\n        # Solo esto. No m\u00e1s.\n\n    runs-on: ubuntu-22.04\n\n    steps:\n      - uses: actions\/checkout@v4\n\n      - name: Setup Python ${{ matrix.python-version }}\n        uses: actions\/setup-python@v5\n        with:\n          python-version: ${{ matrix.python-version }}\n<\/code><\/pre>\n
El fail-fast: false<\/code> es importante. Por defecto, si una combinaci\u00f3n de la matrix falla, GitHub cancela las dem\u00e1s. A veces quieres ver todos los fallos para entender si es un problema espec\u00edfico de versi\u00f3n. Depende del contexto, pero yo lo desactivo casi siempre.<\/p>\n
Para proyectos que son librer\u00edas (tengo un par de paquetes internos que otros equipos usan), ah\u00ed s\u00ed ampl\u00edo la matriz. Pero incluso entonces, no pruebo en Windows a menos que alguien realmente lo necesite. El tiempo de CI de Windows runners es m\u00e1s lento y m\u00e1s caro.<\/p>\n
Lo que har\u00eda hoy empezando desde cero<\/h2>\n
Tres proyectos distintos, varios meses de iteraci\u00f3n, y ahora tengo opiniones fuertes sobre c\u00f3mo estructurar esto.<\/p>\n
Para un proyecto nuevo de Python que va a producci\u00f3n<\/a>: empezar\u00eda con un workflow de CI que corra en cada PR y en push a main. Nada m\u00e1s al principio. No CD automatizado, no deploy<\/a> autom\u00e1tico. Los deploys autom\u00e1ticos sin entender bien tus workflows son la causa n\u00famero uno de los viernes de terror que describ\u00ed al inicio.<\/p>\n
El CD lo agregar\u00eda despu\u00e9s, cuando el equipo conf\u00ede en el<\/a> CI. Y lo configurar\u00eda para que requiera aprobaci\u00f3n manual para producci\u00f3n<\/a> \u2014 ya sea con GitHub Environments o simplemente con un workflow separado que se dispara manualmente con workflow_dispatch<\/code>.<\/p>\n
Honestamente, lo que<\/a> m\u00e1s me sorprendi\u00f3 al configurar todo esto es<\/a> cu\u00e1nto importa el orden de los steps. Poner el cache step antes de instalar dependencias parece obvio, pero vi workflows en el trabajo<\/a> donde el orden estaba mal y la cach\u00e9 nunca se usaba porque ya hab\u00edan instalado todo antes de intentar restaurarla. Cosas peque\u00f1as que cuestan minutos reales, multiplicados por todos los PRs del mes.<\/p>\n
Una cosa m\u00e1s: revisa tus tiempos de CI regularmente. Yo tengo un recordatorio mensual para ver el tab de Actions en GitHub y revisar cu\u00e1nto tiempo est\u00e1n tomando los workflows. Si algo que tardaba 2 minutos ahora tarda 8, algo cambi\u00f3 \u2014 ya sea tus dependencias, tu suite de pruebas, o el runner. Detectarlo tarde significa que ya pagaste horas de minutos de CI sin darte cuenta.<\/p>\n
Si est\u00e1s empezando, copia el primer workflow que puse arriba, ajusta las variables de entorno a tu proyecto, y ponlo a funcionar. No lo optimices hasta que<\/a> tengas datos reales sobre d\u00f3nde se va el tiempo. Premature optimization aplica igual aqu\u00ed que en el<\/a> c\u00f3digo.<\/p>\n
Y si haces un deploy<\/a> un viernes<\/a> a las<\/a> 4pm, al menos que sea con CI verde.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Era un viernes a las 4pm cuando empuj\u00e9 un cambio que parec\u00eda inofensivo a main. Sin CI configurado correctamente, el deploy sali\u00f3 sin correr las pruebas.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-171","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/171","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/comments?post=171"}],"version-history":[{"count":18,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/171\/revisions"}],"predecessor-version":[{"id":621,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/171\/revisions\/621"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/media?parent=171"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/categories?post=171"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/tags?post=171"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}