Forum: Rails France models commun entre deux projets rails

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Emilien T. (Guest)
on 2009-03-19 19:48
(Received via mailing list)
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
Alban P. (Guest)
on 2009-03-19 20:34
(Received via mailing list)
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. - removed_email_address@domain.invalid
http://people.tryphon.org/~alban
philippe lachaise (Guest)
on 2009-03-19 20:48
(Received via mailing list)
m'semble que les "engines" rescucités dans la 2.3 permettent ça de façon
standard :
http://guides.rubyonrails.org/2_3_release_notes.ht...

(pour les modèles ça demande à être creusé, mais il me semble qu oui...)
Emilien T. (Guest)
on 2009-03-20 15:49
(Received via mailing list)
En effet, les Rails Engines semblent faire le boulot, cf railscast  :
http://railscasts.com/episodes/149-rails-engines

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 <removed_email_address@domain.invalid>
Thibaut B. (Guest)
on 2009-03-20 17:37
(Received via mailing list)
> 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
Emilien T. (Guest)
on 2009-03-20 17:45
(Received via mailing list)
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 <removed_email_address@domain.invalid>
Thibaut B. (Guest)
on 2009-03-20 18:06
(Received via mailing list)
> 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
JD (Guest)
on 2009-03-20 18:15
(Received via mailing list)
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.
Thibaut B. (Guest)
on 2009-03-20 18:36
(Received via mailing list)
> 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
Emilien T. (Guest)
on 2009-03-23 12:30
(Received via mailing list)
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 <removed_email_address@domain.invalid>
Thibaut B. (Guest)
on 2009-03-24 10:59
(Received via mailing list)
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-t...

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:
http://github.com/francois/piston/tree/master

-- Thibaut
Emilien T. (Guest)
on 2009-03-24 11:26
(Received via mailing list)
Intéressant, je ne connaissais pas. Merci !

2009/3/24 Thibaut Barrère <removed_email_address@domain.invalid>
This topic is locked and can not be replied to.