Comment organiser 50 applications rails connexes avec git ?

Question

Je m'embarque avec 50 applications rails apparentées qui auront des différences mineures entre elles - le css peut différer et peut-être que chaque application aura des routes différentes et des titres différents pour les vues pour des raisons de SEO et ainsi de suite.

Mais je veux que les 50 applications soient cohérentes lorsque je change d'autres choses. Donc, en fait, je vais devoir créer mon propre CMS et chaque site web aura des paramètres différents.

Je suis sûr que je ne suis pas la première personne à rencontrer ce problème. Comment pourrais-je organiser cela tout en utilisant Rails, git, github et heroku de sorte que lorsque je déploie, toutes les applications se mettent à jour et restent cohérentes tout en conservant leurs propres paramètres ?

Answer 1

Je bifurque un projet de base et le garde comme "upstream". Je clone le projet bifurqué dans mon environnement de développement et le garde comme "origin". Ainsi mon environnement de développement a une origine et un amont.

Quand je fais quelque chose qui affecte tous les projets bifurqués, je fais le changement en amont, puis je vais dans chaque projet, je tire d'amont et je fusionne.

Vous pouvez également avoir une hiérarchie d'amonts et les garder synchronisés avec l'amont original.

Answer 2

S'il s'agit uniquement de fichiers de configuration, la meilleure approche consiste à suivre la page Heroku " Configuration et paramètres de configuration " :

Ne mettez pas ces fichiers dans un repo Git lui-même.

Utilisez les CLI de Heroku config , config:add , config:get y config:remove pour gérer vos variables de configuration

Answer 3

Je suis un grand fan de l'idée de n'avoir à gérer qu'un seul projet si c'est possible. S'il s'agit uniquement du style (contrôlé par l'utilisateur) d'une application, vous pouvez opter pour une approche multi-tenant dans le style de Basecamp. Votre application afficherait différents points de terminaison, par exemple différenciés par des sous-domaines, vers lesquels vous pourriez également diriger différents domaines de premier niveau. Les parties variables de l'application doivent ensuite être stockées dans la base de données, comme par exemple les styles, les mises en page et tout autre contenu contrôlé par l'utilisateur. Une approche est présentée ci-dessous dans les réponses à cette question mais il y a certainement d'autres moyens.