Un petit tutorial rapide pour vous faire un retour d'expérience sur l'installation de Chiara PEAR Server (aka un channel PEAR perso)
Tag - déploiement
mardi, mai 12 2009
Installer son propre channel pear en local (par exemple chez un client...)
Par Olivier Hoareau le mardi, mai 12 2009, 13:44 - Trucs et astuces
samedi, avril 11 2009
Le lien symbolique : ou comment maîtriser son déploiement
Par Olivier Hoareau le samedi, avril 11 2009, 08:12 - Trucs et astuces
Vous avez déjà fait des mises en production ou mises en ligne.
Vous savez que les problèmes arrivent, que l'on peut faire des erreurs, par exemple supprimer malencontreusement un répertoire au moment du remplacement par la nouvelle version, etc...
Il existe une technique simple qui permet de simplifier les mises en production, de faciliter le retour en arrière et de gérer l'archivage : le lien symbolique.
Commentaires récents
Pour gérer le problème de la base de données, je vois deux solutions qui s'intègrent dans le script de livraison de l'appli :
* Sauvegarde complète de la base que l'on archive dans /opt/mon-appli-2.1
* Versioning de la base de données (non testé) : une base par version du code.
Mais en cas de rollback rest le problème du différentiel de données (nécessite une anticipation).
PS: A noter que les fichiers générés par l'application doivent être géré hors du "code"
J'utilise Subversion pour gérer le déploiement de mes releases en taggant celles-ci dans mon repository.
Ainsi je n'ai qu'à faire un svn export du tag correspondant à la release que je veux déployer. Idem pour revenir en arrière.
@Jean-Sébastien: concernant le problème de différentiel des données en cas de rollback, il y a peut être une piste du côté du mécanisme de réplication des bases de données. Notamment MySQL Replication Mechanism permet de répliquer toutes les requêtes effectuées à partir d'un instant (numéro de version de la base) sur une autre base de données (i.e. un autre serveur). Il suffirait alors de noter le numéro de version quand on fait une mise en production, et lorsqu'on fait un rollback d'activer le mécanisme de réplication sur un nouveau serveur/base de données et faire répliquer toutes les requêtes le numéro de révision et maintenant. A creuser (déjà testé sur une plateforme mais pas dans ce contexte).
@Ladenise: svn export n'est pas forcément "rapide", en effet si ton projet contient des milliers de fichiers, la durée du svn export peut être non négligeable (plusieurs minutes) et rendre indisponible ton application, voir pire, pendant le svn export, si tu n'as pas désactivé l'accès à l'appli il peut y avoir un comportement imprévu si certains fichiers sont exportés mais pas tous. D'autre part, comme l'indique Jean-Sébastien, il faut forcément coupler avec un autre mécanisme pour gérer le rollback de la base de données car svn export ne peut le faire (peut être avec un script côté serveur svn, car c'est possible de déclencher un script sur une action svn, mais si le serveur svn n'accède pas à la prod...). La solution svn export est une solution simple cependant.