J'ai écrit des applications de rails depuis si longtemps que je suis soudainement coincé avec quelque chose que vous recevez gratuitement avec des rails: environnements.
C'est-à-dire que vous pouvez exécuter l'application Rails localement et par défaut, Rails_env (ou Rails.env) est "Développement". Et si vous exécutez vos spécifications / tests, c'est "TEST" et lorsque vous déployez sur votre serveur de production, vous l'avez configuré pour exécuter "production".
Ceci est particulièrement utile lorsque vous avez des fichiers de configuration. Également utile pour le gemfile pour différencier les pierres précieuses pour certains environnements.
Alors maintenant à ma question: J'écris une application pure rubis et je ne connais pas la meilleure façon de la configurer pour que je puisse toujours avoir les environnements multiples? Je souhaite configurer des fichiers de configuration des services tiers (comme Mongolab / Iron.io / etc.) Mais je les souhaite de créer avec "développement", "test", "production", etc., puis je veux être capable d'exécuter l'application de divers environnements.
Je sais que je pouvais simplement le gérer manuellement via des variables d'environnement de ligne de commande, mais je me demande s'il y a de meilleures pratiques (meilleures?) pour cela? Des gemmes qui aident à cela? Ou toute recommandation pour structurer la manipulation de l'environnement pour une application pure rubis?
merci,
3 Réponses :
Vous pouvez faire quelque chose comme si la façon dont les rails le fait: puis vous définissez l'environnement var via des tâches Rake. P> gem 'foo'
group :test do
gem 'rspec'
end
Aussi intéressante lisant pourquoi vous ne devriez pas utiliser env ['rack_env'] HEZMATT.ORG/~MPALMER/12/2013/10/13/...
J'aime cette approche. J'ai fini par utiliser une approche modifiée. Il était également intéressant de voir comment les rails le fait en interne. Bien sûr, je n'ai pas besoin du sucre syntaxique de: rails.env.développement? Je vais bien avec: helper.env == "Développement"
Utilisez Utilisez d'autres ENV pour gérer vos dépendances. Par exemple, les informations d'identification et les configurations peuvent être stockées dans ENV. Certaines ENV sont généralement stockées dans un fichier de configuration, comme Vous pouvez utiliser la pierre précieuse dotenv pour gérer votre ENV locale de. Cependant, je préfère avoir un script rubis ou shell qui définit les ENV et / ou commence le serveur dans l'environnement de développement: local_setup.rb: ou rackup_local.sh: Vous pouvez utiliser un script similaire pour la configuration de test et le besoin dans l'assistant de spécification. Je préfère ajouter les configurations au sommet de l'aide de spécifications. Si vous mettez des secrets dans votre script env, assurez-vous de l'ignorer et de ne pas l'ajouter à votre repo. < P> En ce qui concerne le gemfile, ce n'est pas une bonne idée d'utiliser des pierres précieuses différentes pour des environnements différents, à moins que la bonne raison de le faire. Les tests, le débogage et la mise en cache sont de bons exemples pour être dans un groupe d'environnement dans le Gemfile. env ['rack_env'] . rails_env est en réalité une copie de celui-ci. base de données.yml ou mongoid.yml .
Pourquoi ne serait-il pas une bonne idée d'utiliser des groupes dans votre gemfile?
Parce qu'il introduit des différences entre les environnements de production et de test. Cela réduit l'efficacité des tests.
Qu'en est-il des gemmes spécialement utilisées pour les tests ou le débogage qui n'ont pas de place en production? Ou des gemmes qui résolvent des problèmes spécifiques à la production telles que la mise en cache mais qui peuvent faire des tests difficiles ...
Oui, ceux-ci devraient être dans leur groupe approprié dans le gemfile.
Mais vous dites que nous ne pouvons pas utiliser de groupes.
Ce sont de bonnes raisons d'utiliser des groupes. J'ai mis à jour la réponse.
Si vous parlez de fichiers de configuration, vous pouvez simplement utiliser une configuration qui ressemble à un fichier Il y a aussi au moins un gemme pour traiter de tels fichiers de configuration "multi-niveaux". < / p> de wagons.yml , lisez-le et sélectionnez le jeu "Droite" de variables.
Les rails sont «juste» un grand script rubis, vous pouvez vous inspirer de son code: GITUB.com/Rails/Rails/Search?utf8=%E2%9C%93&q=env