Bonne pratique, gem ou freeze?

Community FR
1

Bonjour,

J’aimerais savoir quelle est la bonne pratique pour installer rails …
(pour une appli qui nécessite un minimum de stabilité,
tout en ayant la possibilité de mettre à jour facilement les éventuels
problèmes de sécurité).

gem ou freeze ? Quels sont les avantages et inconvénients des deux
solutions
dans la pratique ?
Dans le cas du freeze, il vaut mieux se baser sur le tag rel_2_0_2 (par
exemple) ou sur la branche stable 2-0-stable ?

Merci de vos réponses,

Emmanuel

2

gem ou freeze ? Quels sont les avantages et inconvénients des deux
solutions dans la pratique ?
j’aurais tendance à dire que le seul inconvénient de freeze est l’espace
disque occupé (qui est tout de meme négligeable de nos jours). me
trompé-je ?

gUI

3

Bonjour,

Pour ma part je freeze tout mes projets, ce qui permet d’être sur que
la bonne version de rails sera disponible sur le ou les serveurs qui
hébergeront l’application.
De plu je freeze avec la dernière version gem disponible sur ma
machine…

Le 16 mars 08 à 09:20, Emmanuel B. a écrit :

4

Ok merci pour vos réponses :slight_smile:

Comme je n’aurais pas forcément la main sur la machine de prod, je vais
donc
plutôt freezer …
Que me conseillez-vous :
freeze de la dernière version gem de ma machine ou freeze de la branche
2-0-stable et gestion de vendor/ avec piston ?
La deuxième solution m’a l’air pas mal, mais ne l’ayant pas encore
pratiquée
je ne sais pas ce qu’elle vaut …

Emmanuel

Le 16/03/08, Yann KLIS [email protected] a écrit :

5

C’est plus simple d’upgrader la version de Rails si tout est installé
en gem. Et comme le souligne un mail précédent, passer par les gems
sous-entend que tu maîtrises un peu la plateforme de prod.

++

yk

Le 16/03/08, Guillaume B.[email protected] a écrit :

6

freeze de la dernière version gem de ma machine ou freeze de la branche
2-0-stable et gestion de vendor/ avec piston ?
La deuxième solution m’a l’air pas mal, mais ne l’ayant pas encore pratiquée
je ne sais pas ce qu’elle vaut …

Juste un point: à l’usage Piston peut être assez lent sur des gros
répertoires (si tu suis tout Rails par exemple :-).

Personnellement je freeze Rails 2.0.2 car je n’ai pas besoin de plus
récent actuellement.

J’utilise Piston pour les plugins (Comatose, Mephisto etc).

Thibaut

7

On 16 mar, 10:45, “Yann KLIS” [email protected] wrote:

C’est plus simple d’upgrader la version de Rails si tout est installé
en gem. Et comme le souligne un mail précédent, passer par les gems
sous-entend que tu maîtrises un peu la plateforme de prod.

Pour ma part pour un max de stabilité et de controle je freeze tout, y
compris les gems (sauf quand ils ont des bindings C)

Je ne suis pas tout à fait d’accord à propos de l’update facilité en
utilisant rails en gems, a mon avis c’est tout le contraire en
environnement de prod.

Sur un serveur de prod passer d’une version à l’autre avec Rails en
gems est impossible sérieusement car il faudrait simulanément changer
le code + les gems, ou prier pour qu’un process ne se reload pas avec
la nouvelle version de rails pendant qu’on est en train de deployer la
nouvelle version du code.

Sans compter que pour faire un rollback ca veut dire réintervenir sur
le serveur pour manuellement remettre l’ancienne version des gems.
L’avantage de gérer le plus possible en freeze c’est la possibilité de
passer d’une version à l’autre de facon totalement automatique suivant
les process de deploiement classique et ainsi d’avoir plusieurs
version de l’appli sur plusieurs version de rails.

L’inconvénient du freeze c’est que ca pourri ton historique de SCM et
que ca a tendance à ralentir les deploiements. Et que les updates sont
chiants, Piston propose une partie de solution mais je n’ai pas osé
utilisé.
IMHO surtout éviter les svn:external

8

Renaud (Nel) Morvan a écrit :

Je ne suis pas tout à fait d’accord à propos de l’update facilité en
utilisant rails en gems, a mon avis c’est tout le contraire en
environnement de prod.

Sur un serveur de prod passer d’une version à l’autre avec Rails en
gems est impossible sérieusement car il faudrait simulanément changer
le code + les gems, ou prier pour qu’un process ne se reload pas avec
la nouvelle version de rails pendant qu’on est en train de deployer la
nouvelle version du code.

