mcp-wms-wiki/wiki_old_13-05-2026/operations/deployment-specific-commit.md

title, type, sources, related, last_compiled

title	type	sources	related	last_compiled
Deploy Specific Commit	operation	sources/archives/Deploiement_VM_commit_specifique.md	operations/deployment-existing-app.md operations/first-deployment.md operations/git-workflow.md	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 :

.\deploy_repository.ps1 NomDuProjetGit NomDeLaNouvelleBranche

La suite (Tenants.xml → InMemory, iisreset…) suit la procédure standard de redéploiement : cf. deployment-existing-app.

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 — procédure de déploiement standard (référencée en étape 4)
• First Deployment — première initialisation d'un projet
• Git Workflow — stratégie de branches générale