Olivier RICARD

Le meilleur environnement de travail est celui que vous maîtrisez sur lequel vous avez toutes vos habitudes. Ça fait plus de 10 ans que j'utilise sur les serveurs des environnements Linux mais jusqu'il y a 6 mois je n'avais pas franchi à titre personnel le pas vers un environnement de travail sous Ubuntu.  J'avais bien un dual boot avec  Windows/Debian mais c'était plus pour faire des tests. Il y avait principalement un point bloquant qui me frénait :  un éditeur pour déveloper.  Sous Windows le seul éditeur sur lequel je pouvais développer était UltraEdit. J'avais bien essayé d'autres éditeurs Eclipse, notepad++ mais soit c'était trop long à charger les fichiers soit j'avais des problèmes avec la coloration syntaxique.

Il y a 6 mois en achetant un nouveau PC portable, l'OS par défaut était WindowsVista et là j'ai pas pu mis faire. Après avoir répondu à toutes les questions Windows m'affichait déjà des erreurs ... donc je me suis décidé à passer sous Linux et plus particulièrement Ubuntu

et bonne nouvelle il y avait une version Beta d'Ultraedit sous Linux. Bien qu'elle souffrait à l'époque de quelques bugs on pouvait déjà développer dessus. En cherchant sur Internet j'ai trouvé Gedit qui avec ses plugins permet d'avoir un éditeur correct, Geany est aussi intéressant. Au final j'utilise désormais Komodo Edit avec une vingtaine d'extensions et je suis devenu plus productif. Je peux à loisir installer tous les serveurs que j'ai besoin : apache, mysql, memcache, php de manière simple. J'ai toujours sous la main une machine virtuelle sous Windows pour faire des tests sous IE :-)

Un point intéressant aussi est le multi bureau en combinaison avec Compiz. C'est quelque chose que désormais j'aurai du mal à m'en passer. Au bout de 6 mois de travail quotidien dessus je ne regrette pas mon choix. Pour l'instant les développeurs choisissent leur environnement de travail mais les prochains développeurs utiliseront de manière automatique Ubuntu ou un unix.

Ca permettra d'ajouter un critère de sélection dans le recrutement de manière simple. J'ai souvent remarqué que les personnes qui utilisaient des OS alternatifs tels que Mac ou Linux s'adaptaient plus rapidement que les personnes sous Windows.

Comme toutes les sociétés de développement, blogSpirit possède différents environnements de travail :

• L'environnement du développeur,
• L'environnement de qualité sur lequel les tests sont lancés
• L'environnement de pré-production pour valider les intégrations et développements
• Et enfin l'environnement de production

J'ai remarqué que l'environnement de pré-production est souvent mis sur une autre url que l'url de production. On fait souvent http://preprod.site.com/. Cependant cette solution a l'usage possède beaucoup de défaut :

• Une configuration de pré-production et production différentes car il faut changer les urls du site, des images
• Une configuration qui selon les intégrations des SSO peuvent ne pas fonctionner.
• Des liens qui peuvent ne pas fonctionner ou rediriger vers la production
• Un client  qui ne comprend pas pourquoi en préproduction c'était correct et lors de la mise en production des erreurs se sont imissés à cause d'erreurs de configuration.

La solution qu'on a actuellement adopté est d'avoir la pré-production sur la même url que la production. Au départ on modifiait le fichier /etc/hosts de sa machine et on accédait à la préproduction. Cette solution est envisageable lorsque vous avez très peu de sites et que vous ne devez pas passer d'un environnement à l'autre car ça nécessite à chaque fois de rouvrir son navigateur.

Afin de résoudre ce problème on a simplement utiliser un serveur sur lequel on a fait tourné un proxy en l'occurrence Squid  sur lequel on mettait une résolution DNS spécifique. Il suffit ainsi de changer les paramètres de son navigateur pour activer le proxy ou pas. Heureusement il existe des plugins de Firefox afin de simplifier cette tâche. Nous utilisons en interne le plugin Foxyproxy qui permet de basculer rapidement d'une configuration à une autre. Vous pouvez même à l'aide de règles n'activait le plugin que sur certaines urls.

On a aussi rajouter au niveau du serveur de pré-production une entête HTTP au niveau d'Apache afin de ne pas se tromper.

   SetEnv ENVIRONMENT preprod  

Avec un plugin comme firebug vous pouvez facilement voir ces entêtes qui sont rajoutées. Depuis lors on passe beaucoup moins de temps à maintenir les 2 environnements et on peut facilement basculer d'un environnement à l'autre.

Sous IE la solution est de toujours activer la préproduction si ce n'est pas votre navigateur par défaut. Sous Chrome il existe le plugin Switch HTTP Proxy mais il ne semble pas fonctionner sous Linux -(

