La technique au service du Lean Startup
À ChooseYourBoss, un site d'emploi informatique, on fait du Lean Startup. Plus précisément, on applique la méthode du Build-Measure-Learn (Construire - Mesurer - Apprendre). Tous les jours on construit notre produit, on l'améliore. Mais une partie importante de celui-ci est un logiciel que l'on développe.
Bien évidemment tout ce que l'on développe est au service du produit ou de nos clients.
Notre but étant d'apprendre le plus possible et surtout le plus vite possible, nous avons mis en place un certain nombre de pratiques qui nous aident. Ce sont des pratiques tout ce qu'il y a de plus classique. Mais mises ensemble elles nous permettent de nous améliorer. Nous allons donc vous les décrire succinctement.
Feature flipping
Cette technique permet d'activer ou de désactiver une fonctionnalité à tout moment. Cela a plusieurs avantages. Tant qu'une fonctionnalité ne nous satisfait pas, on peut la cacher aux utilisateurs. On peut même aller plus loin et ne l'activer que pour un ensemble restreint d'utilisateurs, ce qui nous permet de tester une fonctionnalité avant de la rendre disponible au plus grand nombre, et donc de valider ou invalider une hypothèse (boucle build-measure-learn).
De plus, cela nous aide au continuous delivery (déploiement continu), qui est décrit ci-dessous.
Continuous delivery
Le but du continuous delivery, ou deploiement continu, est de pouvoir mettre en production notre produit à tout moment. Souvent, dans l'imaginaire populaire des DSI, mettre en production est synonyme de problèmes. En effet, il est constaté que plus le temps entre deux mise en production est grand, plus le risque d'erreurs et de problèmes est grand. Nous avons donc opté pour des mises en production régulières, jusqu'à plusieurs fois par jour. En effet, nous développons de nombreuses petites fonctionnalités que nous voulons tester au plus vite, ce qui implique donc de les passer rapidement en production.
Bien évidement, nous ne mettons pas n'importe quoi en production. Premièrement, grâce au feature flipping, tout notre code est en production, mais qu'un ensemble de nos fonctionnalités sont actives.
Deuxièmement, nous avons une batterie de tests importantes ET automatisées qui nous garantissent la non régression de notre site.
Tests automatisés
Nous sommes convaincu que les tests automatisés nous font gagner du temps sur le long terme. Donc nous en écrivons systématiquement. Notre application est composées de deux parties : une partie serveur (en Ruby on Rails) et une partie cliente (en Javascript + CSS3).
Chaque partie possède plusieurs niveaux de tests automatisés :
Tests unitaires : tests sur nos modèles Ruby et nos comportements Javascript
Jasmine pour Javascript
rSpec pour Ruby
Tests fonctionnels : tests de nos contrôleurs en Ruby
Toujours rSpec pour Ruby
Nous n'avons pas de contrôleurs en Javascript, donc pas de tests
Tests d'intégration : tests sur l'enchaînement des actions utilisateurs et des écrans
rSpec + Capybara pour Ruby
Capybara webkit pour Javascript
De plus, nous avons un niveau de test supplémentaire. Ce sont des tests de bouts en bouts sur un certain nombre de fonctionnalité clés. Ceux-ci sont écrit en Capybara sélénium, et s'exécutent sur notre preproduction. Ils nous permettent de nous assurer que ces fonctionnalités seront bien fonctionnelles sur notre production.
Comme indiqué plus haut, ces tests sont automatisés, nous avons donc une usine de build qui s'occupe de tout ceci.
UDD
Encore une fois, rien d'etrange, nous avons une usine de build : un jenkins. Celui-ci est sûrement un peu plus central chez nous que sur d'autres projets.
Effectivement, il s'occupe de construire, tester et déployer notre application. Nous avons établi un simple workflow qui part du code et qui arrive à une application déployée en preproduction. Nous avons 4 étapes :
- Tests Ruby dans l'ordre (unitaires, fonctionnels, d'intégration), puis tests d'intégration Javascript
- Tests unitaires Javascript
- Déploiement en preproduction
- Tests de bouts en bouts
Si une étape échoue, le processus s'arrête et nous prévient de l'erreur. Si cette chaîne complète est sans erreur, nous sommes sûr à 90% que notre application peut partir en production (enquête effectuée autour d'un café un vendredi matin). Nous n'avons pas voulu rajouter le déploiement en production dans ce processus. Il y a plusieurs raisons. Nous aimons pouvoir tester manuellement l'application avant une mise en production. De plus, nous n'avons pas envie que notre site soit coupé régulièrement à cause d'une mise en production, notre infrastructure actuelle ne nous permettant pas de déployer sans avoir de temps d'indisponibilité du site.
Nos technos
Toujours dans le but de faire vite et bien, nous avons choisi plusieurs technologies qui nous semblait répondre à ce besoin.
Comme déjà indiqué plus haut, nous développons notre site en Ruby on Rails. Nous n'allons pas rentrer dans les détails et dans un combat de geek. On a choisi cette technologie, parce que c'est celle où notre équipe est la plus efficace, et celle qui nous semble la plus adaptée pour réaliser rapidement un site internet. En effet, il existe de nombreuse bibliothèques existantes (des gems dans le jargon Ruby), qui permettent de rajouter facilement des fonctionnalités (interface d'administration, authentification via linkedin et viadeo, pagination, etc.).
Étant en Rails, nous avons logiquement opté pour le PaaS (Plateform as a service) Heroku. Pourquoi celle-ci ? Encore une fois la réponse est simple : rapidité et simplicité. Nous pouvons déployer en quelques minutes (il suffit de publier le code sur un dépôt git). Rajouter de la puissance CPU nous prends quelques secondes, de même pour rajouter un service. En l'espace d'une heure, nous avons mis en place un memcache et activé la mise en cache de nos javascript, images et css dans celui-ci (cf. article).
Nos métriques
Nous avons beaucoup parlé de la partie build, mais la technique nous permet aussi d'effectuer la partie measure, de nos boucles build-measure-learn.
Pour ceci, nous avons mis en place plusieurs outils.
Dans le désordre. Newrelic nous permet d'avoir des métriques assez précises sur la santé technique de notre application : temps de réponse, erreurs en production, etc.
Google website optimizer nous permet d'effectuer des tests A/B.
Enfin, le centre de toutes nos mesures est Google Analytics. Il nous permet de suivre en temps réel nos différents tunnels d'inscription et de conversion, ainsi que de récupérer de précieuses informations sur nos visiteurs, et de répondre à des questions dans le style : est-ce que l'on dois passer du temps à faire fonctionner notre site sous internet explorer 6 ? Est-ce que l'on doit améliorer notre site mobile ? Est-ce que nos tunnels convertissent efficacement ? Si non, où est-ce que les utilisateurs les quitte ?
Conclusion
Comme vous avez pu le constater, nous n'utilisons aucune technique ou technologie particulière. Mais leur assemblage nous permet de gagner en fluidité et rapidité dans notre quotidien.
Nous pourrions aller plus loin dans certaines (vrai déploiement continu en production, avoir plus de de tests, ouvrir toutes nos fonctionnalités progressivement, etc.), mais pour le moment n'étant qu'au début de la construction de notre produit, nous pensons que ce n'est pas encore nécessaire.