Bien faire une mise en production

19/12/2008

Certains se demandent comment effectuer une mise en production le plus efficace possible sans avoir trop de soucis de différentiel entre la version en production et la version à livrer d’une application de type “script” (donc non binaire)

En fait, il existe 3 façons de faire + 1 qui est complètement folle:

  • La première est la plus folle: backup, puis écrasement
  • La seconde: rsync…
  • La troisième est un peu plus viable: utilisation de SVN ou CVS
  • La quatrième est l’utilisation d’un patch

Selon les cas, l’une de ces quatre possibilités pourra vous donner satisfaction, mais chacune des 3 premières ont un inconvénient relativement lourd:

Premier cas, on écrase tout… il faut donc être certain que la production n’a rien qui puisse manquer après mise en production d’un nouvelle version… le cas échéant, il faudra s’amuser à rapatrier les corrections vers la version de production, et bien entendu les ajouter sur votre poste de développement et/ou subversion pour ne pas avoir de mauvaises surprise par la suite…

Cette méthode a un autre inconvénient: les dates de création de fichier sont modifiés à la date de livraison… et ce pour tous les fichiers, y compris ceux qui n’ont pas été modifié. Cela peut être gênant pour des sauvegardes différentiels ou pour simplement s’informer des fichiers impacté après quelques jours…

Donc la première méthode est à éviter, on penserait que c’est la plus simple et la plus rapide, mais dans la plupart des cas on perd plus de temps qu’on en gagne.

Rsync, la seconde solution, permet de faire un peu plus de test et est très pratique si vous avez des grappes LVS à livrer en même temps. Mais encore une fois, il faut s’assurer en premier lieu que toutes correction en prod soit bien sur le SVN ou CVS en premier lieu… Bref, encore une fois on peut passer plus de temps à vérifier avant livraison que prévu. Par contre, on évitera le souci des dates de création de fichiers puisque “rsync” ne livre que les fichiers réellement différents.

La troisième méthode, subversion ou CVS, est très pratique puisque nous pouvons savoir avant mise en production si tout est bien synchronisé entre la prod et la version en développement à livrer. Inconvénient (et pas des moindres) les fichiers “.svn” ou “.cvs” son présents sur la production. Donc, on a un souci de sécurité et de place parce qu’en plus d’être un peu partout dans le projet, ces fichiers sont énormes à la longue.

En plus de cela, on risque bêtement de supprimer un répertoire (de cache, de log, pour faire de la place) et de se retrouver avec un problème au moment de la prochaine mise à jour pour la raison d’un dossier manquant…

C’est donc la quatrième méthode que je préconise: diff/patch. Voici comment je m’y prend, vous allez voir qu’en quelques minutes on peut s’affranchir d’un nombre conséquent de contrôles et surtout dans le pire des cas, très vite revenir à la version initiale.

Premier avantage de diff/patch, c’est sa vitesse de mise en place… il suffit de copier la version à livrer dans un autre répertoire, créer le patch, et l’appliquer après un dry-run.

Second avantage: renversement de livraison si besoin. En gros, vous n’aurez pas à faire une sauvegarde de votre application en production car un patch peut être joué dans les deux sens.

Troisième avantage, vous pouvez sauver vos patch pour les appliquer ou désappliquer dans l’ordre. Par exemple, vous perdez 2 livraisons à cause d’un crash serveur, il vous suffit de poser la dernière sauvegarde que vous ayez et d’y appliquer un à un les patchs sauvés.

Ou encore, vous voulez revenir à deux version précédentes sans casser les fichiers de cache, les styles et préférences… vous prenez les deux derniers patch et vous les jouez à l’envers.

Allons y… imaginons que notre application soit installé dans “/var/www/monsite”, je dois livrer une version à partir d’un export que j’ai pris de subversion.

Je dépose donc ma nouvelle version dans /var/www/nextversion puis je fais cela:

cd /var/www
#remplacez X par la date du jour, ou un numéro... bref de quoi
#se souvenir...
diff -Naur monsite nextversion > patch_X.patch

#j'entre dans le dossier à patcher maintenant
cd monsite

#je teste le patch
patch --dry-run < ../patch_X.patch

#pas d'erreur, j'applique réellement
patch < ../patch_X.patch

#je teste mon application dans mon navigateur 
#et je vois que plus rien ne fonctionne
patch -R <../patch_X.patch

Vous l’aurez compris, “diff” permet de détecter les différence “ligne à ligne” (ouvrez le fichier de patch créé, vous comprendrez vite). L’option “--dry-run” permet de tester un patch et “-R” fais un “reverse”, c’est à dire une annulation de patch (appelé aussi renversement)

Gardez maintenant ce patch quelque part (CD, bande…) et supprimez le répertoire “nextversion” et le patch du seveur.

Gardez à l’esprit qu’une livraison diff/patch est l’une des plus simple et rapide à mettre en oeuvre et vous soulagera bien des tests et vous évitera des mauvaises surprises. C’est celle que je préconise le plus souvent.

Je vous montrerai aussi plus tard que le diff/patch est très intéressant lors de phase de développement. Il faut en effet éviter de travailler sur un dépôt local directement et livrer mais travailler sur une copie et créer des patch à appliquer au dépôt avant de faire un “commit”… cela permet de s’assurer de ce que nous livrons et nous évitons par la même occasion d’envoyer à tort des fichier de configurations, de log, temporaires etc…

Ça peut vous intéresser aussi


Poste de développement PHP sous Fedora

Linux est un système parfait pour développer. Simple d’installation,...


Optimisons un peu notre Linux en limitant les accès disques

Que vous ayez un SSD ou non, je pense que ...


Titanium le développement révolutionnaire

Voilà des années que je me tue à le dire,...


OpenOffice en mode serveur

Il est parfois compliqué de créer des documents dignes de ...

Merci de m'aider à financer mes services

Si vous avez apprécié cet article, je vous serai reconnaissant de m'aider à me payer une petite bière :)

Si vous voulez en savoir plus sur l'utilisation de flattr sur mon blog, lisez cette page: Ayez pitié de moi

Commentaires

Ajouter un commentaire

Ajouter un commentaire

(*) Votre e-mail ne sera ni revendu, ni rendu public, ni utilisé pour vous proposer des mails commerciaux. Il n'est utilisé que pour vous contacter en cas de souci avec le contenu du commentaire, ou pour vous prévenir d'un nouveau commentaire si vous avez coché la case prévue à cet effet.