Modèles partagés entre deux applications Rails - quelle est la solution idéale pour Workflow?

Question

Je suis actuellement en train de travailler sur un des Rails de 3 projet est divisé en quatre parties:

• Le site web
• L'administration de site web/backend
• Les modèles
• L'API pour les données de tiers l'accès

Les modèles sont partagés entre les trois éléments clés je veux les garder loin de l'être dans un projet principal, cependant, chaque partie doit avoir accès à des modèles, mais je ne veux pas répéter le code et avoir des versions différentes de partout.

Actuellement, j'ai le modèle de code dans un bijou, et chaque projet Gemfile je suis de référencement avec la ligne suivante:

gem "my_models", :path => "../my_models/"

Cependant, quand je déployer pour nos serveurs de test pour mes collègues pour évaluer le système sur j'ai besoin de tirer sur les modèles à partir d'un référentiel externe, donc je change la ligne ci-dessus par le suivant:

gem "my_models", :git => "git@private.repository.com:username/my_models.git"

Cela en lui-même fonctionne bien, mais il est assez maladroit en termes de "versions" (c'est à dire j'ai besoin de les remonter à la version à chaque fois que je souhaite déployer les modifications sur les serveurs de test), interrupteur de la ligne de plus à l'utilisation de git, et non local, et assurez-vous que je repousse correctement les fichiers.

Auparavant, j'étais partagé un git sous-module, mais c'était juste comme maladroit.

Je préfère ne pas construire le tout dans un méga-projet, que ceux-ci tendent à devenir monstrueux et difficiles à maintenir, et je tiens également à d'autres questions, si possible, afin que toutes les modifications que je fais sur le site de l'administration n'a pas beaucoup de chance d'impact sur les autres composantes - de toute évidence, les modèles ont le potentiel de causer des problèmes, mais c'est un risque que j'ai considéré et à comprendre.

Ce serait des gens suggèrent quand il s'agit de quelque chose comme cela? Ou, suis-je aller à ce sujet complètement dans le mauvais sens?

Quelques informations supplémentaires:

Cette application est une réécriture d'un site existant qui a suivi le modèle de "forfaitaire tout en un seul projet" - malheureusement, il y a deux problèmes ici:

1. L'application a été mal développé - j'ai hérité de ce projet et quand j'ai d'abord pris le temps de chargement ont été ~2 minutes par page, avec un seul utilisateur, ce qui a depuis été réduit, mais encore a des problèmes tout au long de
2. Nous sommes actuellement à notre limite de capacité du site en cours et nous prévoyons que nous aurons besoin de prendre plus de charge dans les 6 prochains mois - cependant, la mise à l'échelle avec un "tout en un" app signifie que nous allons être de gaspiller des ressources sur l'échelle le back-end du site qui n'en a pas besoin.

Il y a essentiellement deux choses que je tiens à séparer l'extrémité Avant (le site web public et de l'API) et l'extrémité arrière - tout ce que je sais sur le développement logiciel me dit que la combinaison de tout cela n'est pas une solution idéale (et du passé, me montre que la séparation de ces deux est une bonne chose en termes de garantie avant la fin de la performance).

J'ai peut-être besoin de regarder cela d'un autre angle de garder les modèles de chaque projet, et au lieu de les partager entre les projets ont un coupe-bas sous-ensemble de fonctionnalités pour chaque domaine fonctionnel (c'est à dire le backend a besoin de savoir qui a créé un poste, mais l'avant n'a pas vraiment de soins à ce sujet, afin de omettre ce logique lors de la lecture dans le modèle).

Answer 1

déposez les modèles de projet(mettre des modèles dans l'une des autres parties, je vous suggère de ce que vous considérez le "plus important"), mettre tous les projets dans un seul dépôt(projet distinct des dossiers) et de faire des liens symboliques pour les modèles/libs/api/whatever

votre code est fortement couplés entre eux et vous avez souvent besoin de faire des changements à quelques projets à la fois(comme la mise à jour des modèles et la mise à jour des Api qui les utilisent, etc)

une bonne chose à propos de unique-repo-symlink l'installation de vos commits seront moins fragmentée et normalement la pleine fonctionnalité de mise en œuvre - en faciliter le suivi de bogues, de lire l'histoire et de maintenir la base de code

aussi lorsque vous déployez vous n'avez pas besoin de lire de nombreux référentiels de - une de moins point de défaillance là

processus de libération est également plus simple avec un tel modèle, comme la filiale va maintenant procéder à la portée de tous les projets

il y a quelques inconvénients comme liens symboliques ne faut pas travailler que sur windows et autres joyeusetés, mais pour moi, il fonctionne parfaitement

Answer 2

Vous pouvez créer un moteur montable contenant les modèles partagés et en créer une gemme. Cela traitera les problèmes d'espacement des noms avec élégance. Autre aspect intéressant, vous partagez également vos actifs.

Regardez ce railcast pour plus de détails.

Answer 3

Vous devrez toujours gérer les «versions» en transmettant les modifications à tester à un référentiel distant, mais vous pouvez utiliser le nouveau local config de Bundler 1.2.

http://gembundler.com/man/bundle-config.1.html#LOCAL-GIT-REPOS

De cette façon, vos commits locaux seront pris en compte et vous n'aurez plus à changer votre Gemfile lors du déploiement.

Answer 4

Je sais que ce n'est pas une solution à votre problème particulier. Mais je vous suggère vraiment de fusionner tous les projets en un seul. Il est très courant d’avoir toutes ces pièces dans une seule application et il n’ya pas de surcharge. Je pense qu'il n'y a pas de solution non maladroite à ce problème.

Answer 5

Votre projet est d'avoir assez de couverture de code? Si c'est le cas, je voudrais essayer de séparer la logique où il fait sens, et si un modèle est utilisé dans différents projets, il suffit de choisir celui qui correspond le mieux et d'écrire une API sur le dessus de cela.

Ensuite, vous pouvez utiliser cette API pour accéder à ces modèles (de préférence en utilisant quelque chose comme ActiveModel) sur l'autre projet. Vous auriez encore un simple CRUD, mais tous les modèle de base de la logique semble être manipulés de l'extérieur.

Assurez-vous de bien réfléchir avant de les diviser, si. Vous voulez garder votre domaine serré sur chaque application que vous créer à partir de la Béhémoth vous voulez déchiré.

Concernant les moteurs:

J'ai utilisé des Moteurs pour le même problème et ça aide, mais j'ai aussi dû changer ma Gemfile soit point à un chemin d'accès local lors de l'élaboration, en poussant le bijou, puis en le tirant sur le projet actuel, qui est le comportement que vous n'êtes pas friands.