---
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