{"id":129,"date":"2026-03-09T02:44:23","date_gmt":"2026-03-09T02:44:23","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/configuracin-de-github-actions-para-aplicacione\/"},"modified":"2026-03-18T22:00:21","modified_gmt":"2026-03-18T22:00:21","slug":"configuracin-de-github-actions-para-aplicacione","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/configuracin-de-github-actions-para-aplicacione\/","title":{"rendered":"Configuraci\u00f3n de GitHub Actions para Aplicaciones Python: Gu\u00eda Completa"},"content":{"rendered":"

Llevaba tres semanas con el mismo problema: cada vez que alguien del equipo hac\u00eda merge de una PR, algo se romp\u00eda en producci\u00f3n<\/a>. No siempre. Solo… a veces. Y cuando no tienes CI, “a veces” es suficiente para arruinarte un viernes<\/a> por la tarde.<\/p>\n

Fue entonces cuando decid\u00ed sentarme seriamente con GitHub Actions<\/a>. Ya lo hab\u00eda usado superficialmente \u2014 ese t\u00edpico workflow copiado de Stack Overflow que “funciona pero no s\u00e9 muy bien por qu\u00e9<\/a>” \u2014 pero esta vez quer\u00eda entenderlo de verdad<\/a>. Esto es lo<\/a> aprend\u00ed despu\u00e9s de dos<\/a> semanas”>que aprend\u00ed despu\u00e9s de<\/a> dos semanas<\/a> configur\u00e1ndolo para una aplicaci\u00f3n FastAPI mediana (unos 40 endpoints, PostgreSQL, Redis, el stack habitual).<\/p>\n

La estructura que realmente<\/a> funciona para proyectos<\/a> Python<\/h2>\n

Lo primero que me cost\u00f3 entender es que un workflow de GitHub Actions<\/a> no es un script de bash disfrazado. Tiene su propia l\u00f3gica, y si intentas usarlo como si fuera uno, acabas con algo que funciona pero que nadie<\/a> puede mantener seis meses despu\u00e9s.<\/p>\n

La estructura que uso ahora como punto de partida para casi todos mis proyectos Python:<\/p>\n

name: CI\/CD Pipeline\n\non:\n  push:\n    branches: [main, develop]\n  pull_request:\n    branches: [main]\n\njobs:\n  test:\n    runs-on: ubuntu-22.04\n    strategy:\n      matrix:\n        python-version: ["3.11", "3.12"]\n\n    services:\n      postgres:\n        image: postgres:16\n        env:\n          POSTGRES_PASSWORD: testpassword\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      redis:\n        image: redis:7\n        options: >-\n          --health-cmd "redis-cli ping"\n          --health-interval 10s\n          --health-timeout 5s\n          --health-retries 5\n        ports:\n          - 6379:6379\n\n    steps:\n      - name: Checkout c\u00f3digo\n        uses: actions\/checkout@v4\n\n      - name: Configurar Python ${{ matrix.python-version }}\n        uses: actions\/setup-python@v5\n        with:\n          python-version: ${{ matrix.python-version }}\n          cache: "pip"  # esto s\u00ed que ahorra tiempo \u2014 ~40% menos en mis builds\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: Ejecutar linters\n        run: |\n          ruff check .\n          mypy src\/ --ignore-missing-imports\n\n      - name: Ejecutar tests\n        env:\n          DATABASE_URL: postgresql:\/\/postgres:testpassword@localhost:5432\/testdb\n          REDIS_URL: redis:\/\/localhost:6379\n          SECRET_KEY: testing-secret-key-not-real\n        run: |\n          pytest tests\/ -v --cov=src --cov-report=xml\n\n      - name: Subir reporte de cobertura\n        uses: codecov\/codecov-action@v4\n        with:\n          file: .\/coverage.xml\n          fail_ci_if_error: false  # no quiero que codecov rompa mi pipeline\n<\/code><\/pre>\n
Hay algunas decisiones aqu\u00ed que tom\u00e9 conscientemente. El ubuntu-22.04<\/code> en lugar de ubuntu-latest<\/code> importa m\u00e1s de lo que<\/a> parece. Aprend\u00ed por las malas<\/a> que ubuntu-latest<\/code> puede cambiar de un d\u00eda para otro y romper tu pipeline por razones completamente ajenas a tu c\u00f3digo. Fijar la versi\u00f3n a\u00f1ade un poco de deuda de mantenimiento, pero al menos sabes por qu\u00e9<\/em> falla cuando falla \u2014 y eso vale mucho a las<\/a> 10pm con una incidencia abierta.<\/p>\n
El cach\u00e9 de pip (cache: \"pip\"<\/code> en setup-python@v5) redujo mis tiempos de CI en torno al 40%. Peque\u00f1o detalle, gran diferencia.<\/p>\n
Testing con servicios externos: el dolor real<\/h2>\n
Aqu\u00ed es donde la mayor\u00eda de los tutoriales se quedan cortos. Todo el mundo muestra c\u00f3mo hacer pytest<\/code> con tests unitarios puros. \u00bfPero y cuando tu aplicaci\u00f3n necesita Postgres y Redis de verdad<\/a>?<\/p>\n
El bloque services<\/code> de GitHub Actions<\/a> es tu amigo \u2014 aunque tiene sus peculiaridades. La m\u00e1s importante: los servicios arrancan antes<\/em> que tu c\u00f3digo, pero no hay garant\u00eda de que est\u00e9n listos<\/em> cuando llegues al step de tests. Por eso el bloque options<\/code> con --health-cmd<\/code> es fundamental, no opcional. Sin eso, me encontr\u00e9 con errores de conexi\u00f3n intermitentes que tard\u00e9 media tarde en diagnosticar porque estaba convencido de que el problema estaba en mis fixtures de pytest. No lo estaba.<\/p>\n
Y aqu\u00ed viene el error concreto que me hizo perder 45 minutos: si usas Redis en tus tests pero no lo declaras como service<\/code> expl\u00edcitamente, GitHub Actions<\/a> no lo levanta. S\u00ed, obvio en retrospectiva. Pero llegu\u00e9 a esto despu\u00e9s de<\/a> media tarde mirando logs y pregunt\u00e1ndome por qu\u00e9<\/a> aparec\u00eda redis.exceptions.ConnectionError<\/code> si “todo estaba instalado”.<\/p>\n
Una optimizaci\u00f3n que descubr\u00ed<\/a> m\u00e1s tarde: fail-fast: false<\/code> en la strategy matrix. Por defecto, si una versi\u00f3n de Python falla, GitHub cancela todos los dem\u00e1s jobs de la matrix. A veces eso es lo que<\/a> quieres. Pero si est\u00e1s debuggeando compatibilidad entre versiones, quieres ver todos los resultados a la vez. A\u00f1adir fail-fast: false<\/code> bajo strategy<\/code> te da exactamente eso \u2014 y honestamente deber\u00eda ser el default en casi todos los casos.<\/p>\n
Secretos, variables de entorno y el error que casi me cuesta caro<\/h2>\n
Ser\u00e9 directo aqu\u00ed porque es donde m\u00e1s gente la l\u00eda (yo incluido): nunca pongas valores sensibles directamente en el<\/a> YAML del workflow. Suena obvio, pero cuando est\u00e1s debuggeando a las<\/a> 11pm y necesitas que algo funcione ya<\/em>, es tentador hacer API_KEY: \"sk-real-key-here\"<\/code> y ya lo arreglo ma\u00f1ana. Ma\u00f1ana nunca llega. Y si ese YAML llega a un repo p\u00fablico aunque sea por dos minutos, esa key est\u00e1 comprometida.<\/p>\n
GitHub Actions tiene dos mecanismos para esto: Secrets<\/strong> y Variables<\/strong>. La distinci\u00f3n importa:<\/p>\n