Bonnes pratiques : préparer son environnement de création de versions
Pourquoi cette page ?
Une nouvelle version est une photographie du poste master au moment où vous la créez. Tout ce qui se trouve sur ce poste à cet instant (logiciels, réglages, fichiers de test, appartenance à un domaine, traces d'un ancien essai…) sera embarqué dans la version et redescendu sur l'ensemble des postes qui la recevront.
Un environnement de création propre et maîtrisé, c'est donc :
- des versions fiables et reproductibles ;
- moins d'incidents après déploiement ;
- un diagnostic plus simple quand quelque chose ne fonctionne pas.
Ce que vous saurez faire à la fin de cette page
- Organiser votre environnement autour de deux postes aux rôles distincts : création et validation.
- Configurer correctement la machine virtuelle master.
- Éviter les trois pièges les plus fréquents : le domaine, l'antivirus et la persistance.
- Retrouver et tagger votre nouvelle version dans Vision temps réel.
1. Un poste, un rôle
Séparez systématiquement la fabrication et le contrôle de vos versions.
| Poste | Rôle | Ce qu'on y fait | Ce qu'on n'y fait pas |
|---|---|---|---|
| Poste de création (VM master) | Fabriquer la version | Installer, configurer, créer la version | Tests utilisateurs, usage quotidien |
| Poste de validation | Contrôler la version | Recevoir la version, vérifier les applications, les accès, le comportement | Modifier le master |
Pourquoi deux postes ? Si vous validez une version sur le poste qui l'a créée, vous testez l'environnement de fabrication et non ce que recevront réellement vos utilisateurs. Le poste de validation se comporte comme un poste de production : c'est lui qui vous dit la vérité.
2. Configurer la machine virtuelle master
Dédiez une machine virtuelle à la création des versions. Elle ne sert qu'à cela.
Dans sa configuration W360, activez :
- ✅ La persistance : vos modifications sont conservées entre deux redémarrages, ce qui vous permet de préparer une version en plusieurs étapes.
- ✅ Le renommage : le poste conserve un nom stable et identifiable, propre au master.
Pourquoi une VM ? Elle est facile à sauvegarder, à cloner et à restaurer. En cas d'erreur, vous revenez rapidement à un état sain.
3. Le domaine : la règle d'or
Un poste joint au domaine embarque des éléments qui lui sont propres (identité machine, stratégies de groupe, relation d'approbation…). Intégrés dans une version, ils sont dupliqués sur tous les postes et provoquent des conflits difficiles à diagnostiquer.
Vous avez besoin du domaine ponctuellement (pour installer ou tester un logiciel, par exemple) ?
- Faites entrer le poste dans le domaine.
- Réalisez votre opération.
- Sortez le poste du domaine et redémarrez-le.
- Vérifiez que le poste est bien en groupe de travail avant de lancer toute création de version.
Un oubli à l'étape 3 se retrouve directement dans la version. Faites de cette vérification un réflexe.
4. L'antivirus : autoriser nos utilitaires
Les utilitaires W360 interviennent en profondeur sur le système. Un antivirus qui ne les connaît pas peut les bloquer, les ralentir ou les mettre en quarantaine, avec pour conséquence une version incomplète ou une création en échec.
À faire : ajoutez les utilitaires W360 à la liste blanche (exclusions) de votre antivirus, sur le poste de création comme sur le poste de validation.
📖 La liste des éléments à exclure et la marche à suivre sont détaillées dans la documentation spécifique antivirus.
5. La persistance : repartir d'une base propre
La persistance est utile… et c'est aussi le piège le plus fréquent.
Il est tentant d'utiliser le poste master pour « faire un petit test rapide ». Or, comme l'environnement est persistant, tout ce que vous y faites est conservé : logiciels d'essai, réglages modifiés, fichiers temporaires, comptes utilisés. Si vous créez une version ensuite, tous ces éléments partent avec elle.
Avant de préparer toute nouvelle version :
- Faites le point : ce poste a-t-il servi à autre chose depuis la dernière version ?
- Si oui, ou en cas de doute, supprimez les modifications persistantes pour repartir de la dernière version propre. C'est la méthode recommandée.
- Appliquez ensuite uniquement les modifications prévues pour la nouvelle version.
Le bon réflexe : « Je pars toujours d'une base propre. » Une suppression prend quelques minutes ; une version polluée déployée sur tout un parc peut coûter des jours.
6. Après la création : retrouver et tagger sa version
Une fois créée, votre version apparaît dans Vision temps réel. Elle n'a pas encore de tag : elle est donc masquée par défaut.
- Ouvrez Vision temps réel.
- Activez l'affichage des versions non taggées.
- Repérez votre nouvelle version.
- Attribuez-lui son tag.
Conseil : adoptez une convention de nommage commune pour vos tags (par exemple, date + objet de la version). Vous retrouverez plus facilement une version et saurez immédiatement ce qu'elle contient.
Vous pouvez maintenant poursuivre avec la procédure de déploiement adaptée à votre mode : V.OS ou D.OS.
✅ Check-list avant chaque création de version
- Je travaille sur la VM master dédiée (persistance et renommage activés).
- Le poste n'est pas dans le domaine (ou il en est bien sorti, puis a redémarré).
- Les utilitaires W360 sont dans la liste blanche de l'antivirus.
- Les modifications persistantes antérieures ont été supprimées : je pars d'une base propre.
- Seules les modifications prévues pour cette version ont été appliquées.
- Un poste de validation est prêt pour contrôler la version.
En résumé
| Règle | Pourquoi |
|---|---|
| Un poste pour créer, un poste pour valider | Tester ce que recevront réellement les utilisateurs |
| VM master dédiée, avec persistance et renommage | Un environnement stable, identifiable et restaurable |
| Jamais dans le domaine au moment de la création | Éviter de dupliquer une identité machine sur tout le parc |
| Utilitaires en liste blanche antivirus | Éviter blocages et versions incomplètes |
| Supprimer la persistance avant une nouvelle version | Ne pas embarquer les traces de tests |
| Afficher les versions non taggées pour tagger | Rendre la version identifiable et déployable |
Updated about 2 hours ago