Git est le gestionnaire de sources privilégié par la communauté Ruby et donc le service qui s'impose pour héberger nos sources est Github.
Investissement pour le gestionnaire de sources: 1 compte sur Github, 1 clic.
Une fois les premières fonctionnalités développées se pose rapidement la question de savoir où déployer l'application.
Avec Rails il y a un service pour ça; Heroku.
Ce service propose une plateforme de déploiement sur le cloud pour les applications Ruby. Le déploiement ne pourrait pas être plus simple; il suffit d'exécuter une commande et l'application est accessible sur un sous domaine d'Heroku.
Investissement pour le deploiement: 1 compte sur Heroku, 1 commande exécutée.
Rapidement dans le cycle de vie de notre application, le nombre de fonctionnalités va augmenter de même que le nombre de tests. De plus il est possible que de nouveaux contributeurs se joignent à l'effort de développement. Il va donc être nécessaire de mettre en place une intégration continue.
Avec Rails il y a un service pour ça; RunCodeRun.
L'intégration avec Github est prévue et une fois celle-ci activée, chaque commit sur Github va déclencher un build sur RunCodeRun.
Investissement pour l'intégration continue: une poignée de clics.
Avec l'augmentation du volume de code il est important d'effectuer un suivi des métriques qualité pour le projet.
Avec Rails il y a un service pour ça; Caliper.
Ce service s'intègre également avec Github et permet de calculer des métriques qualité après chaque commit, de les historiser et les présenter sous forme de graphes. Petit bonus on peut comparer ses scores avec ceux du reste de la communauté.
Investissement pour le suivi des métriques qualité: 1 copier, 2 coller, une poignée de clics.
Une fois l'ensemble minimal de fonctionnalités développées, l'application va être proposée en bêta au public. On a beau faire du TDD en Rails, il n'est pas exclu qu'il survienne une ou deux exceptions en production. Le cas échéant il serait appréciable d'en être informé, dans une interface web qui pourrait tant qu'à faire les grouper par type d'erreur et assurer le suivi de la résolution de ces erreurs.
Avec Rails il y a un service pour ça, même deux en fait; Hoptoad et GetExceptional.
Heroku propose une option GetExceptional, son activation crée un compte pour ce service et nous y identifie en SSO.
Investissement pour le suivi des exceptions: 1 pincée de clics.
Ca y est, l'application n'a de bêta plus que le nom et les utilisateurs affluent. Ils affluent tellement qu'ils nous signalent des soucis de performance sur l'application. Comment savoir quelles sont les pages incriminées ? Dans quelle partie de l'application passe-t-on trop de temps ? Le rendu des vues ? Les requêtes en base ?
Avec Rails il y a un service pour ça; NewRelic.
Même principe que pour GetExceptional ; Heroku propose l'add-on NewRelic, il suffit de l'activer pour qu'un compte soit créé et le composant ajouté de manière transparente à notre application.
Investissement pour le monitoring des performances: 1 pincée de clics.
Heroku offre encore de nombreuses fonctionnalités comme l'intégration avec Amazon S3 pour le stockage, l'intégration d'Amazon RDS pour la base de données ou encore l'utilisation du moteur de recherche en texte intégral Apache Solr. Il y a également bien évidemment l'avantage des hébergements de type cloud en terme de scalabilité.
L'application développée est une application Rails tout ce qu'il y a de plus classique sans aucune modification spécifique à la technologie de déploiement utilisée. On pourra donc la déployer sans souci sur une autre infrastructure si le besoin s'en fait sentir.
Cependant si Heroku ne nous impose pas de modification spécifique à la plateforme, il y a tout de même quelques contraintes. Parmi les plus marquantes, le système de fichiers sur lequel notre application est déployée est en lecture seule. D'autre part il n'est pas possible d'utiliser un autre type de base de données comme par exemple CouchDB ou encore MongoDB.
On retrouve également les risques liés aux déploiements de type cloud, dont souffre Heroku lui-même puisque le service s'appuie sur Amazon EC2.
Etant donné que notre application de gestion de bibliothèque n'a rien de spécifique à Octo et ne contient pas de données confidentielles, cela ne pose aucun problème de la développer en open source. Dans ce cas de figure, l'ensemble de cette solution nous coûte exactement 0 euros par an.
Pour développer une application propriétaire sur le même modèle il faudra débourser un minimum ; en effet chacun des services présentés dispose d'un plan gratuit pour les projets open source et de plans payants pour les projets propriétaires, les prix s'échelonnant d'une poignée de dollars à quelques centaines selon la capacité et le niveau de service désirés.
Dans le cas de notre application de gestion de bibliothèque utilisée à l'échelle d'Octo, il faudrait prendre le premier niveau d'hébergement payant chez Heroku (15$ par mois), un abonnement Github (10 projets et 5 collaborateurs pour 12$ par mois) et un abonnement RunCodeRun (19$ par mois pour 3 projets) soit un total de 552$ pour l'année.