Si vous n'avez pas un serveur dédié pour mettre le proxy vous pouvez l'installer en mettant un système chrooté. Pour faire ça vous utilisez debootstrap. Vous pouvez lire la documentation Installing Ubuntu from Unix/Linux system pour installer l'environnement. Pour Squid il n'y a rien à faire. Le proxy sera sur le port par défaut 3128.

Reste à résoudre le problème pour les clients qui doivent accéder à l'environnement de préproduction. 3 solutions sont possibles.

• Si vous avez des interlocuteurs techniques vous pouvez leur demander de modifier leur fichier hosts.
• Pour des interlocuteurs non techniques vous pouvez toujours avoir un serveur proxy extérieur authentifié et vous leur expliqué la façon de procéder. Suivant votre interlocuteur c'est pas toujours gagné et certaines grandes entreprises n'autoriseront pas sortir sur un port différent de 80 ...
• On est arrivé à la solution de déposer un cookie sur le poste du client lorsqu'il saisit une url particulière. Une fois le client avec ce cookie au niveau d'Apache on utilise une règle de rewriting pour le renvoyer vers un autre serveur. Sur ce serveur on le renvoie de nouveau sur lui-même pour accéder correctement à la préproduction. Cette façon permet ainsi de restreindre simplement l'accès à l'environnement de préproduction.

BlogSpirit a eu 5 ans cette semaine. En 5 ans beaucoup de choses ont changé. Au départ lorsque j'ai commencé à développer le logiciel qui propulse les blogs je ne savais pas si on souhaitait faire du BtoB ou du BtoC et mon expérience faisait que j'avais développé le logiciel en monobase. Un logiciel pour le site http://www.blogspirit.com et un autre pour http://www.hautetfort.com. C'était une solution qui fonctionnait très bien au départ et qui était souple. On pouvait faire évoluer les projets de manière différente. Cependant on s'est orienté rapidement vers le BtoB et les projets sont arrivés les uns derrières les autres. Réorgnaiser le code est devenu très difficile car les problèmes techniques qu'il fallait résoudre apparaissaient les uns après les autres :

• problème de charge au niveau de la base de données
• intégrer les spécificités propres à chacun de nos clients
• rendre de plus en plus personnalisable les sites
• gérer les problèmes de cache
• la méthodologie sur le déploiement des applicatifs
• problèmatique de spams sur la création de blogs ou de commentaires
• accès disques
• des spammers qui envoient des millions de requêtes pour faire tomber notre infrastructure
• des problèmes matériels on n'y échappe pas

Au final on se rend compte que le développement d'une application de blogs est rapide mais son exploitation dans le temps est un autre défi et que chaque choix technique fait a une répercution sur plusieurs années. Faire évoluer des développements en maintenant toujours un service UP nécessite d'être très rigoureux.

L'applicatif sur lequel repose les blogs est à sa 6ème version. Les 3 1ères années il y a eu 5 versions et depuis 2 ans on est à la version 6. Non que depuis 2 ans on n'a pas fait évoluer le logiciel mais la façon dont le développement est fait est différent. Au départ on essayait tous les 6 mois de mettre une nouvelle version et à chaque fois on avait des bugs à corriger dans l'urgence. Désormais on fait des mises à jour hebdomadaire et ça change tout. Tout nouveau développement nécessite de faire cohexister l'ancien code et le nouveau code et l'ajout de nouvelles fonctionnalités doit pouvoir être activé par client. Ca impose de coder un peu plus mais c'est beaucoup plus stable à la fin.

Pour gérer les différents clients on se repose sur le nom d'host du client. Le client a pour url www.blogspirit.com alors la 1ère chose que le  script d'initialisation fait est de charger le fichier www.blogspirit.com.php. Ainsi on sépare facilement tous les clients. 

D'autre part un autre défi a été de concevoir des applications simples et autonomes. Au départ la gestion du portail, des blogs et de l'administration pour nos clients grands comptes était un seul applicatif. Puis au fur et à mesure des nouvelles fonctionnalités il était de plus en plus difficile de faire des mises à jour car telle partie était terminée et pas l'autre. Ca nous freinait dans nos mises à jour. Il a fallu concevoir des applications autonomes qui puissent être mises à jour de manière simple. Un application pour les blogs, pour le portail, pour la superadministration et une dizaine d'autres plus petites afin d'arriver à être agile.

En devenant plus agile on arrive à developper plus et mieux. Depuis un an blogSpirit a sorti un nouveau produit Talkspirit. Ce produit s'est appuyé sur une partie de l'expérience acquise par nos précédents développements. Au bout d'un an on est en train de sortir une nouvelle version dont les possibilités seront beaucoup plus importantes que maintenant et qui je l'espère ira beaucoup plus loin.

5 ans ça paraît long et court blogSpirit au départ société de blogs et devenu désormais un édieur de services en ligne qui peut voir l'avenir de manière sereine.