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.

Le tag dev a deux rôles : répliquer et qualifier

Dans cette procédure, le tag dev sert d'abord à lancer la réplication de la nouvelle version vers les WRS, grâce à la configuration du Chunkstore. Il a aussi un deuxième rôle, tout aussi important : valider la version avant son déploiement.

Le tag dev (Développement) est réservé aux versions de test ou de qualification. On l'utilise surtout pendant les tests applicatifs et lors de l'intégration de patchs de sécurité. Avant tout passage en diffusion, la version est testée sur un périmètre restreint de postes D.OS pilotes.

Il faut vérifier :

le bon déroulement du redémarrage vers W Core (récupération des chunks, complétion, remasterisation) ;
le démarrage sur la partition Windows native ;
les éléments propres à D.OS : pilotes, réseau et Wi-Fi, registre ou VHDX si applicable ;
le fonctionnement des applications métier et la bonne application des patchs.

Une fois la version validée, il suffit de changer son tag de dev vers prod. Tous les postes rattachés à ce master passent alors sur la nouvelle version et l'appliquent au prochain redémarrage vers W Core.

⚠️ Une version qui n'a pas été qualifiée sous le tag dev ne doit jamais passer en push ou en prod.

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é.
• Le tag dev sert à la fois à répliquer la version sur les WRS et à la qualifier avant son déploiement. Une fois la version validée, le passage en prod met à jour tous les postes rattachés au master au prochain redémarrage vers W Core.

9. Comparatif rapide V.OS / D.OS