mcp-wms-wiki/wiki_old_13-05-2026/operations/development-methodology.md

title, type, sources, related, last_compiled

title	type	sources	related	last_compiled
Development Methodology (Custom Apps)	operation	sources/archives/Présentation_méthode_de_développement.md	architecture/overview.md architecture/application-dictionary.md operations/configuration-guide.md operations/git-branch-lifecycle.md operations/git-workflow.md operations/code-review-process.md operations/deploy-test-application.md	2026-04-17

Development Methodology (Custom Apps)

Overview

Méthode de développement interne Mecalux EasyWMS France pour les custom applications (extensions AD déployées au-dessus du core EasyWMS). La méthode régit le cycle de vie des développements custom depuis le poste du développeur jusqu'à la mise en production, via une stratégie de branches GIT dédiée.

Objectifs :

1. Réduire les temps de compilation — chaque développeur compile uniquement sa propre branche
2. Distinguer clairement trois états : ce qui est en production, ce qui est à livrer (validé, prêt pour release) et ce qui est en cours de développement (non validé)

Référence source : Confluence EasyWMS France — Présentation méthode de développement (v8, 29/12/2023).

Stratégie de branches GIT

Branche	Rôle	Contenu
master	Production	Reflète exactement l'état actuel en production. Permet de redéployer à tout moment sans perte. Contient uniquement ce qui a été testé et validé.
développement	Intégration	Base de toutes les branches de développements individuelles. Reçoit les merges des branches de devs après validation locale.
<branche-dev> (par développeur)	Développement individuel	Issue de développement. Chaque développeur travaille sur sa propre branche sur sa machine locale.
post-production	Correctifs livrés post-prod	Créée si un développement a lieu après une mise en production. Mergée uniquement juste avant la mise en production suivante pour ne pas écraser les modifications de master.

Phases du cycle de développement

1. Phase de développement

1. Chaque développeur dispose de sa propre machine de développement sur son PC.
2. Chaque développeur travaille sur une branche GIT personnelle issue de la branche développement.
3. Après chaque merge ou rebase, le développeur redéploie la custom app depuis sa branche de développement (compilation locale).
4. Manuel de reten : pendant les développements, les notes sont consignées dans un fichier Markdown (facilite les merges). À la fin des développements, les données du fichier Markdown sont copiées/collées dans le manuel de reten au format DOC.

2. Phase de tests

1. Lorsqu'une partie ou la totalité des développements est terminée, la custom application est déployée sur une machine dédiée hébergée sur le serveur de test.
2. Les testeurs testent depuis ce serveur sans avoir à monter une machine sur leur propre PC.
3. Correction des bugs — deux options (point à valider selon le chantier) :
   • Option A : le développeur corrige directement sur le serveur de test.
   • Option B : le développeur corrige sur sa machine de développement locale puis redéploie sur le serveur de test.

3. Post-production

1. Après mise en production, la branche master reflète l'état déployé et sert de filet de sécurité pour un redéploiement éventuel.
2. Si de nouveaux développements sont entamés après la mise en prod, une branche post-production est créée.
3. Cette branche post-production n'est mergée qu'au dernier moment, juste avant la prochaine mise en production, pour éviter d'écraser les modifications présentes sur master (hotfixes éventuels, état de production courant).

Schéma du flux

master ──────────────●─────────────────●──── (production courante, intouchable hors release)
                     │                 ▲
                     │                 │ (merge avant MEP)
développement ───●───┼──●───●──●───────●──── (intégration)
                 │   ▲  │   │  ▲
                 │   │  │   │  │
branche-dev-A ───●───●  │   │  │   (dev individuel → merge ds développement)
branche-dev-B ───────────●──●  │
post-production ───────────────● ─── (créée après MEP, mergée juste avant MEP suivante)

Règles pratiques

• Ne jamais committer directement sur master — toute modification passe par développement puis release.
• Ne jamais merger post-production prématurément — cela écraserait des correctifs présents sur master.
• Redéploiement de la custom app après chaque merge/rebase pour vérifier que la compilation passe et que l'app démarre.
• Fichier Markdown obligatoire pour le manuel de reten durant tout le développement — la conversion vers DOC n'intervient qu'en fin de chantier.

Common errors

• Compilation lente sur toutes les machines → vérifier que chaque dev est bien sur sa propre branche et ne compile pas l'intégralité de développement.
• Modifications de production écrasées après mise en prod → cause probable : post-production mergée trop tôt. Toujours merger post-production uniquement juste avant la MEP suivante.
• Conflits massifs sur le manuel de reten en format DOC → cause : plusieurs développeurs éditent le DOC en parallèle. Solution : utiliser le fichier Markdown pendant toute la durée du développement, copier/coller vers DOC uniquement à la fin.
• Bug reproduit uniquement sur le serveur de test → l'option A (correction directe sur serveur de test) peut masquer le problème. Préférer l'option B (correction locale + redéploiement) pour conserver un historique GIT propre.

Related

• System Architecture Overview — contexte de déploiement custom apps (IIS, compilation, SaaS vs on-premise)
• Application Dictionary — éléments AD packagés dans la custom app
• Configuration Guide — configuration post-déploiement