A ma connaissance, tu peux avoir plusieurs version de rails
simultanément sur la même machine, sous forme de gem. Le changement de
version se définit simplement dans configuration/environment.rb. Donc
pour passer d’une version de rails à l’autre, tu change ce fichier
simplement, et pour un rollback, ben tu auras forcément l’ancien fichier
qui précisait l’ancienne version, toujours dispo si t’as pas désinstallé
le gem.

9

Comme Renaud, je freeze tout sauf les gems qui ont des extensions
natives (et je freezerais ces dernières si c’était simple à faire).

Cette approche apporte plusieurs avantages. Un checkout suffit pour
qu’un nouveau développeur aie tous les éléments nécessaires pour faire
tourner un projet (à comparer à “as-tu installé la bonne version de la
gem xxx” ? - et appliqué le patch qui va bien ?).

En production ça évite de se créer des soucis de déploiement au
mauvais moment (ex: serveurs gems non accessible, ou problème sur des
routeurs qui empêchent le gem install - argl!).

Deux tuyaux qui peuvent être utiles toutefois:

  • on peut utiliser sous Capistrano l’option
    “set :deploy_via, :remote_cache” qui accélère le déploiement lorsque
    les fichiers sont nombreux, en gardant une copie complète dans un coin
    sur le serveur, en faisant un svn up puis une copie de ce cache vers
    le répertoire de déploiement (c’est -beaucoup- plus rapide sur mes
    tests)
  • à défaut, il peut être utile de garder les versions nécessaires de
    rails dans un répertoire, et de symlinker au déploiement pour ne pas
    avoir à stocker.

Pour ceux qui ne connaissent pas Piston, vous pouvez en apprendre
davantage sur mon post suivant:

http://blog.logeek.fr/2008/1/4/how-to-use-piston-to-ease-your-upgrades

a+

Thibaut

10

Bref question de gout, dépendre des gems me fait gagner du temps de
support et augmente la maitrise de mes environnements d’execution,
c’est tout mais c’est déjà pas mal.

Histoire de troller un peu mieux, Merb se base beaucoup plus sur la
mécanique des gems (Merb se base, d’une manière générale, beaucoup
plus que Rails sur des mécaniques Ruby de manière explicite).

++

yk

Le 20/03/08, Renaud (Nel) Morvan[email protected] a écrit :

11

Le 20/03/08, Renaud (Nel) Morvan a écrit :

Ha vi c’est vrai, j’ai dit des bétises au sujet de Rails je pensais
surtout au gems en fait. Il y a effectivement le
RAILS_GEM_VERSION ou un truc du genre depuis la 1.0,
j’avais vu passer un commit il me semble même que ca a été
amélioré récemment pour supporter tout la syntaxe de rubygems
et pas juste une version précise.

Tu veux parler du changeset 8160 ?

– Jean-François.

–
Ruby ( http://www.rubyfrance.org ) on Rails ( http://www.railsfrance.org
)

12

On 17 mar, 21:18, Sébastien Lamy [email protected] wrote:

compris les gems (sauf quand ils ont des bindings C)

A ma connaissance, tu peux avoir plusieurs version de rails
simultanément sur la même machine, sous forme de gem. Le changement de
version se définit simplement dans configuration/environment.rb. Donc
pour passer d’une version de rails à l’autre, tu change ce fichier
simplement, et pour un rollback, ben tu auras forcément l’ancien fichier
qui précisait l’ancienne version, toujours dispo si t’as pas désinstallé
le gem.

Ha vi c’est vrai, j’ai dit des bétises au sujet de Rails je pensais
surtout au gems en fait. Il y a effectivement le RAILS_GEM_VERSION ou
un truc du genre depuis la 1.0, j’avais vu passer un commit il me
semble même que ca a été amélioré récemment pour supporter tout la
syntaxe de rubygems et pas juste une version précise.

Ceci dit ce que j’ai dit reste valable pour les gems classiques, ruby
gems gère très bien les dépendances coté require_gem mais c’est
trèsrare de le voir utiliser en dehors du gem install. Un truc à rajouter
dans rails d’ailleurs ce serait la centralisation de ces dépendences,
après ca n’empeche pas de devoir installer les gems sur tous les
serveurs et les machines des devs.

Bref question de gout, le freeze me fait gagner du temps de support et
augmente la maitrise de mes environnements d’execution, c’est tout
mais c’est déjà pas mal.

13

On 21 mar, 15:40, “Jean-François Trân” [email protected] wrote:

Yup, l’ajout du support du versionnement avancé de ruby_gem.
RAILS_GEM_VERSION supporte tout ca: http://rubygems.org/read/chapter/16

Assez sympa pour les releases de projet rails open source, ca permet
de gérer un ensemble de version supportée et pas juste la version
x.y.z ou toute. Par contre je n’ai pas l’impression que ca supporte
les multiples contraintes genre >=1.2.3 et <2.0 donc c’est sympa mais
encore limité pour un usage réel.