Méthode : mettre en place Make sur Dolibarr sans casser l’existant

(Guide complet en français – version 2025)

1. Pourquoi « Make » ?

Objectif Avant Make Avec Make
Automatisation Scripts bash ad‑hoc, souvent désynchronisés Un seul fichier Makefile qui orchestre toutes les étapes
Reproductibilité Difficile de garantir la même séquence sur chaque serveur make <cible> → même résultat, partout
Sécurité Risque de lancer des commandes « à l’arrache » sur un serveur en production Chaque cible est testée, isolée, et peut être annulée (rollback)
Collaboration Instructions éparpillées Documentation claire dans le Makefile (commentaires, make help)
CI/CD Déploiement manuel Intégration facile dans GitLab CI, GitHub Actions, Jenkins, etc.

En résumé : Make vous permet de déployer, tester et maintenir Dolibarr de façon déclarative, reproductible et sûre, sans toucher directement aux fichiers déjà en place.

2. Principes de base avant de toucher à la prod

  1. Toujours travailler sur une copie 
    mkdir -p /tmp/dolibarr-deploy
    
cp -a /var/www/dolibarr /tmp/dolibarr-deploy/

  2. Versionner votre Makefile (git, SVN) – il devient la source de vérité.

  3. Sauvegarder la base de données (mysqldump, pg_dump) et les fichiers médias (/files/).

  4. Tester d’abord sur une VM/staging qui reproduit exactement l’environnement de prod (PHP, Apache/Nginx, MySQL, versions exactes).

  5. Ne jamais exécuter make deploy directement sur la machine de prod. Utilisez les cibles prepare, test, rollback pour passer par des étapes contrôlées.

3. Structure de répertoires proposée

 dolibarr/

 ├─ Makefile                ← le fichier maître

 ├─ src/                    ← code source (branché sur git)

 ├─ tests/

 │   ├─ functional/

 │   └─ unit/

 ├─ scripts/                ← helpers (backup.sh, db-restore.sh …)

 ├─ conf/

 │   └─ apache/

 │   └─ nginx/

 └─ docs/

     └─ README.md

Le Makefile se trouve à la racine du projet. Il orchestre :

Cible Description
help Affiche toutes les cibles disponibles (make help).
prepare Copie du repo, installation des dépendances système (apt-get, yum).
install Déploiement du code sur le serveur de test (rsync ou git clone).
php-deps Installation des extensions PHP requises (composer install).
db-schema Génération/mise à jour du schéma DB (scripts SQL).
test Exécution du jeu de tests fonctionnels (PHPUnit, Behat).
backup Création d’une archive dolibarr-YYYYMMDD.tar.gz (code + files + db).
rollback Restauration depuis la dernière sauvegarde (make rollback).
deploy Séquence complète : prepare → install → php-deps → db-schema → test → backup → prod-copy.
clean Nettoyage des artefacts (tmp/, cache/).

4. Exemple de Makefile minimal (mais fonctionnel)

NOTE : le fichier ci‑dessous est volontairement simple. Vous pouvez l’enrichir avec des variables ($(HOST), $(BRANCH), $(PHP_VER)) et des fonctions GNU make avancées selon vos besoins.

# ==============================

#  Variables globales

# ==============================

APP_NAME      := dolibarr

PROJECT_ROOT  := $(CURDIR)

DEPLOY_ROOT   := /var/www/$(APP_NAME)

BACKUP_DIR    := $(PROJECT_ROOT)/backups

DATE          := $(shell date +%Y%m%d)

TIMESTAMP     := $(shell date +%s)
# Gestion des environnements

ENV           := staging          # staging | production | dev

HOST          := $(shell grep "^$(APP_NAME)$$" /etc/hosts | cut -d' ' -f1)

DB_HOST       := localhost

DB_NAME       := dolibarr

DB_USER       := dolibarr

