màj wiki avec retour MES lot-5 AD
This commit is contained in:
Arthur Ria
@@ -0,0 +1,126 @@
|
||||
---
|
||||
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
|
||||
Reference in New Issue
Block a user