Arthur Ria
6.4 KiB
title, type, sources, related, last_compiled
| title | type | sources | related | last_compiled | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Deploy Test Application (Tag → Test VM) | operation |
|
|
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 (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 :
git switch develop
git pull
git tag <Tag Name>
git push --tags
git checkout <Tag Name>
SourceTree :
- Se positionner sur la branche
develop→ faire un "Pull" - Cliquer sur "Tag"
- "Tag Name" : nom du tag (
<TRIGRAMME>-V<N>) - Choisir le commit précis ou prendre la dernière version de
develop - Cocher "Push tag" pour le créer aussi sur la branche distante
- 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) — 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.
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.
5. Installer le printer service et la licence
Suivre la procédure : gna-services-license (sections Printer Service et Licence WMS).
6. Valider la VM
Procédure de validation post-déploiement : vm-installation — Validation.
En particulier vérifier l'accès SmartUI / consoleRF / EasySTS depuis le PC du CdP — utiliser les ports NAT (vm-network-routing) 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 --tagsou cocher "Push tag" dans SourceTree.
Related
- Git Branch Lifecycle — phase "développement initial", quand cette procédure s'applique
- Git Workflow (Git Flow) — opérations Git détaillées (CLI / SourceTree)
- Deploy Existing Application — procédure de redéploiement réutilisée à l'étape 3
- Deploy Specific Commit — procédure jumelle pour figer un commit sur sa propre VM de dev (vs VM de test partagée ici)
- GNA, Services & License — étapes 4 (réinstallation GNA) et 5 (printer + licence)
- VM Installation & Validation — checkpoint "Deploy 0" et validation post-déploiement
- VM Network Routing — accès distant à la VM de test depuis le PC du CdP