Patrice Ferlet
Patrice Ferlet
Créateur de ce blog.
Publié le déc. 19, 2008 Temps de lecture: 5 min

Me suivre sur Mastodon

Bien faire une mise en production

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…

comments powered by Disqus