arthur
9ce6ae37be
- 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)
102 lines
4.2 KiB
Markdown
102 lines
4.2 KiB
Markdown
---
|
|
title: "Deploy Specific Commit"
|
|
type: operation
|
|
sources:
|
|
- sources/archives/Deploiement_VM_commit_specifique.md
|
|
related:
|
|
- operations/deployment-existing-app.md
|
|
- operations/first-deployment.md
|
|
- operations/git-workflow.md
|
|
last_compiled: "2026-04-17"
|
|
---
|
|
|
|
# Deploy Specific Commit
|
|
|
|
## Overview
|
|
|
|
Procédure pour déployer une VM de développement sur un **commit figé** plutôt que sur le HEAD d'une branche. Utile quand :
|
|
|
|
- On doit **reproduire un bug** signalé sur une version précise
|
|
- On souhaite **comparer le comportement** entre deux versions
|
|
- On prépare une démo / test de régression qui doit rester stable même si `develop` avance
|
|
- On étudie une **hotfix candidate** avant de la merger
|
|
|
|
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).
|
|
|
|
## Prérequis
|
|
|
|
- Dépôt GIT du projet cloné en local
|
|
- **SourceTree** installé (la procédure est décrite via SourceTree ; équivalents CLI possibles mais non décrits côté source)
|
|
- Droit de push sur le dépôt distant (création de tag + création de branche)
|
|
|
|
## 1. Mettre à jour le GIT local
|
|
|
|
1. Lancer **SourceTree** et importer votre projet
|
|
2. Faire un **Fetch** en **cochant "Fetch all tags"** pour récupérer tags et branches du remote
|
|
|
|
## 2. Identifier et taguer le commit
|
|
|
|
> ⚠️ L'identification du bon commit peut être délicate (fusions, rebases, cherry-picks). En cas de doute, demander un avis extérieur.
|
|
|
|
### Créer le tag
|
|
|
|
1. Clic droit sur le commit cible → **"Tag"**
|
|
2. Nommer le tag selon la **convention projet** : préfixe Jira + numéro de version
|
|
|
|
### Convention de nommage
|
|
|
|
```
|
|
<PREFIXE_JIRA>-V<NUMERO>
|
|
```
|
|
|
|
Exemple pour le projet Spengler (préfixe Jira `SPEN`) :
|
|
|
|
```
|
|
SPEN-V1
|
|
SPEN-V2
|
|
SPEN-V3
|
|
…
|
|
```
|
|
|
|
### Pousser le tag
|
|
|
|
**Push le tag sur le remote** pour qu'il soit partagé avec l'équipe.
|
|
|
|
## 3. Créer une branche sur le commit tagué
|
|
|
|
1. Clic droit sur le commit tagué → **"Branch"**
|
|
2. Nommer la branche (par ex. réutiliser le nom du tag ou ajouter un suffixe `-deploy`)
|
|
3. **Pousser la branche** sur le remote
|
|
|
|
## 4. Déployer la VM sur la nouvelle branche
|
|
|
|
Côté VM, utiliser le script de déploiement standard en référençant la nouvelle branche plutôt que `develop` :
|
|
|
|
```powershell
|
|
.\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).
|
|
|
|
## 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.
|
|
|
|
## Common errors
|
|
|
|
- **Tag créé mais non poussé** → le déploiement par branche marche localement mais personne d'autre ne peut reproduire. Toujours push le tag + la branche.
|
|
- **Mauvais commit tagué (merge commit)** → on déploie un merge plutôt que le contenu réel. En cas de doute, demander un avis externe comme le rappelle la source.
|
|
- **Conflit de nom de tag** (`<PREFIXE>-V3` existe déjà) → incrémenter le numéro ou supprimer l'ancien (risqué si partagé). Privilégier l'incrément.
|
|
- **Deploy sur détaché HEAD** → le script attend un nom de branche valide. Toujours créer une branche à partir du tag avant de déployer.
|
|
|
|
## 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
|