Ca y est !!!
La nouvelle version de Freelance Business club est en ligne.
Je suis très heureux de vous proposer notre V1, au programme vous trouverez : notre nouvelle charte graphique, un système de navigation optimisé, un moteur de recherche métier performant et bien d’autres choses… Je développerai plus en détail dans un prochain post les nombreux bénéfices que vous apporte la nouvelle version de FBC,

Mais aujourd’hui je voulais revenir sur le premier succès de cette V1 :

la mise en production

.

C’est une étape critique, délicate et stressante, redoutée par toutes les équipes techniques.
Nous avons réussi à la passer en douceur, sans rencontrer de difficultés majeures, en un peu moins de 4 heures et les indicateurs sont au beau fixe puisque à ce jour, nous constatons :

• A peine 5 bugs de prod,
• Des performances irréprochables,
• Une belle progression du nombre des nouveaux membres,
• Une augmentation significative du trafic entrant et de l’activité sur le site.

Je voudrais partager avec vous sur comment nous avons procédé pour mettre en ligne la version, quelles sont mes conclusions et les bests pratices que je recommande et enfin les axes d’amélioration.

Tout d’abord un petit retour sur le contexte.

Une approche Big Bang

La V1 est trop différente du prototype (ancienne version), notamment au niveau de l’architecture du code.Nous décidons tout de suite, début des développements, d’abandonner le svn (notre outil de versionning) du proto et de repartir from scratch avec un nouveau svn pour la V1.
On part donc sur une migration en ‘big bang’ pour le passage du proto à la V1. On conservera notre modèle de BDD mais on remplacera l’ensemble du code, nous n’utiliserons donc pas le mécanisme svn de branches (sur la prochaine version j’espère !!!).

Avec ces précisions voici comment nous avons procédé.

La démarche

1. Mise en travaux du site, eh oui pas encore de haute disponibilité chez FBC ,
2. Sauvegarde du code de l’ancienne version, de la base de données et des fichiers de données utilisateur (les photos de profil par exemple). Il va sans dire, qu’il est très important de garder l’intégralité des informations (code, BD, data) pour pouvoir en cas d’urgence revenir à l’ancienne version du site,
3. Réinstallation du serveur LAMP. Nous voulions passer sur la dernière version LTS d’Ubuntu. De plus il est important pour nous d’optimiser la configuration de chacun de nos serveurs. Pour comprendre les raisons du choix de notre architecture je vous recommande l’excellent article de Thibauld : Web application implementation step 1: choose your weapons!
4. Configuration d’apache2, de mysql5 et de php5
5. Mise en place du code, création et initialisation de la base de donnée, mise en place des fichiers de données utilisateurs
6. Quelques petites modifications au niveau de nos fichiers de configuration et d’initialisation

Et hop le site est prêt !
Reste encore une petite heure de tests. On passe en revue l’ensemble des processus métiers “vitaux” pour s’assurer de leur bon fonctionnement. Rien A Signaler, la mise en production est réussie.

Tout de suite il faut penser à mettre en place les outils de suivi et d’analyse. On choisi Munin pour le suivi des performances serveurs et Google Analytics pour l’analyse de notre trafic.

Ensuite il n’y a plus qu’à surveiller tout ça.

Facteurs clés de succès / Bests practices

• La maîtrise parfaite de l’environnement technique par nos équipes. Ce point est absolument déterminant, chez FBC nous maîtrisons parfaitement notre environnement et l’administration de Linux Ubuntu, d’apache, de mysql. Notre expérience nous a permis d’éviter les pièges et d’aller vite,
• La qualité de l’architecture technique, des développements, des tests et le niveau d’exigence global. Cela explique en grande partie le petit nombre de bug de prod et la bonne satisfaction client sur la version
• Une MEP préparée depuis le début des développements. Nous avons veillé à ce que l’équipe de DEV fournisse au fil de l’eau l’ensemble des scripts de migration aux testeurs ce qui a permit au final de rejouer des dizaines de fois le script de migration. Lors de la mise en PROD, ce script a marché du premier coup et la base a été migrée en une seule fois

Axes d’amélioration

• Utiliser pour la V2 le mécanisme de branches de svn.

Et vous quelle approche pour vos MEP ? Vos bests practices ? Vos outils favoris ?