DevOps Dolibarr : distribution Guide pratique sans casser l’existant

Version : 1.0 – Mars 2025
Audience : équipes IT, développeurs, chefs de projet, Ops

1. Pourquoi « DevOps » pour Dolibarr ?

Besoin	Apport DevOps
Déploiement fiable	Pipelinage automatisé → zéro surprise en production.
Scalabilité	Conteneurs / VM : on ajoute ou retire des instances en fonction du trafic.
Reproductibilité	Infrastructure as Code (IaC) → chaque environnement (dev, test, prod) se crée de la même façon.
Rollback immédiat	ArtefactsVersionnés + stratégie « blue‑green » ou « canary ».
Visibilité	Monitoring, logs centralisés, tracing des transactions ERP.
Collaboration	Les équipes partageant un même tableau de bord (Git, CI, artefacts).

En bref : la DevOps ne change pas la nature de Dolibarr (ERP/CRM léger), mais elle garantit que chaque mise à jour du code ou de la configuration reste atomique, testée et déployable à chaud sans impacter les clients déjà en place.

2. Principes de Base Avant de Toucher à la Production

Étape	Objectif	Action concrète
1. Capture de l’état actuel	Documenter la configuration actuelle (versions, modules, bases de données, serveurs web).	`git clone …` → `dolibarr -v` + export `mysqldump` / `pg_dump`.
2. Mise en place d’un Environnement Imitatif	Reproduire exactement le même stack (PHP, Apache/Nginx, DB).	Docker‑compose ou Playbooks Ansible.
3. Automatiser les Tests fonctionnels	Vérifier que les scénarios clés (création devis, factures, relances) fonctionnent toujours.	Selenium / PHPUnit + scripts de paiement fictif.
4. Versionner tout	Code, configuration, scripts d’installation.	Git : `repo/dolibarr/`, `repo/infra/`.
5. Containeriser	Centraliser les dépendances (PHP 8.2, Docker, extensions).	`Dockerfile` + `docker-compose.yml`.
6. Définir le processus de release	Comment publier sans affecter les clients existants.	Blue‑Green / Canary ou Rolling Update avec feature‑flags.

Règle d’or : ne jamais installer ou modifier Dolibarr directement sur un serveur de production sans passer par le pipeline CI/CD décrit ci‑dessous.

3. Architecture de Déploiement Recommandée

3.1 Schéma visuel (textuel)

+----------------------+       +------------------+       +----------------------+

|  Docker Registry     | <---> |  CI (GitLab CI)  | <---> |  Helm / K8s / Docker |

+----------------------+       +------------------+       +----------------------+

                                     |

                                     v

                               +------------------+

                               |  Environnements  |

                               |  dev  → test  →  prod  |

                               +------------------+

3.2 Composants clés

Élément	Rôle	Exemple Docker image
PHP‑FPM 8.2	Exécution du code Dolibarr	`php:8.2-fpm-alpine`
Nginx	Proxy inverse, gestion des static files	`nginx:alpine`
MariaDB / PostgreSQL	Stockage persistant	`mariadb:10.11` ou `postgres:15`
Dolibarr	Application métier	`myorg/dolibarr:{{VERSION}}`
phpMyAdmin / Adminer	Debug DB (optionnel)	`phpmyadmin/phpmyadmin`
Prometheus + Grafana	Monitoring	`prom/prometheus`, `grafana/grafana`
Loki / Promtail	Collecte de logs	`grafana/loki`, `grafana/promtail`

4. Pipeline CI/CD « Sans Casser » (exemple GitLab CI)

stages:

  - lint  - test

  - build

  - push

  - deploy-preview

  - deploy-prod
variables:

  DOCKER_REGISTRY: registry.mycompany.com

  DOLIBARR_VERSION: "23.0.4"
# 1️⃣ Lint PHP & Dockerfilelint:

  stage: lint

  image: php:8.2-cli

  rules:

    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

  script:

    - composer self-update

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

    - docker run --rm -v $(pwd):/app -w /app php:${DOLIBARR_VERSION}-cli php -l $(find . -name "*.php" | grep -v "vendor")

    - docker build -t $DOCKER_REGISTRY/dolibarr:$DOLIBARR_VERSION --dry-run .
