Files
mcp-wms-wiki/wiki/sources/archives/Présentation_méthode_de_développement.md
T
2026-05-20 09:41:27 +02:00

51 lines
2.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Présentation méthode de développement
> Source : [Confluence EasyWMS France](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000083316739)
> Dernière mise à jour : 29/12/2023 (v8)
---
## 🏆 Objectifs
1. Réduire les temps de compilation
2. Distinction entre ce qui est en production, ce qui est à livrer et ce qui est en cours de développement
---
## ️ Informations
1. La branche **master** du contrôle de version contiendra toujours les tâches testées et validées.
2. La branche **développement** du contrôle de version sera la base de toutes les branches de développements.
---
## 💻 Phase de développements
1. Chaque développeur aura sa machine de développement sur son PC et une branche GIT issue de la branche de développement.
2. Après chaque merge ou rebase, ils redéploieront la custom app depuis leur branche de développement.
3. Pour le manuel de reten, nous mettrons en place un fichier en markdown afin de faciliter les merges.
À la fin des développements, les données de ce fichier seront copier/coller dans le manuel de reten au format DOC.
---
## 🧪 Phase de tests
1. Lorsqu'une partie des développements ou tous les développements sont terminés, la custom application sera déployée sur une machine qui se trouvera sur le serveur de test.
2. Ceci permettra aux testeurs de tester sans avoir à monter la machine sur leur PC.
3. Les développeurs pourront corriger les bugs trouvés lors des différents tests directement sur le serveur de test.
**OU** *(point à valider)*
En cas de bugs trouvés, le développeur corrige sur sa machine de développement et redéploie sur le serveur de test.
---
## 🏁 Post-production
1. La branche **master** contiendra toujours l'état actuel de la production afin de pouvoir redéployer à tout moment sans perte de données.
2. Si développement il y a, une branche **post production** sera créée et sera mergée seulement avant mise en production pour éviter d'écraser les modifications de master.
---
## 📼 Vidéo de présentation (Obsolète)
[Disponible ici](https://mecaluxgroup-my.sharepoint.com/personal/thomas_chaillou_mecalux_com/_layouts/15/stream.aspx?id=%2Fpersonal%2Fthomas%5Fchaillou%5Fmecalux%5Fcom%2FDocuments%2FRecordings%2FPr%C3%A9sentation%20nouvelle%20m%C3%A9thode%20de%20d%C3%A9veloppement%2D20221013%5F100730%2DEnregistrement%20de%20la%20r%C3%A9union%2Emp4&ga=1)