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.

Tout d’abord, petit point sur les origines et la situation de mon projet.

J’ai commencé par développer un site web pour un besoin personnel. Après les retours de certaines personnes qui trouvaient les fonctionnalités intéressantes et qui se disaient même prêtes à payer (c’est là que j’ai du avoir le déclic!), je me suis dit que je pourrais peut-être en faire quelque chose…

Maintenant que j’en suis à la phase de refonte plus sérieuse du site en vue de son automatisation, je suis confronté au dilemne suivant : PHP ou Java / J2EE?

Naturellement au début, dans l’optique d’un simple et modeste site, j’ai opté pour le package PHP + MySQL, facile, simple… J’ai toujours utilisé ces technos lorsque j’ai développé d’autres petits site web.

Mais maintenant que je me lance dans un projet plus conséquent et plus long terme, je me suis dis “Et pourquoi pas faire ça en Java / J2EE?”

Ce sont des technologies que j’utilise quotidiennement pour mon boulot depuis 5 ans maintenant, avec lesquels je me sens donc beaucoup plus à l’aise que dans l’univers LAMP (Linux, Apache, MySQL, PHP). Selon moi, c’est un environnement beaucoup plus professionnel, permettant le développement d’applications beaucoup plus conséquentes. Et coder en Java avec un IDE (environnement de développement) comme Eclipse, c’est vraiment plus facile qu’en PHP.

Donc il est clair que mon coeur penche plus que fortement du côté Java/J2EE.

MAIS, car bien sûr il y a un plusieurs “mais”. Si jusqu’ici je n’ai fait que des sites en PHP, c’est que les offres d’hébergement de sites en J2EE sont quasi-inexistantes. En France, je n’ai trouvé qu’althosting, qui offre un pack à 6€ HT. Mais mes enquêtes pour avoir l’avis de clients m’ont fait comprendre que la prise en main était limitée, à priori pas moyen par exemple de redéployer soi-même son application. Mon e-mail auprès du service commercial est resté sans réponse…

L’autre solution serait de prendre un serveur virtuel (à partir de 12€ TTC sur 1and1), mais ça commence à revenir plus cher pour un projet qui ne garantie pour l’instant aucun revenu (on y reviendra plus tard).

De plus, l’existant de ce projet est en PHP, et tout recoder prendrait tout de même un certain temps. Même si je pense que je pourrais rattraper ce temps sur le long terme, notamment avec des outils comme GWT.

S’ajoute à cela le fait que j’ai fait tomber certaines limitations (qui ne tenaient qu’à moi) en faisant quelques découvertes intéressantes.

Ma mauvaise appréciation de la solution PHP venait en partie du serveur de base de données qui lui ai systématiquement associé (dans les offres d’hébergement, car il peut fonctionner avec toutes bases de données) MySQL. Car je n’avais jamais prêté attention à l’intérêt des moteurs de stockage MyIsam et InnoDB. Le premier étant celui par défaut, je n’avais jamais tenté de changé ça, ne sachant ce que cela allait engendré.

Et bien InnoDB, c’est mieux! Et c’est peut-être la clé d’un début de réconciliation avec PHP + MySQL. En effet, contrairement à MyIsam, InnoDB permet de définir des contraintes de clés étrangères, ce qui garantie une meilleure intégrité des informations. Mais ce n’est pas tout, il permet aussi l’utilisation de transactions!

De quoi rendre la solution PHP un peu plus convenable dans un contexte professionnel. Il me faut encore trouver un système de mise en cache, qui existe mais que je ne connais pas encore, et ce sera pas mal.

J’ai donc décidé de rester sur PHP + MySQL, histoire d’avancer tout de suite, et en fonction de l’évolution de l’application une fois en place, j’envisagerais peut-être la migration vers J2EE.

Ca me permet aussi de rester pluri-disciplinaire plutôt que d’être un intégriste du J2EE!