GitLab CI resource_group : empêcher deux déploiements concurrents

Quand deux pipelines déploient sur le même environnement en parallèle, le deuxième écrase le premier. Résultat : état incohérent, erreurs de connexion, rollback en catastrophe.

resource_group règle ça proprement. Tu assignes un nom de groupe à un job de déploiement. GitLab garantit qu’un seul job par groupe s’exécute à la fois. Les autres attendent.

deploy_staging:
  stage: deploy
  script: ./deploy.sh staging
  environment:
    name: staging
  resource_group: staging

Si deux pipelines arrivent en même temps sur deploy_staging, le premier s’exécute, le deuxième attend que le premier finisse. Pas de lock manuel, pas de vérification Slack “qui déploie ?”.

Avec environment: action: stop

deploy_review:
  stage: deploy
  script: ./deploy-review.sh
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    on_stop: stop_review
  resource_group: review

stop_review:
  stage: deploy
  script: ./destroy-review.sh
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  when: manual

Le resource_group garantit que deploy_review et stop_review ne tournent jamais en parallèle sur la même review app.

Le piège

resource_group est défini au niveau du job, pas de l’environnement. Si deux jobs déploient sur le même environment: staging mais ont des resource_group différents, ils s’exécutent en parallèle. Le nom du groupe doit correspondre à l’environnement que tu protèges.