Déploiement d’une application Symfony avec la CI de GitLab

Frédéric Allain — Fondateur de CTO Externe
20 ans d’expertise en infrastructure, sécurité IT et pilotage de projets numériques · Basé à Damigny (61)
Voir le profil complet

Mis à jour le 26 mai 2026. Cette révision intègre les évolutions Symfony 7.4 LTS, PHP 8.3/8.4, GitLab 18.x, le passage à rules: (l’ancien only: étant déprécié), une nouvelle section sur la sécurité des tokens GitLab CI et une section sur l’optimisation du cache. Le rapport des outils a aussi été actualisé (Composer audit natif, PHP-CS-Fixer, Rector).

L’intégration continue (CI) est devenue une pratique essentielle dans le développement d’application moderne. Avec Symfony comme framework backend et GitLab comme plateforme d’intégration et déploiement continue, vous pouvez automatiser les tests, analyser la qualité du code, et déployer votre application en toute sécurité. Ce guide vous propose un tour d’horizon des bonnes pratiques, des outils de tests, des pièges à éviter, et une configuration type pour un fichier .gitlab-ci.yml.

Bonnes pratiques pour la CI avec GitLab et Symfony

1.1. Structurer votre pipeline CI

Un pipeline CI bien structuré se compose de plusieurs étapes :

1. Build : Installer les dépendances (composer, npm).
2. Tests : Exécuter les tests unitaires, d’intégration, et fonctionnels.
3. Analyse de code : Vérifier la qualité du code et les failles potentielles, audit de code Symfony.
4. Déploiement : Automatiser le déploiement sur l’environnement de production ou de staging.

1.2. Utiliser des caches

Pour optimiser les temps d’exécution, configurez un cache pour les dépendances :

• Composer pour PHP.
• Node_modules si des assets sont gérés.
  Cela évite de re-télécharger les mêmes dépendances à chaque exécution.

1.3. Isoler les environnements

Utilisez des conteneurs ou des environnements Docker pour garantir que l’application fonctionne dans un environnement contrôlé, identique à celui de la production.

Tests et outils à intégrer dans la CI

2.1. Tests unitaires avec PHPUnit

• Installez et configurez PHPUnit pour vérifier que chaque composant de votre application fonctionne comme prévu.
• Exécutez les tests dans une étape dédiée du pipeline pour isoler les erreurs.

2.2. Analyse de qualité du code avec PHPStan

• PHPStan analyse votre code pour détecter les erreurs potentielles, comme les types incompatibles ou les méthodes inexistantes.
• Configurez-le avec un niveau de rigueur (ex. : --level=max) pour renforcer la qualité.

2.3. Vérification des standards avec PHPCS

• PHPCS (PHP CodeSniffer) s’assure que le code respecte les standards de codage définis (PSR-12, par exemple).
• Ajoutez-le pour vérifier chaque modification avant l’intégration au code principal.

2.4. Analyse de sécurité avec Composer audit et Snyk

Plusieurs outils permettent de couvrir la sécurité applicative en CI :

• Composer audit (natif depuis Composer 2.4) : exécution dans le pipeline pour détecter les vulnérabilités connues (CVE) dans les dépendances. Sortie en échec si une faille critique est détectée.
• Snyk ou GitHub Dependabot pour le suivi continu hors pipeline et les correctifs automatisés.
• SAST GitLab (Static Application Security Testing) : intégré nativement dans GitLab Ultimate, détecte les patterns d’injection, XSS, désérialisation non sécurisée.
• DAST GitLab (Dynamic Application Security Testing) : tests sur une instance déployée pour valider la sécurité runtime.

SonarQube reste pertinent pour la qualité globale du code mais ne couvre pas pleinement la sécurité des dépendances PHP.

Modernisation automatique avec Rector

Rector permet d’appliquer des règles de refactoring automatique : migration de versions Symfony (5.4 vers 6.4, 6.4 vers 7.x), passage à PHP 8.3/8.4, modernisation des types, suppression de code déprécié. Intégré dans la CI en mode --dry-run puis en correction automatique sur les branches de migration, il accélère la maintenance évolutive d’une application Symfony existante.

2.5. Autres outils recommandés

• Infection PHP : Pour tester la robustesse des tests (mutation testing).
• Symfony Panther : Pour tester les interfaces web.
• PHP-CS-Fixer : alternative moderne et plus performante à PHPCS pour le respect des conventions (PSR-12, Symfony, custom rules).

Pièges à éviter

3.1. Ignorer les étapes de tests

Il peut être tentant de sauter les tests pour accélérer le déploiement. Résultat : des bugs en production. Priorisez toujours les tests.

3.2. Mauvaise gestion des secrets

N’intégrez jamais les clés API ou mots de passe directement dans le code ou le fichier CI. Utilisez les variables sécurisées de GitLab pour gérer ces informations.

3.3. Déploiement sans validation

Ne déployez pas automatiquement sur l’environnement de production sans une validation manuelle ou un environnement de staging.

3.4. Pipelines non optimisés

Des pipelines longs ou mal optimisés peuvent ralentir les développements. Configurez les caches et limitez les étapes redondantes pour réduire les délais.

Sécurité des tokens et secrets GitLab CI

