Bonjour à tous,
Je cherche de la doc et des bonnes pratiques pour le partage des modèles
entre deux projets Rails. Avez-vous ça dans vos favoris, ou un avis sur
le
sujet ?
Merci
Emilien
Emilien T. wrote:
Je cherche de la doc et des bonnes pratiques pour le partage des modèles
entre deux projets Rails. Avez-vous ça dans vos favoris, ou un avis sur
le sujet ?
Bonjour Emilien,
J’ai “croisé” récemment un projet Rails qui utilisait Desert pour cela
(http://github.com/pivotal/desert).
Alban P. - [email protected]
http://people.tryphon.org/~alban
m’semble que les “engines” rescucités dans la 2.3 permettent ça de façon
standard :
(pour les modèles ça demande à être creusé, mais il me semble qu oui…)
En effet, les Rails Engines semblent faire le boulot, cf railscast :
Ca reste assez vague sur la manière de synchroniser l’appli “importée”
et le
app/ du plugin, peut-être à coup de rsync ?
2009/3/19 philippe lachaise [email protected]
Je cherche de la doc et des bonnes pratiques pour le partage des modèles
entre deux projets Rails. Avez-vous ça dans vos favoris, ou un avis sur le
sujet ?
Veux-tu partager la base de données en plus des modèles, ou simplement
le code des modèles et des migrations ?
– Thibaut
Partager la base de donnée et les modèles, effectivement : je suis dans le
cas du front-office et du back-office placés sur des serveurs différents.
Une question se pose: est-ce que tu as la main pour redéployer les
applis en même temps quand le schéma évolue ? Ou es-tu contraint (car
ça coute plus cher) à faire évoluer l’un un jour, puis l’autre
quelques jours plus tard ? (cad nécessité de gérer une phase de
transition, avec les données additionnelles en nullables par exemple)
Dans les deux cas une possibilité (proche de ce que je fais dans un
cas un peu analogue) est d’utiliser le back-office en
“maitre” (référence), et un “piston import” d’un répertoire dédié aux
modèles dans l’autre application.
– Thibaut
Partager la base de donnée et les modèles, effectivement : je suis dans
le
cas du front-office et du back-office placés sur des serveurs
différents.
2009/3/20 Thibaut Barrère [email protected]
Salut,
Le vendredi 20 mars 2009 à 16:45 +0100, Emilien T. a écrit :
Partager la base de donnée et les modèles, effectivement : je suis
dans le cas du front-office et du back-office placés sur des serveurs
différents.
J’ai peut-être lu un peu vite les postes mais…
Pourquoi ne pas réunir le front et le back dans la même appli et la
déployer sur les deux serveurs ?
La base ne pourrait-elle pas se trouver sur l’un des deux serveurs et
chaque serveur son database.yml pour pouvoir y accéder (host configuré
local pour l’un et host configuré distant pour l’autre) ?
La différenciation entre back et front (alors que l’appli est la même)
ne pourrait-elle pas se faire soit par fonctionnalité en testant le
hostname (%X(hostname)) quand nécessaire soit par routage en déployant
un routes.rb différents par serveur (ou les deux).
Si besoin, mettre en place un partage nfs entre les deux serveurs ?
Ne serait-il pas facile de mettre cela en place avec capistrano
(obligation de déployer simultanément bien-sur pour rester cohérent) ?
Un seul projet c’est quand même plus facile à maintenir que deux.
L’inconvénient bien-sûr est de ne partager que la base et le code (voir
les fichiers), pas l’ espace d’adressage…mais là c’est un autre
problème… erlang ?
J.
Pourquoi ne pas réunir le front et le back dans la même appli et la
déployer sur les deux serveurs ?
Si c’est possible, c’est l’idéal…
– Thibaut
Je confirme que ce n’est pas envisageable dans mon cas de réunir les
deux
applis sur un même serveur. Des histoires de certif… Thibaut, comment
as-tu géré le “piston” ?
2009/3/20 Thibaut Barrère [email protected]
Hello,
Thibaut, comment as-tu géré le “piston” ?
Piston est un outil qui permet d’importer le contenu d’un repository
distant (ex: le repository de ton appli maitre) dans un autre
repository (ex: celui de ton appli secondaire), tout en retenant les
infos (ex: numéro de révision) sur lesquelles tu t’es basé pour faire
cet import.
Tu peux réaliser des “updates” périodiques (réimporter le maitre), les
passer en revue (tests etc) avant commit.
Tu peux voir une intro pour un autre type d’usage sur mon blog:
http://blog.logeek.fr/2008/1/4/how-to-use-piston-to-ease-your-upgrades
Plus d’infos sur le site: http://piston.rubyforge.org/
Nb: la version publique fonctionne avec SVN. Si tu as besoin de SVN +
GIT, voir la version 2.0 dispo sur github:
– Thibaut