Olivier RICARD

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.