mcp-wms-wiki/wiki/operations/deploy-test-application.md

---
title: "Deploy Test Application (Tag → Test VM)"
type: operation
sources:
  - sources/archives/Deployer_application_en_test.md
related:
  - operations/git-branch-lifecycle.md
  - operations/git-workflow.md
  - operations/deployment-existing-app.md
  - operations/deployment-specific-commit.md
  - operations/gna-services-license.md
  - operations/vm-installation.md
  - operations/vm-network-routing.md
last_compiled: "2026-04-17"
---

# Deploy Test Application (Tag → Test VM)

## Overview

Procédure interne Mecalux EasyWMS France pour **livrer un lot de développements aux chefs de projet pour test**, sur la **VM de test** (distincte de la VM de dev de chaque développeur). Le déploiement en test peut être fait :

- **Par lot** (livraison intermédiaire, plusieurs features groupées)
- **À la fin des développements** (livraison complète avant MEP)

…selon la taille du projet.

Le pivot de la procédure est la **création d'un tag Git** sur le commit `develop` choisi : cela garantit que la version déployée et testée par le CdP est **figée**, indépendamment de tout commit ultérieur sur `develop` (potentiellement en cours de dev / non testé).

Source : Confluence EasyWMS France — *Déployer l'application en test* (v1, 20/12/2022).

## Convention de nommage des tags

```
<TRIGRAMME_PROJET>-V<NUMERO>
```

Exemple : `LMD-V1`, `LMD-V2`, `SPEN-V3`.

> Cette convention est **identique** à celle utilisée pour [deployment-specific-commit](deployment-specific-commit.md) (déploiement sur un commit figé d'une VM de dev). La nuance : ici on travaille sur la **VM de test partagée** par les chefs de projet ; là-bas on figeait un commit sur sa propre VM de dev.

## Procédure (7 étapes)

### 1. Création du tag sur `develop`

**Git CLI :**
```bash
git switch develop
git pull
git tag <Tag Name>
git push --tags
git checkout <Tag Name>
```

**SourceTree :**
1. Se positionner sur la branche **`develop`** → faire un **"Pull"**
2. Cliquer sur **"Tag"**
3. **"Tag Name"** : nom du tag (`<TRIGRAMME>-V<N>`)
4. Choisir le commit précis ou prendre la dernière version de `develop`
5. **Cocher "Push tag"** pour le créer aussi sur la branche distante
6. Une fois le tag créé : **double-clic sur le tag** dans la liste pour s'y positionner

### 2. Remettre la VM de test sur le checkpoint **"Deploy 0"**

Appliquer le point de contrôle Hyper-V **"Deploy 0"** sur la VM de test **avant** le déploiement.

> Le checkpoint "Deploy 0" est créé à la fin de la procédure d'installation initiale de la VM (cf. [vm-installation](vm-installation.md)) — c'est l'état "VM prête à recevoir un déploiement, vide de tout projet".

### 3. Déploiement de l'application existante

Suivre la procédure complète : [deployment-existing-app](deployment-existing-app.md).

> Pour déployer **par tag** plutôt que par branche : utiliser `deploy_repository.ps1 <Projet> <NomDuTag>` (le script accepte un tag comme deuxième argument, comme une branche).

### 4. Réinstallation du GNA (si besoin)

Si la livraison contient des modifications BOO du GNA → réinstaller le GNA : [gna-services-license — Réinstallation](gna-services-license.md#réinstallation-du-gna).

### 5. Installer le **printer service** et la **licence**

Suivre la procédure : [gna-services-license](gna-services-license.md) (sections Printer Service et Licence WMS).

### 6. Valider la VM

Procédure de validation post-déploiement : [vm-installation — Validation](vm-installation.md#validation-de-la-vm).

> En particulier vérifier l'accès SmartUI / consoleRF / EasySTS depuis le PC du CdP — utiliser les ports NAT ([vm-network-routing](vm-network-routing.md)) si la VM de test est sur un autre poste.

### 7. Mise à jour des tâches Jira

Pour **toutes les tâches** dont les développements sont inclus dans le tag :

| Action | Détail |
|---|---|
| Transition statut | **"Attente déploiement pour test" → "Prêt à tester"** |
| **Champ tag (obligatoire)** | Renseigner l'**étiquette Git** créée à l'étape 1 (ex : `LMD-V1`) |

> ⚠️ Le tag est **obligatoire** lors du passage en "Prêt à tester". Sans tag, le CdP ne peut pas vérifier la version testée et le test n'est pas reproductible.

## Pourquoi un tag (et pas un déploiement direct de `develop`) ?

| Risque sans tag | Conséquence |
|---|---|
| Commit `develop` ultérieur non testé | Bug introduit après les tests CdP est inclus si on déploie `develop` au moment de la présentation client |
| Pas de version stable de référence | Impossible de revenir précisément à la version testée pour debug |
| Présentation client risquée | Le CdP ne sait pas exactement ce qui tourne sur la VM de test |

Le tag fige le commit → la livraison est **reproductible** et **garantie sans bug postérieur**.

## Common errors

- **CdP voit un bug introduit après ses tests** → la VM de test a été redéployée sur `develop` (HEAD) et non sur le tag. Toujours déployer le tag explicite.
- **Jira "Prêt à tester" sans tag renseigné** → tâche bloquée pour le CdP. Renseigner le tag obligatoirement à la transition.
- **VM de test pas remise sur "Deploy 0"** → résidus du déploiement précédent (custom app, données) peuvent fausser les tests. Toujours appliquer le checkpoint avant un nouveau déploiement.
- **Printer service / licence oubliés** → CdP ne peut pas tester l'impression d'étiquettes ni les fonctionnalités payantes. Étapes 4-5 sont des étapes à part entière, pas des "si besoin".
- **Tag créé sans le pousser** → seul le développeur voit le tag, le CdP ne peut pas le retrouver. Toujours `git push --tags` ou cocher "Push tag" dans SourceTree.

## Related

- [Git Branch Lifecycle](git-branch-lifecycle.md) — phase "développement initial", quand cette procédure s'applique
- [Git Workflow (Git Flow)](git-workflow.md) — opérations Git détaillées (CLI / SourceTree)
- [Deploy Existing Application](deployment-existing-app.md) — procédure de redéploiement réutilisée à l'étape 3
- [Deploy Specific Commit](deployment-specific-commit.md) — procédure jumelle pour figer un commit sur sa propre VM de dev (vs VM de test partagée ici)
- [GNA, Services & License](gna-services-license.md) — étapes 4 (réinstallation GNA) et 5 (printer + licence)
- [VM Installation & Validation](vm-installation.md) — checkpoint "Deploy 0" et validation post-déploiement
- [VM Network Routing](vm-network-routing.md) — accès distant à la VM de test depuis le PC du CdP