Pour l’instant du moins.

Comme vous le savez peut-être déjà, Zend a publié hier la première beta publique de son Zend Server.
L’idée est en soi sympa. Le produit, qui a des versions Windows, Mac et Linux, inclut :

  • Apache (ou le support de IIS si vous êtes un grand fou sous windows)
  • PHP
  • Zend Framework
  • MySQL (optionnel)

Alors après un petit test rapide, le produit est sympa.
L’interface web d’administration du serveur est toute jolie, ergonomique toussa (même si sans licence on ne peut pas voir grand chose).
A savoir qu’elle a été développée avec le Zend Framework et Dojo.

Mais cette interface ne permet de gérer que PHP, les extensions installées et les logiciels Zend installés.
C’est bien maigre lorsque l’on sait que pour faire fonctionner PHP il faut aussi un Apache correctement configuré. Du coup pour configurer son Apache, il faut passer par le fichier de configuration normal.

Ainsi en « natif », pas de multi projets. Vous placez votre application développée avec Zend à la base du DocumentRoot et puis c’est tout.
Quand j’ai vu l’interface, j’ai tout de suite pensé à une génération automatique de virtualhosts moi (je me suis même pris à rêver de modification automatique du fichier hosts, c’est dire).

Pour finir le Apache utilisé est celui disponible chez apache.org, sans aucune implémentation native dans le Zend Server.
Du coup vous avez (sous windows) deux icônes, une pour le ZS et une pour Apache. Quand des logiciels comme WAMP sont capables de monitorer seuls le serveur http ainsi que le serveur mysql, c’est plutôt dommage.

Du coup je me tâte pour regarder si ce serveur est intégrable à wamp justement. Même si l’intérêt en est finalement assez faible puisque ce dernier permet de gérer les extensions php installées de manière parfaitement correcte.

Du coup je vire le Zend Server et je reste avec wamp pour l’instant. On verra d’ici un an ou deux si la version stable intègre une gestion plus avancée des serveurs http et mysql.

P.S. : Aujourd’hui, O2Sources vient de sortir son premier projet Open Source, développé avec Zend Framework justement.

Si vous utiliser Phusion Passenger (ou mod_rails), vous savez déjà que votre application est démarrée une première fois lors du premier chargement de page.
Puis que tous les autres chargements se baseront sur cette application déjà démarrée, jusqu’à ce que vous la redémarriez.
En gros, si vous modifiez un fichier dans votre application, la modification ne sera pas prise en compte jusqu’à ce que l’application ne soit redémarrée.
Cela permet d’accélérer considérablement le chargement des pages en production.

Pour redémarrer votre application de manière exceptionnelle, il vous suffit de créer le fichier tmp/restart.txt
Après le rechargement de l’application, le fichier sera automatiquement supprimé.

Mais dans des environnements de développement ou de test, ce n’est pas forcément adapté et c’est plutôt lourd de redémarrer l’application à chaque fois.

C’est pourquoi une nouvelle feature a été ajoutée dans le git de passenger il y a quelques jours de cela.
En créant le fichier tmp/always_restart.txt.
Ce document, si il existe, force le redémarrage de l’application. Cependant, contrairement à restart.txt, il n’est pas supprimé après le redémarrage de celle-ci. Votre application sera donc redémarrée à chaque chargement de page.

Bien évidemment, ceci n’est pas à utiliser dans des environnements de production (sauf si vous cherchez volontairement à fortement ralentir votre application).
Le commit en question.La fonctionnalité arrivera probablement dans la branche stable lors de la prochaine release.

Je vous ai déjà parlé de mon nouveau collocataire, Norris.  En voulant configurer celui-ci, je me suis heurté à une légère problématique

Comment puis-je tester une application située dans mon repository SVN ?

Tout d’abord, je me suis dit "pour faire propre, je crée un repository par projet". Jusque la, facile :-)

Ensuite, Jean-Sebastien (il ne fera pas de billet là-dessus alors que cela serait une excellente manière pour lui de remplir son blog. Qu’a cela ne tienne) m’a expliqué comment il a fait sur le dépot de projets interne à O2Sources. Le principe est au final assez simple :

SVN, utilisé comme un module Apache, permet de visualiser un dépot et d’y faire des commit via le protocole DAV (à tous les étudiants de ma promo : oui je sais, je suis passé du côté obscur de la force. Mais je n’avais pas le choix).

A partir de la, tout devient très simple ! Il existe en effet davfs, qui permet de faire un mount sur une adresse DAV. Y’a plus qu’à faire un mount sur notre chemin SVN ! Je fait donc ce mount vers le chemin ou pointe le dossier parent à tous mes repository. Oui, j’ai pas envie de faire un nouveau mount à chaque fois que je fait un nouveau repository. Ca serait un peu chiant …

Et la, "connection refused". Quelle déception ! Surtout lorsque je tente sur un autre repository SVN et que je constate que cela fonctionne. Après quelques recherches, j’ai finalement tout de même réussi à monter ma partition. En effet, en cherchant à monter le dossier parent à mon repository, qui me semblait être un dossier subversion supportant DAV puisqu’il s’affichait de la même manière que les autres dans mon visualisateur, je ne montais en fait absolument pas un dossier DAV, mais un dossier tout court …

Il fallait donc que je monte directement mon repository. Pas moyen de monter le dossier parent … Ô rage, Ô désespoir. Mais c’est la que viennent faire leur apparition les branches. Pourquoi ne pas utiliser un seul repository pour tous mes projets et créer une nouvelle branche pour chaque projet :-)

Evidemment maintenant cela fonctionne. Je peux monter mon repostory "sites", dans lequel sont situés de multiples projets tels que "refstats", "kazhar", … Et comme cette parition dav contient des fichiers bruts, je peux y placer une virtualhost Apache et donc voir les fichiers présents dans mon repository subversion comme s’ils étaient en dur sur ma machine.

Pour finir, voici ce que j’ai mis dans mon fichier /etc/fstab (afin de monter la partition automatiquement au démarrage de la machine)

http://localhost/sites         /svn/sites     davfs   user,auto,ro    0       0

J’ai créé un virtualhost pour svn sur localhost afin de ne pas avoir à m’embeter à créer une identification pour la machine locale. Un identifiant et un mot de passe sont tout de même demandés au démarrage. Il suffit cependant de taper sur "entrée" pour passer à la suite.

 
Fork me on GitHub