SoliSoft.net

Je suis passé à Git pour ma gestion de révision de fichiers en abandonnant peu à peu SVN. Je vous le conseille fortement d’ailleurs… La gestion des branches est beaucoup plus facile et intuitive que SVN.

Pour mes projets Rails j’ai besoin au minimum d’avoir 2 branches : Une pour ma version de production et une pour ma version de développement.

Ma version de développement sera dans une branche dev, et ma version de prod dans master.

Mais voilà… pour pouvoir déployer ma version de dev il faut que la branche se situe également sur le serveur et pas seulement en local sur ma machine.

La solution est de créer une remote branche :
$ git push origin origin:refs/heads/dev
$ git fetch
$ git branch -r

Voilà, notre branche a été créé sur le dépôt.

Maintenant créons une branche en local qui permet de travailler directement sur la remote branch précédemment créée :
$ git checkout --track -b dev origin/dev

Nous voilà donc avec 2 branches.

Note : Pour pouvoir fair un push de ma branche dev, un simple git push ne semble pas fonctionner lorsque l’on est dans la branche dev. Je fais donc :
$ git push origin dev

Déploiement

Nous allons utiliser le plugin capistrano-ext :
gem install capistrano-ext

voici mon deploy.rb se situant dans config/
set :stages, %w(prod dev)
set :default_stage, "dev"
require 'capistrano/ext/multistage'
require 'mongrel_cluster/recipes'
default_run_options[:pty] = true

Je vais créer le dossier config/deploy/ dans lequel se situera mes fichiers dev.rb et prod.rb

Me voilà donc prêt à déployer mes applications
$ cap dev deploy:setup
// Paramétrages des fichiers de config database.yml et mongrel_cluster_(dev)(prod).yml
$ cap dev deploy:cold
$ cap dev deploy (pour le déploiement normal)

Pour déployer la version en production, rien de plus simple :
$ cap prod deploy:setup
$ cap prod deploy:cold
$ cap prod deploy (pour le déploiement normal)

Il m’est maintenant plus aisé d’avoir ma version stable et de développement. Lorsque ma version de développement est validée, je la merge dans mon master :
(master) $ git merge dev

La dernière version du fameux framework Ruby on Rails est sortit avec son lot de nouveautées (source linuxfr):

• Gestion des fuseaux horaires:
  Cela permet plus facilement à une application de personnaliser par utilisateur le fuseau horaire des enregistrements en base. Pour cela il suffit de sauvegarder les enregistrements en UTC (Temps universel coordonné) et une variable globale à l’application « Time.zone » change à la volée le fuseau horaire lors de l’affichage des variables.
• Dirty Tracking (mis à jour partielle):
  ActiveRecord subit une évolution importante et remarquée, on peut enfin détecter les changements d’un modèle lors d’une mise à jour (par un formulaire par exemple). Cela permet de connaître facilement dans le code l’ancienne et la nouvelle valeur d’un champ précis seulement si celui-ci a changé et n’est pas encore sauvegardé.
• Périmètre nommé (named scope):
  Sans doute LA grosse nouveauté de cette version, la fonction recherche (select) d’ActiveRecord devient extensible à l’infini. C’est en fait le plugin has_finder qui est inclus dans ActiveRecord et permet de définir des méthodes qui ajoutent à la volée des conditions à la requête SQL générée, avec possibilité de les imbriquer.
  Un exemple vaut mieux qu’un long discours:
  class User < ActiveRecord::Base
named_scope :active, :conditions => {:active => true}
named_scope :inactive, :conditions => {:active => false}
named_scope :recent, lambda { { :conditions => ['created_at > ?', 1.week.ago] } }
end
# Usage standard
User.active # pareil que User.find(:all, :conditions => {:active => true})
User.inactive # pareil que User.find(:all, :conditions => {:active => false})
User.recent # pareil que User.find(:all, :conditions => ['created_at > ?', 1.week.ago])
# Imbrication possible
User.active.recent
# pareil que:
# User.with_scope(:conditions => {:active => true}) do
# User.find(:all, :conditions => ['created_at > ?', 1.week.ago])
# end

• Migrations basée sur une référence temporelle:
  En travail collaboratif, la gestion des migrations (script qui permet de faire évoluer le schéma de la base en ajoutant/modifiant/supprimant table, colonne, index, …) avec un compteur incrémenté devenait rapidement un calvaire: si 2 personnes faisait une migration avant leur prochain commit, les migrations avaient le même numéro. Maintenant, un timestamp (référence temporelle) est utilisée pour le nommage des migrations afin d’éviter toute « collision ».
• Dépendances des Gem (paquets ruby):
  On peut maintenant configurer la liste des paquets Gem requis pour l’application avec une version exacte ou minimale requise. Une nouvelle tâche à la commande « rake » permet d’installer les paquets manquants ou de les mettre à jour si besoin:
  rake gems:install
• Meilleure mise en cache:
  C’est essentiellement la flexibilité de la mise en cache qui a été améliorée, on peut dorénavant facilement implémenter une nouvelle classe de gestion de cache personnalisée et l’utiliser dans les vues.

Comme toujours pour l’installer :
gem install rails

Bref que du bien