🚀 GitLab CI/CD – Pipelines, Runners & Déploiement

Comment tester un projet Django qui a besoin d'une BDD (ex: PostgreSQL) ? On utilise la directive services.

default:
  image: python:3.11-slim

stages:
  - test

# Job de test
test_django_app:
  stage: test
  
  # 1. 'services' (lance un 2ème conteneur 'postgres'
  #    et le lie au conteneur principal)
  services:
    - name: postgres:15-alpine
      alias: postgres-db
      
  # 2. Variables (pour configurer Django/Postgres)
  variables:
    # (Remplace le .env pour les tests)
    POSTGRES_DB: test_db
    POSTGRES_USER: test_user
    POSTGRES_PASSWORD: "test_password"
    # (Dit à Django où trouver la BDD)
    DATABASE_URL: "postgres://test_user:test_password@postgres-db:5432/test_db"
  
  before_script:
    - apt-get update && apt-get install -y postgresql-client
    - pip install -r requirements.txt
    
  script:
    # (Attendre que le service Postgres soit prêt)
    - PGPASSWORD=$POSTGRES_PASSWORD psql -h postgres-db -U $POSTGRES_USER -d $POSTGRES_DB -c "SELECT 1"
    
    # (Lancer les tests)
    - python manage.py migrate
    - python manage.py test

GitLab injecte des centaines de variables d'environnement dans chaque job. Voici les plus utiles.

C'est une confusion très fréquente chez les débutants.

Exemple

# (Mise en cache de 'node_modules' si 'package-lock.json' n'a pas changé)
cache:
  key:
    files:
      - package-lock.json
  paths:
    - node_modules/

build_job:
  stage: build
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - dist/ # (Le résultat du build)
    expire_in: 1 day # (Garde l'artifact 1 jour)

deploy_job:
  stage: deploy
  script:
    - echo "Déploiement du dossier 'dist/'..."
    - ls dist/
  dependencies:
    - build_job # (Télécharge automatiquement l'artifact 'dist/' de 'build_job')

La directive environment: (environnement) permet à GitLab de "suivre" vos déploiements (Operations -> Environments).

deploy_staging:
  stage: deploy
  script:
    - echo "Déploiement Staging..."
    # (script de déploiement)
  rules:
    - if: '$CI_COMMIT_BRANCH == "dev"'
  
  environment:
    name: staging
    url: https://staging.ideolab.com
    
deploy_prod:
  stage: deploy
  script:
    - echo "Déploiement PRODUCTION..."
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
    
  environment:
    name: production
    url: https://ideolab.com

Il est dangereux de déployer en production automatiquement à chaque 'push' sur 'main'. On utilise when: manual pour forcer une action manuelle.

deploy_prod:
  stage: deploy
  script:
    - echo "Déploiement PRODUCTION (SSH, rsync...)"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      # 1. Le job ne s'exécute pas auto
      when: manual
      # 2. (Optionnel) Si 'manual', le pipeline
      #    est considéré comme "bloqué".
      #    'false' le met en "succès" (jaune).
      allow_failure: false
      
  environment:
    name: production
    url: https://ideolab.com

Dans l'UI GitLab, un bouton (▶) apparaîtra. Le déploiement ne démarre que si un humain clique dessus.

Pour *construire* une image Docker (docker build) dans un job, le Runner a besoin d'un accès Docker. On utilise "Docker-in-Docker" (DinD).

# Job pour builder et pusher une image
build_docker_image:
  stage: build
  
  # 1. Utiliser l'image 'docker' (client)
  image: docker:24.0
  
  # 2. Lancer le 'daemon' docker (dind)
  #    en tant que service lié.
  services:
    - docker:24.0-dind
    
  # 3. (Requis) Dire au client de ne pas utiliser TLS
  variables:
    DOCKER_TLS_CERTDIR: ""
    DOCKER_HOST: tcp://docker:2375

  before_script:
    # 4. Login au registre GitLab
    - echo $CI_REGISTRY_PASSWORD | docker login -u $CI_REGISTRY_USER $CI_REGISTRY --password-stdin
    
  script:
    # 5. Build & Push
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

stages:
  - test
  - deploy_staging
  - deploy_prod

# Job de Test (cf 2.3)
test_django:
  image: python:3.11
  stage: test
  services:
    - postgres:15
  variables:
    POSTGRES_DB: test_db
    POSTGRES_USER: test_user
    POSTGRES_PASSWORD: "test_password"
    DATABASE_URL: "postgres://test_user:test_password@postgres:5432/test_db"
  script:
    - pip install -r requirements.txt
    - python manage.py migrate
    - python manage.py test

# Job de Déploiement (Staging)
deploy_staging:
  image: alpine:latest
  stage: deploy_staging
  
  before_script:
    # (Installer SSH & Clé privée)
    - apk add --no-cache openssh-client rsync
    - eval $(ssh-agent -s)
    - echo "$STAGING_SSH_KEY" | tr -d '\r' | ssh-add -
    - mkdir -p ~/.ssh
    - chmod 700 ~/.ssh
    - ssh-keyscan -H $STAGING_SERVER_IP >> ~/.ssh/known_hosts
    
  script:
    - echo "Déploiement Staging..."
    # (Ex: rsync -avz . ideo_user@$STAGING_SERVER_IP:/opt/ideo_project/)
    # (Ex: ssh ideo_user@$STAGING_SERVER_IP "cd /opt/ideo_project && ./deploy.sh")
    
  environment:
    name: staging
    url: http://staging.ideolab.com
  rules:
    - if: '$CI_COMMIT_BRANCH == "dev"'
    
# Job de Déploiement (Production)
deploy_prod:
  # (Copie de 'deploy_staging', mais avec $PROD_SSH_KEY)
  stage: deploy_prod
  script:
    - echo "Déploiement PRODUCTION..."
  environment:
    name: production
    url: http://ideolab.com
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: manual # (Protection)

GitLab CI peut héberger des sites statiques (HTML/CSS/JS) gratuitement, si le job s'appelle pages et que l'artifact est un dossier public/.

# (Exemple: Déployer un site React/Vite)

# 1. Nom de job spécial
pages:
  stage: deploy
  image: node:18-alpine
  
  script:
    - npm install
    - npm run build # (Crée le dossier 'dist')
    # 2. Renommer 'dist' en 'public'
    - mv dist public
    
  # 3. L'artifact DOIT être 'public'
  artifacts:
    paths:
      - public
      
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

Le site sera disponible sur https://[username].gitlab.io/[projectname].