Pourquoi rester chez un hébergeur lorsque l’un de ses concurrents vous propose une machine deux fois plus puissante pour le même prix ?
Depuis le début de la semaine, ce nouveau serveur de production (nommé laetitia) est arrivé et j’ai fait progressivement les migrations de mes divers sites depuis l’ancien serveur (nommé agnès).

L’arrivée de ce nouveau serveur marque donc la fin de ma migration vers mon nouvel environnement de développement. Après l’arrivée du serveur de développement, norris il y a un mois, ce changement de serveur de production me permet d’utiliser les données du serveur svn de norris en production.
Désolé mais je n’ai pas de photo de laetitia.

CakePHP fournit de base quelques méthodes permettant de développer des applications dans le but de les exécuter avec PHP-cli, c’est à dire de les exécuter comme des scripts shell au lieu de passer par l’interface graphique.

Je ne propose pas ici un tutoriel permettant de développer ce genre de scripts. Il en existe déjà un résumant assez bien la chose sur cakebaker (en).

Après avoir développé une application, nous avons plusieurs tâches qui sont exécutées dans le script shell principal.

Cependant il peut être utile, pour diverses raisons de tests, d’analyses de bugs voir statistiques, d’exécuter les mêmes méthodes présentes dans nos tasks mais via une page web.

Il serait fortement bête de devoir faire un copier/coller de notre méthode et de la remettre dans un contrôleur. Cela ne serait pas vraiment en concordance avec le mojo du framework (« think twice, code once« ).

Supposons donc que dans votre contrôleur « admin », vous désiriez utiliser la méthode « makeTest » de la tâche « test ».
Créez une nouvelle action dans votre contrôleur.

Dans celle-ci, placez les lignes suivantes :

include(APP.'console/libs/shell.php');
vendor('shells/tasks/test');

Vous avez ici inclu dans votre action les fichiers nécessaires l’instanciation de votre tâche.

Le premier fichier contient la classe parente à celle que doit avoir votre tâche. La seconde contient votre tâche (remplacer « test » par le nom de votre tâche).

$tache = $test->makeTest();

Maintenant initialisons notre tâche :

$test = new TestTask();

Et exécutons la méthode que nous désirons pour notre tâche.

$tache = $text->makeTest();

Vous n’avez maintenant plus qu’à effectuer l’action que vous désirez avec les données que votre méthode vous renvoie.

Irish Coffee

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.

J’ai, depuis hier soir, un nouveau colocataire. Celui-ci se nomme Norris. Il est un peu timide. Mais il me laisse poster une photo de lui ci-dessous.

Donc, qui est Norris et que fait-il dans la vie ? Norris est un beau Shuttle K45 couplé à un processeur Intel Core 2 Duo 2,4Ghz et une barrette de 1Go de RAM.

La vie de Norris est plutôt assez cool pour l’instant puisqu’il sert de serveur de sauvegarde (automatique pour les données de mes sites et manuelle pour mes photos notemment). Cependant son potentiel va bientot décupler puisqu’il va servir de … serveur de développement. J’avai déjà parlé dans un autre billet de la refonte de mon environnement de développement. Norris étant arrivé, cette refonte peut se produire !

Comment cela va se passer ? Norris va accueillir (accueille déjà. Mais il faut faire quelques migrations encore) un serveur SVN. Chacun de mes sites web sera un répository SVN sur Norris.

Lorsqu’une nouvelle fonctionnalité sera développée, la procédure sera la suivante :

  • La fonctionnalité est développée et testée sur la machine locale
  • Le développeur (moi) fait un commit de la version présente sur sa machine vers le serveur de développement
  • Le développeur et toute personne autorisée à cela peut tester l’application en cours de développement, afin de supprimer tous les bugs existants notemment
  • Lorsque l’application est prète, un svn update est fait depuis le serveur de production. La version de développement passe en production :-)

Ainsi en placant une interface similaire à l’interface de développement, on évite des bugs de mise en production qui pourraient arriver pour des raisons X ou Y. Cela faisait un certain temps que je voulais appliquer ce genre de règle à mes développement personnels. C’est maintenant chose faite :-)

P.S. : si vous aimez pas le nom Norris (en référence à Chuck Norris, l’Homme qui avait déjà tout vécu avant que toute chose n’existe), faut raler auprès de TOMHTML. C’est son idée.

 
Fork me on GitHub