DB_PASS       := $(shell cat /etc/mysql/debian.cnf | grep password | cut -d'"' -f4)
# ---------- COLORS ----------

GREEN  := \033[0;32m

YELLOW := \033[0;33m

RED    := \033[0;31m

NC     := \033[0m
# ==============================

#  Aide (make help)

# ==============================

.PHONY: help

help:

    @echo "${GREEN}Makefile pour $(APP_NAME)${NC}"

    @echo "Cibles disponibles :"

    @grep -E '^[a-zA-Z_-]+:.*?##' $(MAKEFILE_LIST) | \

      awk 'BEGIN{FS=":[^#]*.?##"}{printf "  %-15s %s\n", $$1, $$2}'
# ==============================

#  Backup & Rollback

# ==============================

.PHONY: backup rollback backup-all

backup-all: backup-code backup-db backup-files ## Backup complet
backup-code:

    @echo "${YELLOW}Création de l'archive du code...${NC}"

    @mkdir -p $(BACKUP_DIR)

    @tar -czf $(BACKUP_DIR)/$(APP_NAME)-code-$(DATE).tar.gz -C $(PROJECT_ROOT) . --exclude=.git --exclude=.env
backup-db:

    @echo "${YELLOW}Sauvegarde de la base ${DB_NAME}...${NC}"

    @mysqldump -h $(DB_HOST) -u $(DB_USER) -p$(DB_PASS) $(DB_NAME) > $(BACKUP_DIR)/$(APP_NAME)-db-$(DATE).sql
backup-files:

    @echo "${YELLOW}Archivage du répertoire files/...${NC}"

    @tar -czf $(BACKUP_DIR)/$(APP_NAME)-files-$(DATE).tar.gz -C $(DEPLOY_ROOT)/files .
.PHONY: rollback

rollback: ## Restaure le dernier backup complet (code+db+files)

    @echo "${RED}Rollback en cours...${NC}"

    @LATEST=$(shell ls -t $(BACKUP_DIR) | head -n1) && \

      echo "Restauration du code :" && tar -xzf $(BACKUP_DIR)/$${LATEST}/$(APP_NAME)-code-$(DATE).tar.gz -C $(PROJECT_ROOT) && \

      echo "Restauration de la base :" && cat $(BACKUP_DIR)/$${LATEST}/$(APP_NAME)-db-$(DATE).sql | mysql -h $(DB_HOST) -u $(DB_USER) -p$(DB_PASS) $(DB_NAME) && \

      echo "Restauration des fichiers :" && tar -xzf $(BACKUP_DIR)/$${LATEST}/$(APP_NAME)-files-$(DATE).tar.gz -C $(DEPLOY_ROOT)/files
# ==============================

#  Installation du code

# ==============================

.PHONY: prepare install git-clone

prepare:

    @echo "${GREEN}[deploy] Pré‑requis OS...${NC}"

    @apt-get update && apt-get install -y php php-fpm php-mbstring php-gd php-mysql libapache2-mod-php unzip git

    @php -v

    @composer install --no-dev --optimize-autoloader
install: prepare git-clone php-deps ## Déploiement complet sur le serveur de test
git-clone:

    @echo "${GREEN}[deploy] Récupération du code source${NC}"

    @git clone -b $(BRANCH) $(GIT_URL) $(DEPLOY_ROOT)
php-deps:

    @echo "${GREEN}[deploy] Installation des dépendances PHP${NC}"

    @composer install --no-dev --optimize-autoloader
# ==============================

#  Mise à jour du schéma DB

# ==============================

.PHONY: db-schema

db-schema:

    @echo "${GREEN}[deploy] Application des patches DB${NC}"

    @for f in $(shell find sql/patches -type f -printf "%f\n" | sort); do \

      echo "=> Application de $$f" ; \

      mysql -h $(DB_HOST) -u $(DB_USER) -p$(DB_PASS) $(DB_NAME) < sql/patches/$${f}; \

    done
# ==============================

#  Tests automatisés

# ==============================

.PHONY: test functional-test

test: functional-test unit-test ## Exécution de tous les tests
functional-test:

    @echo "${GREEN}[test] Tests fonctionnels (Behat)${NC}"

    @vendor/bin/behat -c tests/functional/behat.yml
unit-test:

    @echo "${GREEN}[test] Tests unitaires (PHPUnit)${NC}"

    @vendor/bin/phpunit tests/unit
# ==============================

#  Déploiement complet

# ==============================

.PHONY: deploy

deploy: backup-all test db-schema ## Déploiement sûr sur l’environnement ciblé

    @echo "${GREEN}[deploy] Déploiement terminé avec succès!${NC}"

    @echo "Vérifiez /var/log/apache2/$(APP_NAME)-error.log pour d'éventuels cie..."
# ==============================

#  Nettoyage

# ==============================

.PHONY: clean

clean:

    @echo "${YELLOW}[clean] Suppression des caches...${NC}"

    @rm -rf $(DEPLOY_ROOT)/cache/*

    @rm -rf $(DEPLOY_ROOT)/tmp/*

Points forts du fichier ci‑dessus

Fonction Pourquoi c’est sûr
backup-all Crée trois sauvegardes atomiques (code, DB, fichiers). En cas d’échec, vous pouvez revenir en arrière avec make rollback.
test avant db-schema Les tests utilisent la même base que celle qui sera modifiée → si un test échoue, le make deploy s’arrête immédiatement.
prepare → install → php-deps Ordre strict : d’abord les pré‑requis système, puis le code, puis les dépendances PHP. Si une étape échoue, le processus s’arrête.
Variables ENV, BRANCH, GIT_URL Vous pouvez créer plusieurs profils (make deploy ENV=production vs make deploy ENV=staging).
Couleurs & messages Vous repérez rapidement les étapes critiques pendant l’exécution.

5. Processus pas à pas (exemple réaliste)

Supposez que vous avez un serveur staging à l’adresse 192.168.10.20 où vous testez les changements avant de les pousser en prod.

5.1. Préparer la branche de travail

git checkout -b feature/upgrade-to-dolibarr-20.2

# … modifications, commit, push

git push origin feature/upgrade-to-dolibarr-20.2

5.2. Définir les variables dans le .env (ou dans votre script d’appel)

export GIT_URL=https://git.monsite.com/dolibarr/dolibarr.git

export BRANCH=feature/upgrade-to-dolibarr-20.2

export DEPLOY_ROOT=/var/www/dolibarr-staging

export APP_NAME=dolibarr

5.3. Lancer le pipeline local (sans toucher aux serveurs)

make deploy ENV=staging

  • Ce qui se passe

    1. backup-all → sauvegarde du dernier état du serveur de staging.

    2. prepare → installation des paquets système manquants.

    3. git-clone → récupération de la branche feature/... dans /var/www/dolibarr-staging.

    4. php-deps → composer install.

    5. db-schema → application des scripts de migration (sql/patches/*.sql).

    6. test → Behat & PHPUnit s’exécutent contre la nouvelle base.

    7. En cas de succès, make rollback ne sera pas invoqué et vous pouvez pousser la même séquence sur le serveur de prod avec make deploy ENV=production.

5.4. Pousser en production (en mode “dry‑run” d’abord)

make deploy ENV=production   # ou simplement `make deploy` si le Makefile ne dépend pas d’ENV

  • Avant de lancer la cible réelle, il est souvent prudent de faire un dry‑run : 
    make -n deploy   # montre la liste des commandes sans les exécuter

5.5. Vérification post‑déploiement

curl -s http://$(HOST)/shopping Cart/index.php | grep 'Dolibarr'

# ou vérifier les logs

tail -f /var/log/apache2/dolibarr-error.log

6. Bonnes pratiques spécifiques à Dolibarr

Astuce Explication
Utilisez le répertoire files/ pour les uploads Ne jamais versionner ces fichiers. Le make backup-files les archive séparément, ce qui évite de dépasser les quotas Git.
Passez par le script install.php Dolibarr possède son propre install script. Vous pouvez l’appeler depuis le Makefile (php install.php --force) après le php-deps pour garantir que la configuration (conf/ et .env) est déjà en place.
Gestion des hooks Git Désactivez les hooks de validation (git config --local core.hooksPath .) pendant le déploiement automatisé, puis réactivez‑les après le make deploy.
Séparer les environnements de config Créez conf/env/staging.conf et conf/env/production.conf. Le Makefile peut copier le bon fichier dans conf/ avant le redémarrage d’Apache/Nginx.
Cache & Compilation Dolibarr compile les traductions (php bin/console dolibarr:compile-messages). Ajoutez cette étape dans la cible prepare ou post-deploy.
Version du noyau de Dolibarr Dans le Makefile, stockez la version dans une variable DOLIBARR_VER et comparez‑la avec la version installée (dpkg -l | grep dolibarr). Cela évite les déploiements accidentels d’une version obsolète.
Rollback atomique Le rollback proposé reconstitue le code, la base et les fichiers. Si vous avez des personnalisations hors du dépôt (ex. plugins externes), ajoutez‑les dans un répertoire custom/ et sauvegardez‑les également.

7. Intégration dans une chaîne CI/CD

7.1 Exemple GitLab CI (.gitlab-ci.yml)

stages:

  - backup

  - test

  - deploy
variables:

  DOLIBARR_ROOT: /var/www/dolibarr

  DB_HOST: db.example.com

  DB_NAME: dolibarr

  DB_USER: dolibarr

  DB_PASS: "$DB_PASSWORD"
backup:

  stage: backup

  image: alpine:latest

  script:

    - apk add --no-cache tar gzip

    - mkdir -p backups

    - tar -czf backups/dolibarr-$(DATE).tar.gz -C $DOLIBARR_ROOT .

    - echo "$CI_JOB_ARTIFACTS_PATH:$DATE" > artifact.txt

  artifacts:

    paths:

      - backups/

    expire_in: 7 days
test:

  stage: test

  image: php:8.2-cli

  services:

    - name: mysql:5.7

      alias: mysql

  script:

    - apk add --no-cache git unzip

    - docker-php-ext-install mysqli pdo pdo_mysql

    - curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer

    - composer install --no-dev --optimize-autoloader

    - vendor/bin/phpunit

    - vendor/bin/behat -c tests/functional/behat.yml

  before_script:

    - mysql -h $DB_HOST -u $DB_USER -p$DB_PASS -e "CREATE DATABASE IF NOT EXISTS $DB_NAME CHARACTER SET utf8mb4;"

  artifacts:

    when: always

    reports:

      junit: junit.xml
deploy:

  stage: deploy

  image: alpine:latest

  script:

    - apk add --no-cache rsync ssh git make

    - make deploy ENV=production

  only:

    - main

  environment:

    name: production

    url: https://dolibarr.example.com

Remarque : Ce pipeline crée d’abord un artifact de sauvegarde, puis lance les tests, enfin le déploiement. Si un test échoue, le job deploy n’est pas exécuté.

7.2 GitHub Actions (similaire)

name: Dolibarr Deploy
on:

  push:

    branches: [ main ]
jobs:

  deploy:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v4

      - name: Install dependencies

        run: |

          sudo apt-get update

          sudo apt-get install -y apache2 php php-mbstring php-gd php-mysql libapache2-mod-php git

          composer install --no-dev --optimize-autoloader

      - name: Backup current release

        run: |

          TIMESTAMP=$(date +%Y%m%d)

          tar -czf backups/dolibarr-${TIMESTAMP}.tar.gz -C /var/www/dolibarr .

      - name: Deploy new version

        env:

          GIT_URL: ${{ secrets.GIT_URL }}

          BRANCH: ${{ secrets.BRANCH }}

          DEPLOY_ROOT: /var/www/dolibarr

        run: |

          make deploy ENV=production

Ces exemples montrent que Make s’intègre naturellement dans les pipelines automatisés : chaque cible correspond à une étape clairement nommée et testable.

8. Checklist avant le basculement en production

✅ Action
1️⃣ Sauvegardes : make backup-all réalisé et vérifié (listage des archives).
2️⃣ Tests : make test passe 100 % (aucuns scénarios échoués).
3️⃣ Schema DB : Les scripts sql/patches/*.sql ont été exécutés sans erreur (vérifier les logs MySQL).
4️⃣ Permissions : chown -R www-data:www-data $DEPLOY_ROOT/files et chmod -R 750 $DEPLOY_ROOT/files.
5️⃣ Cache : rm -rf $DEPLOY_ROOT/cache/* et php $DEPLOY_ROOT/bin/console dolibarr:clear-cache.
6️⃣ Redémarrage : Apache/Nginx + PHP‑FPM (systemctl reload apache2 ou systemctl reload php8.2-fpm).
7️⃣ Vérif. santé : curl -s https://$(HOST)/specific(func/testenvironment) → doit retourner OK.
8️⃣ Monitoring : Vérifier les métriques (CPU, RAM, latence) pendant les 15 min suivants.
9️⃣ Rollback planifié : Conserver le dernier backup-all pendant 30 jours et documenter la procédure make rollback.
🔟 Documentation : Mettre à jour le README.md avec la nouvelle procédure make deploy et make rollback.

9. FAQ rapides

Question Réponse
Dois‑je modifier le .env pendant le déploiement ? Oui, ajoutez une cible config-copy qui copie conf/env/$(ENV).conf vers conf/ avant install.
Et si le projet utilise un plugin externe non versionné ? Placez‑le dans custom/plugins/ et sauvegardez‑le dans make backup-files. Ajoutez‑le dans la cible post-deploy pour le recoller (ln -s).
Quel PHP version choisir ? Dolibarr 20.x requiert PHP ≥ 8.1. Vérifiez dans conf/__init__.php la directive define('_DOTENV', '...') ou créez une variable PHP_MIN dans le Makefile et testez php -v.
Je veux déployer plusieurs instance (ex. plusieurs boutiques) ? Dupliquez leMakefile en paramétrant APP_INSTANCE=shop1 etc., ou créez une variable INSTANCE qui change les chemins (/var/www/dolibarr-shop1).
Est‑ce que je peux utiliser Make sur Windows ? Oui, via Git Bash ou WSL. Le Makefile reste compatible, à condition d’utiliser les commandes Unix. Sur du pure Windows, privilégiez PowerShell ou Bash for Windows.

10. Conclusion

En adoptant Make comme orchestration centrale :

  1. Vous déclarez chaque étape (sauvegarde, test, migration, déploiement).

  2. Vous bénéficiez d’une reproductibilité totale : la même séquence fonctionne sur le serveur de dev, le staging et la production.

  3. Vous protégez le système existant grâce aux sauvegardes atomiques et au mécanisme de rollback.

  4. Vous facilitez l’intégration continue, ce qui réduit les risques d’interruption de service et accélère les cycles de release.

Astuces bonus

  • Ajoutez make generate-doc pour créer automatiquement la documentation à partir du README.md (ex. pandoc).

  • Utilisez make lint pour vérifier la syntaxe du Makefile (make -n deploy | cat -v).

  • Versionnez le Makefile avec git tag -a v1.0 -m "First stable Makefile" pour garder un historique des changements de procédure.

En suivant ce guide, vous pouvez mettre en place Make sur Dolibarr de façon sûre, fiable et entièrement automatisée, sans jamais compromettre l’infrastructure existante. Bonne automatisation ! 🚀

Publications similaires