Mecalux/mcp-wms-wiki
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

lint(standard): corrections completes mode standard

Browse Source 
- Em dashes: 1712 remplaces par tirets simples (86 fichiers + _index.md,
  en-tete section Limagrain conserve)
- Checklists: 24 '- [ ]' -> '- ☐' (3 pages operations, plus de todos Obsidian)
- Ancres: 33 reparees (slugs GitHub + ancres HTML <a id> reconnues),
  1 reciblee (manuel de reten)
- related: tenseflow -> tense-flow, pie -> mechanical-elements,
  group.md retire (doublon shipping)
- Registre: compteur global 122 -> 131 pages
- Rapport racine _lint_report.md mis a jour (scan v2 + re-scan final: 0 anomalie)
- Aucun fichier limagrain/ modifie (cloisonnement)
This commit is contained in:
Arthur
2026-07-20 13:01:21 +02:00
parent 7496aafe64
commit 9ce6ae37be
88 changed files with 1769 additions and 1871 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wiki/operations/deployment-specific-commit.md
+9 -9
View File
@@ -23,7 +23,7 @@ Procédure pour déployer une VM de développement sur un **commit figé** plut
Le principe : créer un tag GIT sur le commit cible, créer une branche à partir de ce tag, puis utiliser le mécanisme standard de déploiement par branche (`deploy_repository.ps1 <Projet> <Branche>`).
Source : Confluence EasyWMS France — *Déploiement d'une VM sur un commit spécifique* (v3, 09/06/2023).
Source : Confluence EasyWMS France - *Déploiement d'une VM sur un commit spécifique* (v3, 09/06/2023).
## Prérequis
@@ -78,14 +78,14 @@ Côté VM, utiliser le script de déploiement standard en référençant la nouv
.\deploy_repository.ps1 NomDuProjetGit NomDeLaNouvelleBranche
```
La suite (Tenants.xml → `InMemory`, `iisreset`…) suit la procédure standard de redéploiement : cf. [deployment-existing-app](deployment-existing-app.md#étape-7--désactiver-les-instances-en-bdd-obligatoire).
La suite (Tenants.xml → `InMemory`, `iisreset`…) suit la procédure standard de redéploiement : cf. [deployment-existing-app](deployment-existing-app.md#étape-7---désactiver-les-instances-en-bdd-obligatoire).
## Règles pratiques
- **Un tag + une branche par version à déployer** — ne jamais forcer le déploiement directement sur un commit détaché, qui échapperait au script de déploiement (basé sur branche).
- **Nommage `<PREFIXE>-V<N>` incrémental** — facilite la lecture de l'historique et le support côté client.
- **Fetch all tags avant toute opération** — sinon risque de recréer un tag qui existe déjà, ou de manquer la version cible.
- **Pousser tags et branches** — si l'autre dev / l'environnement de test doit pouvoir y accéder, le push est indispensable.
- **Un tag + une branche par version à déployer** - ne jamais forcer le déploiement directement sur un commit détaché, qui échapperait au script de déploiement (basé sur branche).
- **Nommage `<PREFIXE>-V<N>` incrémental** - facilite la lecture de l'historique et le support côté client.
- **Fetch all tags avant toute opération** - sinon risque de recréer un tag qui existe déjà, ou de manquer la version cible.
- **Pousser tags et branches** - si l'autre dev / l'environnement de test doit pouvoir y accéder, le push est indispensable.
## Common errors
@@ -96,6 +96,6 @@ La suite (Tenants.xml → `InMemory`, `iisreset`…) suit la procédure standard
## Related
- [Deploy Existing Application](deployment-existing-app.md) — procédure de déploiement standard (référencée en étape 4)
- [First Deployment](first-deployment.md) — première initialisation d'un projet
- [Git Workflow](git-workflow.md) — stratégie de branches générale
- [Deploy Existing Application](deployment-existing-app.md) - procédure de déploiement standard (référencée en étape 4)
- [First Deployment](first-deployment.md) - première initialisation d'un projet
- [Git Workflow](git-workflow.md) - stratégie de branches générale