I. Définition▲
Pour le développement d'un jeu par navigateur on utilise en général deux serveurs :
- le serveur de développement : environnement réservé à l'équipe ;
- l'environnement de production : le serveur auquel ont accès les utilisateurs finaux (vos joueurs).
On appellera mise en production, le fait de déployer sur le serveur de production une nouvelle version du logiciel, donc ici, de votre jeu. Habituellement on dit tout simplement « mettre à jour » le jeu.
II. Procédure type▲
Je vais décrire ce que je pense être le processus idéal pour réaliser une mise en production.
L'étape précédant la mise en production est celle de validation. Avant de mettre à disposition de vos utilisateurs une nouvelle version, il est indispensable de la tester et de valider son bon fonctionnement. Je ne vais pas décrire ce processus ici, on va considérer que vous êtes à peu près sûr de vos développements.
II-A. Étape 1. Packaging▲
On appellera « packaging » le fait de préparer votre mise à jour en vue de son installation/déploiement. A priori, cette nouvelle version est issue de votre environnement de développement et son objectif est donc celui de production.
Le risque c'est d'oublier quelque chose : un fichier de code modifié, un bout de script SQL, etc. Pour éviter cela, je vous conseille de noter quelque part pendant vos développements ce que vous modifiez/ajoutez.
Je vous conseille de mettre en place une structure type de fichiers que l'on appellera « package » et qui sera respectée pour chaque nouvelle version. Cette structure dépend essentiellement de votre projet et de ce que vous mettez à jour à chaque mise en production.
On peut envisager la structure de fichiers suivante :
- /v1.0/
- documentation/
- contient la documentation liée à la version : patchnotes, procédure d'installation, etc.,
- source/
- contient l'ensemble des fichiers qui ont été modifiés ou créés : code source, images, etc. Je vous conseille de respecter l'arborescence des fichiers sur le serveur,
- SQL/
- contient un ou plusieurs scripts .sql de mise à jour de la base de données pour garantir la compatibilité avec la nouvelle version ;
- documentation/
- /v1.1/
- documentation/
- source/
- SQL/
- etc.
Une fois le package prêt (le dossier « v1.0 » contenant l'ensemble des fichiers de la mise à jour), il suffira de l'archiver (winrar, winzip, gunzip ou autres) et de transférer ce dossier v1.0.rar sur la machine de production.
II-B. Étape 2. Arrêt du jeu▲
Vous avez sûrement prévu un moyen de couper rapidement l'accès à votre jeu. Si ce n'est pas le cas, faites-le. Si possible, ne coupez pas violemment l'accès (du genre coupure du serveur web générant une erreur 404), coupez la phase de connexion et affichez un message à vos joueurs comme quoi le jeu est en maintenance. Si vous connaissez la durée de la rupture de service, indiquez-la, c'est toujours plus agréable.
Je vous conseille de réaliser cette maintenance pendant les périodes d'activités creuses afin de ne pas déranger votre communauté. Pour un jeu en navigateur certains se connectent dix minutes par jour, ce serait dommage de les priver de leur dose quotidienne parce que vous patchez à 18 h…
II-C. Étape 3. Dérouler la procédure d'installation▲
Suivez votre procédure d'installation à partir du package préparé à l'étape 1. Si vous n'en avez pas, écrivez-en une.
On peut ainsi imaginer la procédure suivante :
- Sauvegarde du code source actuel sur le serveur de production (indispensable en cas de problème grave pour revenir en arrière) ;
- Sauvegarde de la base de données (je vous conseille de le faire quotidiennement) ;
- Mise à jour des fichiers à partir du dossier "/v1.0/source" du package (simple copier-coller) ;
- Mise à jour de la base de données : exécution des scripts .sql disponibles dans "/v1.0/SQL" ;
- Réalisation de quelques tests fonctionnels fondamentaux pour vérifier que tout est OK ;
- Ouverture du jeu aux joueurs ;
- Croiser les doigts.
II-D. Étape 4. Communiquer▲
Le serveur est ouvert avec votre nouvelle version, il est temps de communiquer aux joueurs ce qui a changé (patchnote de la nouvelle version) sous forme d'une news, d'un message ingame ou autre.
II-E. Étape 5. Rester alerte▲
Selon le contenu de la nouvelle version, il est bon de prévoir un peu de temps de disponibilité après la mise en production. Si c'est une version majeure que vous venez de mettre sur le serveur, vous risquez des bogues, des crashs, des blocages, et vous devrez alors être réactif et donc disponible.