# 2️⃣ Tests fonctionnels (automatisés)

tests:

  stage: test

  image: php:8.2-cli

  services:

    - name: mariadb:10.11

      alias: db

      command: ["--default-authentication-plugin=mysql_native_password"]

    - name: phpadmin

      image: adminer      ports: ["8080:8080"]

  before_script:

    - docker pull mariadb:10.11

    - docker compose up -d db adminer

    - php -r "copy('https://raw.githubusercontent.com/PHPUnit/phpunit/phpunit/phpunit.xml', 'phpunit.xml');"

  script:

    - vendor/bin/phpunit

  after_script:

    - docker compose down
# 3️⃣ Build & Push image Docker

build:

  stage: build

  image: docker:latest

  services: [docker:dind]

  script:

    - docker build -t $DOCKER_REGISTRY/dolibarr:$DOLIBARR_VERSION:$CI_COMMIT_SHA .

    - docker push $DOCKER_REGISTRY/dolibarr:$DOLIBARR_VERSION:$CI_COMMIT_SHA

    - docker tag $DOCKER_REGISTRY/dolibarr:$DOLIBARR_VERSION:$CI_COMMIT_SHA $DOCKER_REGISTRY/dolibarr:$DOLIBARR_VERSION:latest

    - docker push $DOCKER_REGISTRY/dolibarr:$DOLIBARR_VERSION:latest

  rules:

    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
# 4️⃣ Deploy preview (Canary) sur un cluster test

deploy-preview:

  stage: deploy-preview

  image: alpine/k8s:1.27

  script:

    - helm upgrade --install dolibarr-preview ./helm/dolibarr \

        --set image.tag=$CI_COMMIT_SHA \

        --set service.type=LoadBalancer \

        --namespace preview

  environment: preview

  rules:

    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
# 5️⃣ Deploy de façon rolling sur prod (Blue‑Green ou Canary)

deploy-prod:

  stage: deploy-prod

  image: alpine/k8s:1.27

  script:

    - helm upgrade --install dolibarr-prod ./helm/dolibarr \

        --set image.tag=$CI_COMMIT_SHA \

        --set env=prod \

        --namespace prod

  environment: production

  rules:

    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Points clés du pipeline

Lint : évite les erreurs de syntaxe dès le commit.

Test : crée un conteneur MariaDB + adminer, lance les suites unitaires & fonctionnelles.

Build : construit deux tags (sha + latest) et les pousse dans le registre privé. * Deploy‑preview : chaque PR génère un environnement preview isolé (utile pour les revues).

Deploy‑prod : utilise Helm + rolling update avec maxSurge = 1 et maxUnavailable = 0 → aucune perte de service.

5. Stratégies de Release “Sans Casser”

Stratégie	Description	Quand l’utiliser
Blue‑Green	Deux versions de l’app (Blue = production, Green = nouvelle). Après validation, on migre le trafic via un load‑balancer.	Mises à jour majeures (nouvelle version de Dolibarr, changement de DB).
Canary	Déploiement à 5 % des pods, suivi des KPI (latence, erreurs). Si OK, on augmente le pourcentage.	Ajouts de fonctionnalités (ex. nouveau module Facturation automatique).
Feature‑Flag	Désactiver la fonctionnalité par défaut; l’activer progressivement via configuration.	Tests A/B, tests utilisateurs ciblés.
Rollback Immediate	En cas d’échec du helm upgrade, revenir à l’image précédente (`--replace`).	Toute modification survenant en production.
Hot‑Patch via Debian/RPM	Si vous ne pouvez pas containeriser immédiatement, créez un paquet `dolibarr_23.0.5_all.deb` versionnée et déployez via Ansible in‑place.	Environnements legacy qui ne supportent pas Docker.

Tip Opérationnel : automatiser le rollback via helm rollback dolibarr-prod <REVISION_ID> ou via le label app=prev_version dans votre manifest K8s.

6. Gestion de la Base de Données

