Comment le mobile a-t-il transformé le développement des applications ? Les digital player comme Uber, Twitter, Facebook ont placé la barre haut en matière de réactivité des applications. Aujourd’hui l’expérience mobile ne peut pas être moins que rapide, fluide, instantanée. Derrière ces applications, le cloud et l’automatisation sont les éléments fondateurs de la Software Factory, une infrastructure dédiée à la livraison en continu d’applications mobiles scalables et au temps de réponse immédiat.

Si aujourd’hui la plupart de nos clients sont conscients de l’intérêt du cloud et de la nécessité d’y migrer leurs applications, ou mieux encore de concevoir des applications cloud natives, ils disposent rarement des compétences en interne pour mener ces projets. C’est dans ce contexte que D2SI a été appellé à intervenir sur ce projet en tant qu’intégrateur AWS : le client souhaitait construire une software factory entièrement automatisée, basée sur une architecture cloud AWS. Le client n’étant pas familier de la plateforme AWS, l’expertise de D2SI a été sollicitée pour concevoir l’architecture et les design patterns destinés à supporter l’application.

Le challenge posé par le changement complet de stack technique et l’intégration de nouvelles technologies tenait également à la diversité de compétences de l’équipe client : business analysts, ops, product owners, etc. Le projet a donc été mené en mode agile, rythmé par des daily meeting et des démos bimensuelles : cela a permis d’embarquer l’ensemble de l’équipe dans le projet. Autre facteur de succès, le rythme des démos : quand il faut présenter l’avancement à un public qui ignore tout d’AWS, on ne fait pas de la technique pour la technique, les résultats délivrés sont concrets.

L’objectif est ici de fournir une API basée sur des services existants, dont une plateforme Salesforce, et de construire une couche d’abstraction au dessus de ces données. Cette API est destinée à permettre le développement de l’application mobile par les équipes internes : l’API gère notamment l’authentification et tous les droits associés au compte développeur.

Nous avons fait le choix d’un modèle où les couches sont séparées :

• Couche Nginx pour le front (réceptionne les requêtes et les envoie vers les API)
• Autorisation sur l’API gérée par 3scale (provider d’API Gateway)
• Node.js pour l’exposition des données.

L’usine de déploiement automatisé sur AWS a ensuite été mise en place : la livraison du code sur Github avec une nouvelle fonctionnalité génère une batterie de tests automatisés. La non-régression est vérifiée avec Travis CI, puis un conteneur est démarré pour lancer les applications dans un environnement sécurisé, en mode blackbox. Une image système incluant les sources de l’application est ensuite packagée; cette image immutable, liée à la version du code correspondant, peut ensuite être déployée à volonté sur Amazon, sur autant de machines que nécessaire.

Une fois que l’ensemble de ces process sont automatisés, une stratégie de “zero downtime” est mise en place : l’infrastructure change de version en même temps que le code. Pour le client, cela réprésente un réel progrès : fini la complexité du passage à une nouvelle version, la migration n’entraîne aucune interruption de service. En un clic, la nouvelle version du code part en production avec de nouvelles machines virtuelles.

Ce nouveau type d’architecture suppose cependant de revoir la répartition des rôles entre développeurs et ops : les développeurs sont maintenant responsables de la mise en production. Dans ce contexte client, où les ops n’étaient pas non plus familier du développement Terraform, nous avons mis en place deux comptes différents sur AWS : intégration et production. Ceci permet une stratégie de migration blue/green en production: chacune de ces deux stacks reproduit la même architecture, l’une héberge la version en cours (blue par exemple), l’autre la version du code à être déployée prochainement (green par exemple). L’intégration est une image parfaite de la production avec une seule stack (blue).Dans ce cas client, on compte environ 50 déploiements par jour en intégration. Après validation de l’ensemble de l’équipe (y compris le product owner) d’une version spécifique déployée en intégration, celle-ci est envoyée en production (green) et par une simple action de bascule DNS, la green devient visible des utilisateurs de façon instantanée, et la stack blue (ancienne production) est alors supprimée.