mercredi 11 janvier 2012

Mises en production

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 reservé à 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.

Procédure type

Je vais décrire ce que je pense être le process 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 à disponibilité 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 process ici, on va considérer que vous êtes à peu près sûr de vos développements.

É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, ... pour 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
  • /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 autre) et de transférer ce dossier v1.0.rar sur la machine de production.

Étape 2. Arrêt du jeu

Vous avez surement 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 10 minutes par jour, ce serait dommage de les priver de leur dose quotidienne parce que vous patchez à 18h...

É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 n'avez pas, écrivez en une. 

On peut ainsi imaginer la procédure suivante :
  1. Sauvegarde du code source actuel sur le serveur de production (indispensable en cas de problème grave pour revenir en arrière)
  2. Sauvegarde de la base de données (je vous conseille de le faire quotidiennement)
  3. Mise à jour des fichiers à partir du dossier "/v1.0/source" du package (simple copier coller)
  4. Mise à jour de la base de données : exécution des scripts .sql disponibles dans "/v1.0/SQL"
  5. Réalisation de quelques tests fonctionnels fondamentaux pour vérifier que tout est ok
  6. Ouverture du jeu aux joueurs
  7. Croiser les doigts
É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.

Étape 5. Restez 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 bugs, des crashs, des blocages, et vous devrez alors être réactif et donc disponible.

7 commentaires:

  1. Bonjour,
    Pour un jeu par navigateur, je me demandais justement couper l'accès au jeu pour une mise à jour ?
    Comment faire ça proprement et tout ça ?
    Merci :)

    RépondreSupprimer
  2. Bonjour,

    On pourrait tout simplement "couper" le serveur web, dans ce cas les utilisateurs ont une belle erreur http (pas bien).

    Ce qu'il faut faire c'est prévoir un système pour faire ça "proprement". Il y a plusieurs possibilités techniques, le but étant de laisser le site accessible en indiquant qu'une maintenance est en cours. Les joueurs pourront toujours accéder au forum etc.

    Le plus simple je pense c'est d'avoir un petit fichier de conf en .php contenant la connexion à la base de données (le mysql_connect) et que l'on appelle dans chaque autre page .php via un include au début.

    Pendant la mise à jour il suffira donc de remplacer ce fichier .php de connexion par un autre prévu pour la maintenance contenant :
    - un session destroy pour ceux qui sont déjà connectés
    - un refus de connexion à la base de données
    - un message indiquant le mode maintenance pour informer les joueurs

    Après la maintenance il faudra juste remettre le fichier initial sur le serveur.

    Il y a évidemment plusieurs moyens techniques mais celui là permet de mettre fin aux sessions déjà en cours en plus d'en interdire de nouvelles.

    J'espère que la réponse est claire ;)

    RépondreSupprimer
  3. Par exemple, si mon fichier de connexion à la bdd est "bdd_connexion.php", je crée un du même nom et au lieu d'avoir la connexion à la bdd, je met une session destroy, (marche même en présence de cookies ?), et une redirection en header vers une page expliquant la maintenance ?
    Merci de votre réponse :)

    RépondreSupprimer
    Réponses
    1. A partir du moment où il n'y a plus de mysql_connect dans le bdd_connexion, le joueur ne pourra pas se connecter à la base de données et ne pourra donc pas jouer (enfin après ça dépend de l'implémentation du jeu mais si c'est un jeu via navigateur ça devrait être le cas). Pour le session_destroy il y a plus de détails ici :
      http://php.net/manual/fr/function.session-destroy.php

      Supprimer
  4. On peut faire ça encore un peu plus "propre" en créant une constante d'état du jeu en base de données.
    Si l'état du jeu est placé en maintenance (via une interface d'administration par exemple), on rend les connexions, via le module de connexion au jeu, impossibles et on exécute un session_destroy() dans chaque appel au script de connexion à la BDD et une redirection vers la page de maintenance

    Ainsi, plus besoin de modifier le script à chaque fois, le simple changement de l'état du jeu coupe les accès au jeu.

    On peut imaginer aller plus loin en demandant à l'administrateur de donner une raison à chaque mise en maintenance de l'état du jeu, raison qui ira compléter la page de maintenance pour que les joueurs sachent tout de ce qui se trame.

    RépondreSupprimer
    Réponses
    1. C'est vrai que l'on peut faire comme ça mais ça sous-entend que la base de données est toujours accessible donc cela ne fonctionnera pas si tu as besoin de remonter une base, un dump ou je ne sais quelle action de maintenance sur l'intégrité de la base.

      En tout cas c'est peut-être plus "pratique" ainsi c'est vrai.

      Supprimer
    2. C'est juste, dans le cas d'une mise à jour portant sur l'intégrité de la base, il faut passer par une autre solution, plus "manuelle".

      Ma solution est donc pertinente essentiellement pour les mise à jours de scripts, ou les maintenances mineurs de la base de données.

      Pour pallier à ce cas de figure, on peut peut être imaginer stocker les informations d'états du jeu dans un fichier text (ou XML) qu'on irait lire à la place de la base de données. Et l'interface d'administration mettrait à jour ce fichier et non pas la base. Ainsi, la solution est fonctionnelle, même pour une mise à jour touchant à l'intégrité de la base de données.

      Supprimer