Procédure de déploiement d’une nouvelle version — D.OS

Cette documentation décrit le processus de déploiement d’une nouvelle version d’un master D.OS, depuis la préparation du master jusqu’à la mise en production.

En mode D.OS, l’environnement final utilisé par l’utilisateur est une partition Windows native. Le master D.OS est préparé depuis une VM Master persistante sur un poste d’administration, puis la version est publiée et appliquée lors d’un redémarrage vers W Core.

Point important
Les tâches d’administration et de modification du master se font depuis un poste d’administration.
Le poste d’administration et le poste utilisateur sont deux postes distincts.

Objectif

Décrire un processus simple, progressif et sécurisé pour :

• préparer une nouvelle version de master D.OS ;
• répliquer la version sur les WRS ;
• distribuer la version aux postes utilisateurs ;
• appliquer la nouvelle version via W Core ;
• officialiser la version après validation.

1. Principe de fonctionnement

Le processus repose sur une séparation claire entre le poste utilisé par l’administrateur et les postes utilisés par les utilisateurs finaux.

2. Prérequis techniques

Configuration WRS / Chunkstore

Pour garantir le bon fonctionnement du mécanisme d’automatisation, le Chunkstore doit autoriser le téléchargement automatique des versions associées aux tags suivants :

• dev
• push
• prod

Sans ce paramétrage, les blocs de données ne sont pas correctement répliqués sur les WRS locaux, ce qui peut compromettre le bon déroulement du déploiement.

Préparation des environnements D.OS

Les environnements D.OS doivent être :

• affectés à un groupe ;
• configurés avec un démarrage automatique ;
• associés à une planification comprenant :
  • un arrêt automatique le soir ;
  • un réveil réseau Wake-on-LAN ;
  • un redémarrage automatique vers W Core, au moins une fois par semaine, ou plus si nécessaire.

Le démarrage via BIOS n’est pas compatible avec le mode D.OS.

Cette organisation permet le téléchargement de la version en arrière-plan, puis son application au moment du redémarrage vers W Core.

3. Préparation spécifique du master D.OS

La mise à jour d’un master D.OS suit la même logique générale qu’un master V.OS, mais avec des points de vigilance supplémentaires.

Depuis le poste d’administration, l’administrateur doit notamment :

1. ouvrir la VM Master D.OS en mode persistant ;
2. réaliser les mises à jour nécessaires ;
3. vérifier les pilotes et composants système ;
4. contrôler les éléments spécifiques D.OS, par exemple :
   • pilotes nécessaires au fonctionnement natif ;
   • configuration du registre ou du VHDX si applicable ;
   • services nécessaires au bon fonctionnement du Wi-Fi ou du réseau ;
5. verrouiller de nouveau le master ;
6. créer une nouvelle version depuis le W360 Manager.

4. Processus de déploiement D.OS

La nouvelle version D.OS est téléchargée en tâche de fond, puis appliquée lors d’un redémarrage vers W Core. Cette étape permet la récupération des chunks, la complétion système et la remasterisation automatique de D.OS.

5. Cycle de version

Le déploiement n’est pas une action unique. Il repose sur un cycle de tags permettant de préparer, distribuer, activer puis officialiser la version.

6. Calendrier de déploiement J à J+5

7. Points de contrôle avant diffusion large

8. À retenir

• Le master D.OS est modifié depuis un poste d’administration.
• Le poste d’administration et le poste utilisateur sont deux postes distincts.
• L’environnement final utilisateur est une partition Windows native.
• Le cycle de déploiement s’appuie sur les tags dev, push et prod.
• L’activation nécessite un redémarrage vers W Core.
• Le redémarrage vers W Core déclenche la récupération des chunks, la complétion système et la remasterisation D.OS.
• La mise en production intervient après validation du parc et 48 heures de stabilité.

9. Comparatif rapide V.OS / D.OS