Vu qu’il s’agit d’un hébergement mutualisé, il n’est pas possible de modifier directement la configuration serveur de Php. Il est possible de faire la modification dans le code des pages Php, mais je préfère  différencier les aspects métiers du code et la configuration. La dernière solution est de faire la modification dans un fichier php.ini.

Contenu du fichier php.ini :
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off

Un fichier?

Oui et non : un fichier php.ini par répertoire contenant des fichiers Php.

Ce qui est un peu lourd et c’est là qu’intervient le script de mise en prod. C’est lui qui va se charger de recopier le fichier php.ini dans tous les répertoires concernés dans l’archive à distribuer. Pour faire cette opération on utilise l’instruction d’itération for. Elle n’est pas par défaut dans Ant, il faut ajouter la librairie ant-contrib (pour ma part, la version 1.0beta3 ne fonctionne pas, j’ai gardé la 0.6). Et il n’y a plus qu’à boucler sur les dossiers en excluant ceux qui n’en n’ont pas besoin comme les répertoires d’images, de css, …
<for param="folder">
 <path>
  <dirset dir="${DIST_DIR}">
   <include name="**" />
   <exclude name="*/css/**" />
   <exclude name="*/images/**" />
   <exclude name="*/js/**" />
  </dirset>
 </path>
 <sequential>
  <copy file="./php.ini" todir="@{folder}" />
 </sequential>
</for>
Plus d’infos sur le comportement des magic quotes chez PhpFrance.

Rien de bien compliqué avec Ant, on va juste ajouter quelques instructions à la target deploy_end, qui rétablit l’accès au site une fois la mise à jour de la base (manuelle…) effectuée.

<tstamp>
  <format property="tag_date" pattern="yyyy-MM-dd" />
</tstamp>
<echo message="Tag des repository CVS : prod_${tag_date}" />
<cvspass cvsroot="${CVSROOT}" password="${CVS_PWD}" passfile="./.cvspass" />
<cvs cvsRoot="${CVSROOT}"
  command="rtag -R prod_${tag_date} ${CVS_MODULE}"
  failonerror="false" quiet="true" reallyquiet="true" />
<cvs cvsRoot="${CVSROOT}"
  command="rtag -R prod_${tag_date} ${CVS_MODULE_ENV}"
  failonerror="false" quiet="true" reallyquiet="true" />

La directive tstamp permet d’obtenir la date courante au format spécifié par l’attribut pattern et la placer dans une propriété tag_date utilisable ensuite, comme ici pour le nom du tag.

La directive cvs exécute la “command” spécifié : rtag -R prod_${tag_date} ${CVS_MODULE}. Ce qui veut dire en français : place le tag prod_2010-02-10 sur le projet nommé par la propriété CVS_MODULE. Il y aura donc autant de commande cvs que de projets à tagguer.

J’ai choisi de faire ce script avec Ant, tout simplement parce que je le connais pour l’avoir utilisé dans mes jobs précédents et qu’il me convient parfaitement. Il s’intègre de plus très bien dans Eclipse, que j’utilise pour développer, à condition d’avoir installé le plugin adéquat, soit l’environnement JDT (Java Development Tools), si on a choisi comme moi, une installation Eclipse PDT (Php Development Tools) qui n’inclue pas d’utilitaires pour Java. Car Ant tourne à l’aide de Java.

Que fait ce script?

Avec ce script, j’ai voulu automatiser 3 opérations : la sauvegarde, la construction du projet à déployer et le déploiement.

La sauvegarde

Dans cette “target”, je fais simplement un export des fichiers sources sur le serveur de production. Etant contraint par mon type d’hébergement, je ne peux que passer par une tâche ftp pour les récupérer. Ensuite, je créé une archive compressée à la date du jour, puis je supprime les fichiers importés.

Pour les mêmes contraintes, il n’est pas possible de se connecter à la base de données. On ne peut donc pas automatiser un dump de la base. Il faut donc le faire à la main… Ce n’est ni long, ni compliqué à faire, c’est juste qu’il ne faut pas l’oublier.

Cette étape peut être relativement longue en fonction du nombre de fichiers et de leur taille. Mais on peut le faire un peu à l’avance.

La construction du projet

Cette étape consiste à générer un ensemble de fichiers destinés à être copiés sur le serveur. Ayant plusieurs projets CVS, je récupère le projet avec les sources en environnement de dev, que je surcharge avec celui contenant les fichiers de l’environnement de production.

Le déploiement

Cette étape s’effectue en 2 fois, là aussi pour cause d’impossibilité de connexion à la base de données via le script.

Dans un premier temps, on copie un fichier .htaccess, permettant de renvoyer toutes les requêtes HTTP vers une page d’attente, et on copie les fichiers construits à l’étape précédente (sauf le .htaccess) sur le serveur de production.

Ensuite, au besoin, il faut faire la mise à jour de la base de données à la main.

Dans un second temps, on copie le .htaccess de l’environnement de production qui n’a pas été copié précédemment pour rétablir l’accès au site.

Y’a surement de meilleures méthodes, mais celle-ci fonctionne pour moi pour l’instant.