La gestion des secrets dans une CI Symfony reste l’une des sources de fuites les plus courantes. Les bonnes pratiques en 2026 :

Utiliser les variables masquées et protégées

Dans Settings → CI/CD → Variables, configurer pour chaque secret :

• Masked : la valeur est masquée dans les logs de pipeline (obligatoire pour tout secret).
• Protected : la variable n’est disponible que sur les branches/tags protégés (typiquement main et v*.*.*). À activer pour tout secret de production.
• File-based : pour les fichiers de configuration (clés privées SSH, certificats), préférer le type « File » à « Variable » pour éviter d’avoir à reconstruire le fichier dans le job.

Limiter la portée des Project Access Tokens

Préférer un Project Access Token avec scope minimal (read_repository, write_registry) à un Personal Access Token avec scope global. Renouveler les tokens tous les 90 jours.

Bannir les secrets dans le code

git push ne doit jamais contenir de .env.local ni de clés privées. Activer le scanner de secrets GitLab (gratuit dans toutes les éditions depuis 2024) qui bloque les push contenant des patterns sensibles.

Auditer régulièrement les permissions

Les tokens GitLab CI ont une portée par défaut très large. Auditer trimestriellement qui a accès à quoi via Settings → Members → Access expirations et CI/CD → Job tokens permissions.

Optimisation du cache et de la performance

Un pipeline mal optimisé peut tripler le coût en minutes runner. Quelques leviers efficaces :

Cache key par branche

Sans cache:key, toutes les branches partagent le même cache et se polluent. Configuration recommandée :

cache:
key:
files:
- composer.lock
- package-lock.json
paths:
- vendor/
- node_modules/
policy: pull-push

Exemple d’un fichier .gitlab-ci.yml

Voici une configuration adaptée à une application Symfony 7 en 2026, intégrant les bonnes pratiques ci-dessus :

stages:
  - build
  - analyze
  - test
  - deploy

variables:
  COMPOSER_CACHE_DIR: "$CI_PROJECT_DIR/.composer-cache"
  COMPOSER_ALLOW_SUPERUSER: "1"
  PHP_IMAGE: "php:8.3-cli-alpine"

# Cache partagé par branche, basé sur composer.lock + package-lock.json
cache:
  key:
    files:
      - composer.lock
      - package-lock.json
  paths:
    - vendor/
    - node_modules/
    - .composer-cache/

# === BUILD ===
build:
  stage: build
  image: $PHP_IMAGE
  script:
    - apk add --no-cache git unzip
    - curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
    - composer install --prefer-dist --no-progress --no-interaction --optimize-autoloader
  artifacts:
    paths:
      - vendor/
    expire_in: 1 hour
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

# === ANALYZE (jobs parallèles) ===
phpstan:
  stage: analyze
  image: $PHP_IMAGE
  needs: ["build"]
  script:
    - vendor/bin/phpstan analyse src/ --level=8 --no-progress
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

php-cs-fixer:
  stage: analyze
  image: $PHP_IMAGE
  needs: ["build"]
  script:
    - vendor/bin/php-cs-fixer fix --dry-run --diff
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

composer_audit:
  stage: analyze
  image: $PHP_IMAGE
  needs: ["build"]
  script:
    - composer audit --format=summary
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

# === TEST ===
phpunit:
  stage: test
  image: $PHP_IMAGE
  needs: ["build"]
  script:
    - vendor/bin/phpunit --coverage-text --colors=never
  artifacts:
    reports:
      junit: tests/_output/junit.xml
    expire_in: 7 days
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

# === DEPLOY ===
deploy_production:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add --no-cache openssh-client rsync
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -
    - mkdir -p ~/.ssh && chmod 700 ~/.ssh
    - ssh-keyscan -H "$DEPLOY_HOST" >> ~/.ssh/known_hosts
  script:
    - rsync -avz --exclude='.git' --exclude='var/cache' ./ "$DEPLOY_USER@$DEPLOY_HOST:/var/www/symfony-app/"
    - ssh "$DEPLOY_USER@$DEPLOY_HOST" "cd /var/www/symfony-app && composer install --no-dev --optimize-autoloader && php bin/console cache:clear --env=prod"
  environment:
    name: production
    url: https://example.com
  rules:
    - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/
  when: manual

Ce qu’il faut retenir :

La combinaison de Symfony et de la CI de GitLab permet de construire, tester et déployer vos applications de manière fiable et efficace. En intégrant des outils comme PHPUnit, PHPStan, et SonarQube directement dans vos pipelines, vous garantissez une qualité de code et une sécurité optimales. Suivre les bonnes pratiques et éviter les pièges communs vous aidera à maximiser les bénéfices de cette approche.

Adopter ces stratégies avec GitLab vous permettra non seulement de gagner du temps, mais aussi de renforcer la robustesse et la fiabilité de vos applications Symfony.

FAQ : Déployer une application Symfony avec GitLab CI

Pour aller plus loin

Si vous héritez d’une application Symfony et que la qualité du code vous inquiète au-delà du seul pipeline CI, la méthode complète d’audit de code Symfony couvre les 5 dimensions à examiner systématiquement.

Si l’enjeu dépasse la seule application et concerne la continuité de service en cas d’incident, le plan de reprise d’activité PME détaille comment construire un PRA testé et chiffré.