Arthur Ria
95 lines
6.3 KiB
Markdown
95 lines
6.3 KiB
Markdown
---
|
|
title: "Development Methodology (Custom Apps)"
|
|
type: operation
|
|
sources:
|
|
- sources/archives/Présentation_méthode_de_développement.md
|
|
related:
|
|
- 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
|
|
last_compiled: "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](../architecture/overview.md) — contexte de déploiement custom apps (IIS, compilation, SaaS vs on-premise)
|
|
- [Application Dictionary](../architecture/application-dictionary.md) — éléments AD packagés dans la custom app
|
|
- [Configuration Guide](configuration-guide.md) — configuration post-déploiement
|