Rails 4 et MongoDB part 4 : Heroku

Heroku est un service paas pour héberger des applications facilement. Afin de s’en servir facilement il faut suivre quelques conseils.

Premièrement, modifiez votre fichier mongoid.yml pour y ajouter :

Une fois fait, ajoutez la gem rails_12factor à votre projet.

Créez-vous ensuite un compte sur Heroku, puis installez la Heroku Toolbelt. Allez alors dans le dossier de votre application et lancez les commandes suivantes :

La 3e ligne sert à ajouter une base MongoDB à votre instance Heroku.

Une fois fait vous devriez alors pouvoir accéder à votre application en ligne.

Si vous utilisez Travi-CI vous pouvez le configurer afin qu’après un build réussît, le déploiement se fasse sur Heroku. Pour ce faire installer la gem travis avec la commande suivante :

Toujours dans le dossier de votre application lancez la commande suivante pour mettre à jour votre fichier .travis.yml avec les informations requises pour Heroku :

Rajoutez la ligne run: rake assets:precompile dans la section deploy de votre fichier .travis.yml.

Lors de votre prochain push sur GitHub, à la fin du build Travis si vos tests sont tous passés, votre instance d’Heroku sera mise à jour.

Rails 4 et MongoDB part 3 : Travis

Tout d’abord, qu’est-ce que Travis-CI ?

Travis-CI est un serveur d’intégration continue gratuit pour les projects open source.

Il est utilisé par beaucoup de projet afin de vérifier que les pull request n’introduise pas de bug et qu’il n’y a pas de régression lors de modifications.

Afin de l’utiliser il faut suivre les étapes suivantes:

  • Se connecter sur travis-ci.org avec son compte GitHub
  • Activer les dépôts que l’on souhaites tester
  • Ajouter un fichier .travis.yml a la racine de notre projet

Le fichier .travis.yml contient les informations dont Travis-CI a besoin afin de lancer les tests de votre dépôt.

Dans le cas de notre projet RoR avec MongoDB, il nous faut spécifier :

  • le langague
  • la version de interpréteur Ruby
  • notre base de données
  • l’environnement et la commende pour lancer les tests

Au final notre fichier .travis.yml sera le suivant :

Une fois se fichier disponible sur GitHub, Travis-CI va automatiquement lancer les tests a chaque commit.

Pour le dépôt du projet GitHub utilisé pour mes articles, la page Travis-CI est la suivante : https://travis-ci.org/dayofr/rails_tuto

On peux y voir le dernier test, la sortie de la console ainsi que l’historique des builds :

travis

Il est possible de rajouter un badge fin d’indiquer l’état actuel des tests du projet, généralement dans le fichier README à la racine du dépôt.

Rails 4 et MongoDB part 2 : Cucumber

Dans l’article précédent, nous nous étions arrêté après l’utilisation du scaffolding pour créer un document dans MongoDB et le CRUD qui va avec.

Parmi les fichiers générés nous avons :

Afin de commencer par de bonnes pratiques, nous allons créer nos premiers tests BDD avec Cucumber.

Le BDD, Behavior Driven Developmen, est une méthode agile qui consiste à écrire des tests de scénarios décrivant le comportement de l’application dans un langage le plus proche possible de celui de l’humain. Un exemple valant mieux qu’un long discoure, voilà le scénario décrivant la page de listing des posts :

En lisant ce texte, il est facile de savoir ce qu’il se passe et ce qui va être testé.

Afin de commencer, copiez le code suivant dans le fichier features/posts.feature :

Ici nous avons juste rajouté le bloc Feature afin de décrire la fonctionnalité qui sera testée.
Une fois fait, en ligne de commande lancez : rake cucumber

Vous devriez alors avoir la sortie suivante :

cucumber1Cucumber nous indique ici qu’il ne comprend pas les différentes étapes de notre test. En effet il ne peut pas comprend sans qu’on lui explique ce qu’il faire pour la ligne Given I have posts titled Paris, Marseille. Il nous faut écrire le code correspondant a cette étape. Créez alors un fichier step_definitions/posts_steps.rb puis ajoutez-y :

Que faisons-nous ici ? La 1re ligne est une expression régulière afin de définir quelle étape nous définissons, elle capture tout ce qui suit et le fournit dans la variable names .

À la ligne 2, nous divisons la variable sur ,  et itérons sur les valeurs retournées afin de les ajouter dans MongoDB grâce à la ligne 3.

Si nous relançons les tests nous pouvons voir que nous somme allez plus loin cette fois.

cucumber2Il ne nous reste plus qu’à définir les autres étapes de notre test afin d’avoir 100% dans nos scénarios :

cucumber3Pour voir le code, j’ai créé un dépôt GitHub : https://github.com/dayofr/rails_tuto .

Dans le prochain article je parlerais d’intégration continue avec Travis-ci.

Rails 4 et MongoDB part 1

Changeons un peu et parlons de Ruby, Ruby on Rails et MongoDB.

J’ai eu envie de voir ce qu’il se fait ailleurs et je pense que l’univers de RoR vaut le détour.

En partant du principe que vous avez Ruby d’installer sur votre machine, l’installation de RoR est aussi simple que :

Une fois cela fait, il suffit d’une autre ligne de commande pour créer un projet RoR :

Dans le cas présent, je n’installe pas ce qui concerne les bases de données si les tests unitaires.

Pour voir le résultat il suffit de se déplacer dans le dossier my_project et de lancer le serveur embarqué :

Rendez-vous sur http://localhost:3000/ afin de voir la page par défaut.

Passons à l’ajout de la gestion de MongoDB à Mongoid travers la gem et des gem de tests. Pour cela il faut editer le fichier Gemfile et y rajouter:

Avec la sortie récente de RoR 4, la gem mongoid n’est pas encore totalement compatible, dans notre cas nous disons à bundler d’aller la chercher sur github.

Un petit bundle install afin d’installer les nouvelles gem et nous voila prêt pour la suite.

Premièrement, il faut configurer mongoid avec :

Afin de générer les fichiers pour les tests, lançons les 2 commandes suivantes :

Avant d’aller plus loin, il faut désactiver quelques éléments prévus pour des applications avec une base de données relationnelle.

Dans le fichier spec/spec_helper.rb commentez les lignes :

Pour finir dans le fichier  features/support/env.rb  changez  DatabaseCleaner.strategy = :transaction  par DatabaseCleaner.strategy = :truncation .

Passons aux choses sérieuses avec la génération d’un model et du CRUD associé. Comme souvent, une ligne de commande suffit :

Je vous laisse découvrir ce qui fonctionne en allant sur : http://localhost:3000/posts