Scalingo est une startup Strasbourgeoise spécialisée dans l'hébergement. Leur produit fait partie de la catégorie des Platform-as-a-Service (PaaS): les développeurs et entreprises ne s'occupent pas des serveurs eux-mêmes, c'est l'équipe de Scalingo qui s'en charge. Ainsi, les utilisateurs du service peuvent se concentrer sur leurs applications et produits.
Le service est similaire à Heroku dans la manière de s'en servir, mais les technologies sous-jacentes ne sont pas les mêmes. De plus, Scalingo utilise des datacenters européens, et ce faisant permet aux entreprises européennes d'utiliser le service en toute conformité.
Je connaissais Yann (gérant de Scalingo) et Léo (directeur technique Scalingo) de Novelys où j'ai travaillé avec eux. Je savais aussi qu'ils utilisaient Ember.js pour le dashboard Scalingo et qu'ils n'étaient pas contre un peu d'aide pour le tenir à jour. J'ai donc commencé à travailler avec eux début Avril 2014.
Le dashboard était fonctionnel en lui-même, mais il commençait à accumuler de la "dette technique": ember.js était en retard de plusieurs versions, et la communauté autour d'ember.js s'était depuis mis d'accord sur un certain nombre de conventions et de bonnes pratiques qui étaient donc absentes du dashboard. Ces deux points commencaient doucement à rendre la maintenance et l'évolution de l'application difficile; c'est pourquoi mon but était d'y remédier.
Pour commencer, j'ai établie une liste des étapes à suivre, expliquant pourquoi elles étaient nécessaire et quels étaient leurs buts. Pas à pas, au fur et à mesure que l'application était refactorée, le code commençait être plus propre et plus concis. Etant donné que je documentais mon travail au fur et à mesure, Léo a rapidement été capable de s'y mettre également de son côté.
Peu après, le refactoring fut complété et le dashboard tournait avec la dernière version stable d'Ember sans problèmes. Quelques bugs ont été réglés au passage, et le système de connexion qui été légèrement buggué a été revu.
L'étape suivante consistait à migrer l'application (réalisée avec ) vers ember-cli, qui était devenu la manière officielle de travailler avec ember.js. Bien que cette étape n'impacte pas directement les utilisateurs et comment ils utilisent l'application, elle n'en est pas moins critique: utiliser ember-cli permet aux développeurs de bénéficier de morceaux de codes tiers réalisés par la communauté ainsi que de recevoir les mises à jour d'ember plus rapidement. Et vu qu'ember-cli impose une structure commune à tous les projets, le jour où un nouveau développeur joindra Scalingo, il ne perdra pas de temps à prendre ses repères avec l'application.
Une fois encore, j'ai commencé par établir la liste des étapes pour réaliser la migration. Ce travail est encore en cours à l'heure actuelle et devrait être complété prochainement.
Bien avant que mon travail soit fini, l'application était déjà plus agréable à maintenir: Léo a pu développer une nouvelle fonctionnalité assez rapidement pendant que je finissais le refactoring. Au final, le travail effectué ici a mis en place des fondations solides pour les temps à venir.