Action	Méthode sans perte de données
Sauvegarde	`mysqldump --single-transaction --quick` → sauvegarde incrémentale sur un volume partagé (e.g. Ceph, NFS).
Migration schema	Utiliser Liquibase ou Flyway embarqués dans le conteneur (`php -f bin/liquibase.php migrate`).
Version des migrations	Stocker les scripts dans `db/migrations/` et les appliquer lors du post‑install du pipeline.
Synchronisation entre dev/test/prod	`docker compose exec db pg_dump -U dolibarr -Fc dolibarr > db_backup.dump` → restore via `pg_restore`.
Encryption at‑rest	Activer `TLS` sur le socket DB et Encrypt les volumes Docker (`--encrypt` dans les options de déploiement).

Bonnes pratiques : garder au moins 3 copies de la sauvegarde (au niveau jour, semaine, mois) et tester le restore sur un serveur de test chaque mois.

7. Monitoring & Alerting

Métrique	Outil	Seuil d’alerte recommandé
Latence HTTP (p99)	Prometheus	> 800 ms
Taux d’erreur 5xx	Prometheus	> 2 % des requêtes
Utilisation CPU/MEM du pod Dolibarr	Grafana	CPU > 80 % pendant > 5 min
Lien DB connexion saturée	Loki + alerts	`max_connections` > 90 %
File system disk usage	Prometheus	Disk > 85 %
Queue de paiement (si intégrée)	RabbitMQ / Kafka	Lag > 30 s

Alert routing : Notifications Slack → ticket JIRA → AWS SNS (ou équivalent interne).

8. Rollback « Sans Casser » – Checklist opératoire

Vérifier l’état

helm status dolibarr-prod -n prod | grep "REVISION"

Retourner à la version précédente



