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
on 16.03.2008 09:21
on 16.03.2008 09:26
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 Bouton a écrit :
on 16.03.2008 09:59
> 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
on 16.03.2008 10:45
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 Betous<guillaume.betous@gmail.com> a écrit :
on 16.03.2008 11:23
Ok merci pour vos réponses :) 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 <yann.klis@gmail.com> a écrit :
on 16.03.2008 20:07
> 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
on 17.03.2008 13:08
On 16 mar, 10:45, "Yann KLIS" <yann.k...@gmail.com> 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
on 17.03.2008 23:15
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.
on 19.03.2008 21:59
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
on 20.03.2008 13:54
On 17 mar, 21:18, Sébastien Lamy <lamys...@free.fr> 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.
on 20.03.2008 17:31
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<renaud.morvan@gmail.com> a écrit :
on 21.03.2008 15:41
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 )
on 24.03.2008 13:40
On 21 mar, 15:40, "Jean-François Trân" <jft...@rubyfrance.org> 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.