--- 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 ``` -V ``` 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 git push --tags git checkout ``` **SourceTree :** 1. Se positionner sur la branche **`develop`** → faire un **"Pull"** 2. Cliquer sur **"Tag"** 3. **"Tag Name"** : nom du tag (`-V`) 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 ` (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