helm rollback dolibarr-prod 5 -n prod   ```

Re‑déployer le service de health‑check (si besoin)
```
kubectl rollout restart deployment/dolibarr -n prod
```

Notifier les équipes (slack/Teams) – “Rollback effectué à xx:xx, état : OK”.

Analyser les logs pour identifier la cause racine (issue ticket).

9. Checklist de Validation Avant mise en production

✅	Action
1	Image Docker scannée (Trivy / Clair) – aucun vulnérabilité critique.
2	Tests unitaires & fonctionnels ≥ 90 % de couverture.
3	Scénario smoke exécuté sur l’environnement `preview`.
4	Monitoring de base activé (CPU, RAM, latence).
5	Backup DB récent (< 15 min).
6	Document de changement (CHANGELOG) signé par le PO & Ops.
7	Fenêtre de maintenance définie (ex. 02:00‑03:00).
8	Plan de rollback testé en pré‑prod.
9	Communication aux clients internes/externes (mail, tableau de bord).
10	Tag Git annoté avec `release-<date>-v<NUM>`.

10. Exemple de Documentation « Version X.Y » dans le Repository

repo/

├─ dolibarr/

│   ├─ src/

│   └─ composer.json

├─ infra/

│   ├─ docker-compose.yml│   ├─ helm/

│   │   └─ values-prod.yaml

│   └─ templates/

│       ├─ deployment.yaml│       └─ service.yaml

├─ tests/

│   ├─ Functional/

│   └─ Unit/

├─ db/

│   └─ migrations/

│       └─ 2024-11-add-field-client_status.sql

└─ docs/

    ├─ architecture.md

    ├─ CI_pipeline.md    └─ rollback_checklist.md

11. FAQ Rapide| Question | Réponse courte |

|———-|—————-|
| Dois‑je‑il‑réécrire le code Dolibarr pour le DevOps ? | Pas obligatoirement : l’application reste PHP + HTML. Ce qui change, c’est comment on la construit, teste et déploie (conteneurs, CI). |
| Et si on ne maîtrise pas Kubernetes ? | Utilisez Docker Compose + Traefik en mode « Swarm » léger, ou Ansible + docker‑engine sur les serveurs. Le même pipeline CI/CD fonctionne, seule la partie déploiement change. |
| Peut‑on conserver les anciens paramètres PHP (ex.: max_execution_time) ? | Oui ; créez un fichier docker/php.ini dans le répertoire infra/php/ et montez‑le dans le conteneur via un ConfigMap. |
| Comment gérer les licences des modules payants ? | Placez les fichiers de licence dans un secret Docker (ou Vault) monté en ${DOLIBARR_LICENSE_PATH}; activez‑les au démarrage via le script d’initialisation. |
| J’ai besoin d’un accès database en lecture‑seule pour les reporting ? | Exposez un user dédié readonly avec les droits SELECT uniquement; créez-le via un script SQL injecté lors du init container. |

12. Checklist de mise en production – Version 1.0 (Multi‑client)

Phase	Tâches
A – Pré‑prod	`helm upgrade --install dolibarr-preview` + tests smoke.
B – Validation client	Partager l’URL du preview, récupérer feedback, vérifier logs.
C – Promotion	`helm upgrade --install dolibarr-prod` avec `--set image.tag=<SHA>` & `--set env=prod`.
D – Post‑déploiement	– Vérifier le health‑endpoint (`/dolibarr/version`). – Faire un smoke test sur les transactions (création facture). – Activer le monitoring et vérifier que les alertes sont à zéro.
E – Communication	Envoyer le Release Note aux équipes commerciales & support client.
F	Archiver le tag Git et le CHANGELOG dans le repository versionné.

13. Conclusion – « Deployer sans casser » devient une routine

Standardiser l’ensemble de la chaîne (code → image → déploiement).

Automatiser la validation (lint + tests) à chaque push.

Isoler les environnements (preview → prod) afin de protéger les clients existants.

Rouler les changements progressivement (Canary/Blue‑Green).

Documenter chaque version et garder un plan de rollback testé.

En suivant ce guide, vous pourrez publier de nouvelles versions de Dolibarr toutes les semaines, voire quotidiennement, sans crainte de « casser » les installations déjà en production.

Bonus : ajoutez un badge de conformité Docker Build Security (docker build --provenance) dans votre README pour rassurer les parties prenantes.

Bonne mise en production ! 🚀

DevOps Dolibarr : distribution Guide pratique sans casser l’existant

1. Pourquoi « DevOps » pour Dolibarr ?

2. Principes de Base Avant de Toucher à la Production

3. Architecture de Déploiement Recommandée

3.1 Schéma visuel (textuel)

3.2 Composants clés

4. Pipeline CI/CD « Sans Casser » (exemple GitLab CI)

Points clés du pipeline

5. Stratégies de Release “Sans Casser”

6. Gestion de la Base de Données

7. Monitoring & Alerting

8. Rollback « Sans Casser » – Checklist opératoire

9. Checklist de Validation Avant mise en production

10. Exemple de Documentation « Version X.Y » dans le Repository

11. FAQ Rapide| Question | Réponse courte |

12. Checklist de mise en production – Version 1.0 (Multi‑client)

13. Conclusion – « Deployer sans casser » devient une routine

Comment Dolibarr ERP peut-il améliorer votre productivité ?

Comment automatiser votre entreprise avec Dolibarr cloud ?

Comment automatiser votre entreprise avec Dolibarr comptabilité ?

Comment automatiser votre entreprise avec Dolibarr TVA Maroc ?

Dolibarr personnalisable : Avis et témoignages d’utilisateurs

Dolibarr et la TVA au Maroc : Guide Complet

1. Pourquoi « DevOps » pour Dolibarr ?

2. Principes de Base Avant de Touch­er à la Production

3. Architecture de Déploiement Recommandée

3.1 Schéma visuel (textuel)

3.2 Composants clés

4. Pipeline CI/CD « Sans Casser » (exemple GitLab CI)

Points clés du pipeline

5. Stratégies de Release “Sans Casser”

6. Gestion de la Base de Données

7. Monitoring & Alerting

8. Rollback « Sans Casser » – Checklist opératoire

9. Checklist de Validation Avant mise en production

10. Exemple de Documentation « Version X.Y » dans le Repository

11. FAQ Rapide| Question | Réponse courte |

12. Checklist de mise en production – Version 1.0 (Multi‑client)

13. Conclusion – « Deployer sans casser » devient une routine

Publications similaires

1. Pourquoi « DevOps » pour Dolibarr ?

2. Principes de Base Avant de Toucher à la Production

4. Pipeline CI/CD « Sans Casser » (exemple GitLab CI)

8. Rollback « Sans Casser » – Checklist opératoire

10. Exemple de Documentation « Version X.Y » dans le Repository

13. Conclusion – « Deployer sans casser » devient une routine