J'ai deux processus différents à expliquer ici : le processus de patch majeur, qui apporte du nouveau contenu et des lots de corrections, et le processus de patch mineur, utilisé pour apporter rapidement des petites corrections aux versions du moment. A la fin, j'illustre la théorie avec un exemple concret : le patch de la semaine dernière.
A] Processus de patch majeur
Diagramme 1 : processus de patch majeur
Comme vous pouvez le constater, il y a trois phases :
- Le développement
- Les tests (tests en interne et sur lATS)
- Le patch public
1) Le Développement
La première phase, le développement, inclut le travail de différentes équipes : les codeurs, les level designers (concepteurs de niveau), les artistes 3D, etc. Ils ont différentes techniques de travail, chacune d'elles adaptée au travail qu'ils effectuent. Par exemple, les codeurs emploient un sous-ensemble adapté appelé Extreme Programming (voir en particulier Planning Game, Small Releases, Simple Design et Design Improvement concernant le sujet abordé ici). Ils reçoivent un ensemble de travaux correspondant approximativement à deux semaines de travail : l'itération.
A la fin de certaines itérations des codeurs, les changements au niveau du code et le travail de toutes les équipes sont marqués pour créer une « branche » : cela correspond en fait à un chiffre de version interne attribué au code et aux contenus courants. Sa forme est X_Y_Z, où X est le chiffre de version principale (actuellement 1), Y le chiffre du chapitre (actuellement 2), Z le nombre de branches depuis le dernier chapitre (actuellement 7). Les notes apportées par les développeurs quand ils modifient le code sont compilées pour garder des traces des changements de la branche courante : les notes de branche ; elles correspondent en fait à une version technique des notes de patch.
2) Les tests
a) Test simple de régression
La première chose que fait l'équipe de testeurs quand ils reçoivent la nouvelle version de branche à tester est de réaliser « un test basique de régression ». Pendant deux jours, les testeurs effectuent une série de contrôles simples, pour être sûrs que les systèmes généraux du jeu fonctionnent correctement, puisquun logiciel aussi complexe qu'un MMORPG est enclin à leffet Papillon, selon lequel des petits changements apportés sur un système dynamique peuvent avoir de grandes répercussions.
Quand un problème important est découvert à ce stade, nous travaillons sur une correction et la version est testée à nouveau avant de commencer l'étape suivante. Ceci peut naturellement entraîner des retards, qui sont cependant nécessaires pour éviter de trop modifier la version ATS.
b) Tests internes approfondis et ATS
Puis, quand tout fonctionne bien, un patch est créé et appliqué à lATS. Les testeurs en interne continuent leurs tests, passant en revue une liste de contrôles plus profonds à la fois des mécanismes existants et nouveaux du jeu, basés sur des listes de contrôle standards et les notes de branche.
Alors que les tests sont effectués en interne et sur l'ATS, des bugs peuvent être détectés et d'autres problèmes peuvent survenir. Il y a trois cas possible ici pour chaque problème : il peut être corrigé immédiatement si le problème est bénin et ce rapidement et de façon sûre ; la fonctionnalité en question peut être désactivée dans la branche courante et être remise au prochain patch ; ou si les conséquences des changements exigés sont trop grandes, le patch est retardé. Le délai habituel est de deux semaines ici, mais, encore une fois, il peut être prolongé en fonction des tests.
Quand tout fonctionne correctement, nous passons à létape finale (et la plus stressante) : le patch des serveurs publics.
3) Patch des serveurs publics
Ici, la première chose est de vous annoncer le patch (sur les forums et maintenant aussi dans les news). Puis le patch et les notes sont préparées et en conclusion, à la date et à l'heure annoncées, les serveurs sont fermés : le patch est appliqué.
Pendant que les serveurs sont patchés, l'équipe dadministration système profite de larrêt des serveurs pour mettre à jour les serveurs Linux et exécuter un archivage complet des sauvegardes du jeu.
Quand les serveurs sont patchés et prêts, les équipes de CSRs les vérifient minutieusement et... tada ! Vous pouvez enfin apprécier les codes durement travaillés pour vous.
B] Processus de patch mineur
Diagramme 2 : processus de patch ninja
Comme chaque joueur de MMORPG sait, il n'y a pas de jeu MMO parfait, ou même de patch parfait. Il faut donc disposer d'un processus réactif pour traiter des problèmes urgents sur les serveurs publics. En effet vous ne voudriez pas que nous employions le processus de patch itération pour cela, vous devriez alors attendre quelques semaines pour avoir une correction dans le jeu ! : -)
Nous en avons donc un qui peut être décrit comme « le moyen le plus sûr pour la correction la plus rapide ». Quand une correction doit être apportée en urgence, il y a un équilibre difficile entre vitesse et sûreté à respecter, car la sûreté exige des tests et prend du temps. Il n'y a donc pas de délais fixes ici car cela dépend vraiment de ce qui est corrigé.
Les jours suivant le lancement du jeu, nous avons eu un processus réactif à lextrême (que nous avons appelé en interne le « patch ninja »
). Certains développeurs recevaient un appel au milieu de la nuit, ils devaient alors ramper hors du lit, corriger un problème et lancer le patch dans un délai de 10 ou 20 minutes ! Mais comme décrit dans les News des devs, le manque de temps pour les développer et les tester n'était pas sans conséquences pour le jeu à long terme. Même la correction la plus simple doit être testée avant de pouvoir être lâchée sur un serveur public. C'est pourquoi nous avons cessé de développer des patchs ninja et avons adopté le procédé de patch mineur.Etape par étape, le processus de patch mineur est le suivant :
- étape 1 : une décision est prise de corriger un problème en utilisant le procédé de patch mineur
- étape 2 : la correction est développée
- étape 3 : les codeurs et les testeurs ont monté une procédure de test court pour vérifier la correction et trouver déventuels effets secondaires
- étape 4 : la correction est testée jusqu'à ce que tout le monde en soit satisfait et que cela fonctionne correctement, les délais étant importants, les tests ne sont donc pas aussi complets qu'ils le seraient pour un patch majeur.
- étape 5 : le patch est implémenté sur les serveurs publics et des annonces sont faites.
C] Exemple du patch de la semaine dernière
Pour illustrer la théorie, rien de mieux que du concret : voici en détail les patchs des dernières semaines.
(53, 55, 56).
1) Patch 53 - processus de patch majeur
- 18/02 : Les codeurs ont fini litération.
- 21/02 : Une branche est créée ; elle porte en interne la référence 1_2_7.
- 22/02 au 25/02 : un rapide test de régression est fait par les testeurs en interne.
- 25/02 : le feu vert est donné après des tests réussis et la branche 1_2_7 est appliquée à lATS.
- 03/03 : des problèmes au niveau des textes de nouveaux rites sont découverts dans le jeu ; ils sont donc reportés.
- 07/03 : un problème avec la commande /afk est découvert, la commande est donc désactivée.
- 09/03 : aucun autre problème ne survient, le feu vert est donné pour limplémentation du patch. Le patch se voit attribuer le numéro 53 et il vous est immédiatement annoncé.
- 10/03 : la note de patch est préparée et postée pendant que les serveurs sont arrêtés, comme dhabitude, pour vous donner de la lecture pendant que vous ne pouvez pas jouer Le patch est enfin appliqué.
2) Patchs 55 et 56 - processus de patch mineur
Deux problèmes ont été corrigés dans les patchs suivants. Il y avait un problème connu au niveau de la localisation du nom des montures dans certains endroits du jeu. C'était un problème de traduction qui a été corrigé quelques temps avant limplémentation du patch. Cependant la correction n'avait pas encore reçu le feu vert des testeurs et nous avons donc préféré ne pas retarder le patch principal. La correction a seulement exigé un patch du client qui a été appliqué plus tard le même jour (le 10 mars) sans interruption des serveurs. Quand des nouveaux joueurs sont entrés dans le jeu le patch a été appliqué alors que les autres restaient avec le 53 jusqu'à déconnexion.
Après le patch, nous avons découvert un autre problème au niveau des outils d'artisanat affectant quelques joueurs. Puisque ce problème n'était pas insignifiant et que nous voulions nous assurer que la correction soit passée par un cycle approprié de tests, l'équipe de support clientèle a réagi immédiatement, avec tout le personnel de support clientèle en offrant des outils de remplacement gratuitement. La correction a été introduite dans un patch mineur avec d'autres corrections, patch qui a eu lieu hier (patch 56).
--
Xavier.