Dividir el trabajo en etapas y tareas

En una cocina, poner una caja sobre la mesa no significa que la comida esté lista. El encargado del reparto debería esperar una señal concreta antes de cerrarla. Esa relación entre tareas es más importante que el dibujo de flechas que las une.

En GitHub Actions, un trabajo —job— reúne pasos de ejecución. Los pasos de un trabajo comparten su entorno; trabajos distintos pueden ejecutarse en otros entornos. No debemos suponer que un archivo creado en uno aparece automáticamente en el siguiente.

Expresa una dependencia que realmente exista

El caso del pedido separa comprobar de preparar. Este fragmento esquemático muestra la dependencia; los comentarios describen los pasos que faltaría desarrollar en un flujo ejecutable:

jobs:
  comprobar:
    runs-on: ubuntu-latest
    steps:
      # Obtener código, preparar Python y ejecutar pruebas.

  preparar:
    needs: comprobar
    if: github.event_name != 'pull_request' && github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      # Obtener código y generar una entrega.

needs declara que preparar depende de comprobar. Con el comportamiento normal del ejemplo, si comprobar falla, preparar no avanza. La condición adicional limita cuándo tiene sentido producir el paquete.

En ambos trabajos se obtiene el código y se configura Python. No es un paso repetido por descuido: cada uno puede recibir un entorno nuevo. Si debieran compartir un resultado construido, necesitarían un mecanismo explícito, como un artefacto. Una caché de dependencias cumple otro propósito; no debería utilizarse como identidad de la versión que vas a entregar.

Divide para entender, no para multiplicar cajas

Un trabajo único puede ser suficiente para un proyecto pequeño. Separar tiene sentido cuando mejora responsabilidades, dependencias o aislamiento. Más trabajos también añaden coordinación y tiempo de preparación.

La ejecución paralela ayuda cuando las tareas son independientes. Si el paquete depende de una prueba, dibujarlos en paralelo puede producir una entrega antes de conocer su resultado. A veces el flujo más rápido es el que detecta pronto un error y deja de gastar trabajo en lo que ya no debe avanzar.