le fond: Maintenant, des étapes ci-dessus, nous observons que dans les étapes 1 et 2, tandis que l'application fonctionne en mode test, il a une configuration différente. Similaire est le cas avec les étapes 3,4 et 5.
Dans de telles situations, quelle est la pratique recommandée? Nous avions des fichiers de configuration YAML, mais personnellement, j'ai senti que le maintien de nombreux fichiers de configuration n'a pas de sens. Et donc, j'ai changé de la pratique de suis-je sur la bonne voie? Est-ce que mon action, simplifie-t-elle les choses?
Quels sont les avantages et les inconvénients de ces deux approches?
Étape 1 -> Nous avons une boîte qui exécute des tests de l'unité et des fonctionnalités d'une application en l'exécutant en mode test avec une configuration spécifique.
Étape 2 -> En cas de succès de l'étape 1, nous exécutons des tests d'intégration d'une application en l'exécutant en mode test avec un ensemble de configuration différent, dans une autre case.
Étape 3 -> Sur le succès de l'étape 2, nous exécutons les tests de performance d'une application en l'exécutant en mode de production, dans la zone de test de performance.
Étape 4 -> Sur le succès de l'étape 3, la construction est considérée comme stable et la boîte UAT est mise à jour avec cette base de code et l'application est exécutée en mode de production, pour la révision et les commentaires du client.
Étape 5 -> Avec Aller du client, la boîte de production est mise à jour avec la base de code.
"fichier de configuration par environnement"
à
3 Réponses :
chez mon entreprise, nous avons les deux, d'une manière.
Nous avons une application Rails qui peut pointer sur l'une des différentes installations d'un autre logiciel et utiliser l'API à partir de cette installation. Pour spécifier une installation, environ 5 variables doivent être définies.
Nous avions chacune de ces variables en tant que variables d'environnement distinctes, mais toutes les personnes ont été très rapides et que nous avons inévitablement oublié une.
Alors maintenant, nous avons une variable d'environnement, nous appelons env_Token et nous avons des fichiers YAML contenant des entrées correspondant aux variables Env_Token valides, ainsi que le code dans la configuration / Initialiseurs qui définit env [Touche] = valeur. < P> Disons donc que j'ai des variables "foo" et "bar" que je veux régler sur "un" et "deux", respectivement. Je pourrais créer un fichier yaml contenant: et je définirais mon environnement variable env_Token à CarolClarinet et FOO et Bar est défini sur un et deux. Je n'ai aucune idée si c'est la meilleure façon de le faire, mais cela fonctionne pour nous. ETA: Notez que cela s'applique uniquement à l'élaboration et à l'essai, l'installateur de notre logiciel prend soin de Configurez tout cela pour que nos clients ne changent jamais de variables d'environnement.
Je ne sais pas si c'est le meilleur moyen ou non non plus, mais c'est certainement une amélioration.
Dans mon expérience, les variables d'environnement sont l'option de configuration de Last-Resort. Ils ont absolument leur place, mais les applications doivent généralement vérifier d'abord une autre option de configuration plus fiable et explicitement intentionnelle. Je vous recommande vivement de charger la configuration à partir d'un fichier YAML et n'utiliserais qu'une variable d'environnement comme une relèvement. Supposons toujours que votre variable d'environnement va s'appliquer à tout ce qui est à l'échelle du système et suppose que cela va accidentellement obtenir non défini ou défini sur la mauvaise valeur à un moment donné. C'est-à-dire que votre application ne devrait pas commettre Seppuku, car certains répertoires de configuration sont définis sur Personnellement, j'aime déposer Avec votre problème précis, honnêtement, je passerais probablement la valeur de configuration pour laquelle l'environnement démarre sur la ligne de commande. / et il ne dispose pas de les autorisations (ou d'effacer vous effacer votre lecteur car l'application a couru comme root < / code>). Ou plus probablement, quelque chose comme votre rails_env a été défini sur test quand il aurait dû être production et personne ne réalisé et maintenant les utilisateurs écrivent des données au mauvais endroit ou à / dev / null sur le compte de tous les 500s.
LOGGER.WARN Messages à chaque fois que je retombe à une variable d'environnement pour une valeur de configuration.
Merci. Il est basé sur votre déclaration que les variables d'environnement pour l'application config sont la dernière action de recours, ainsi que votre conseil pour utiliser le fichier YAML pour charger les configurations de l'application, j'ai proposé la conception que j'ai bloguée dans mon poste. Votre réponse a doublé ma passion pour aller à la solution. Merci encore!
Oui, cela, un million de fois. Les fichiers de configuration sont saluits avec moins de l'environnement. De plus, lorsque vous relisez un fichier de configuration, vous obtenez la valeur téléchargée la plus récente. Je ne peux pas vous dire combien de fois j'ai dû expliquer aux personnes que vous devez modifier explicitement la variable d'environnement actuelle de votre coquille ou tuer votre coquille après avoir changé .profile et redémarrez-le pour obtenir une variable d'environnement mis à jour chargée. Il confond les gens. Utilisez simplement un fichier de configuration.
Après beaucoup de googling en vain, discussions avec des collectes de rails et un brainstorming, j'ai apporté des modifications au code de telle sorte que j'ai "un fichier de configuration par voie de rails, externalisant les configurations de l'application dans un fichier YML , qui reste dans mon cas à l'extérieur de l'environnement des rails " strong> suivez les extraits de code auto-explicatif pour comprendre comment je le réalise de manière simple. L'explication rapide est que l'extrait de code dans le fichier Environnement.rb lit le fichier YAML du système pour copier toutes les paires de la valeur de clé vers les rails en env haash. Ce hachage env est disponible partout où / On / après la charge de l'application. P> File: config/environment.rb
# Mechanism to load all application related configurations
$CONFIG_FILE = "/var/myapp/config/jsconfig.yml"
require 'yaml'
APP_CONFIG = YAML.load_file($CONFIG_FILE)
APP_CONFIG.each do |key, value|
ENV[key] = value
end
#3rd Party Server's (that my application is using) Configurations here...
3RD_PARTY_SERVER_URL = ENV['3rd_party_webservice_endpoint_url']
3RD_PARTY_SERVER_CREDENTIALS = {:username => ENV['3rd_party_server_username'], :password=> ENV['3rd_party_server_password']}
File: /var/myapp/config/jsconfig.yml
3rd_party_webservice_endpoint_url: url
3rd_party_server_username: username
3rd_party_server_password: password
myapp_db_url: jdbc:oracle:thin:@localhost:1521:XE
myapp_db_username: kartz
myapp_db_password: rails_savvy
File: /var/myapp/config/database.yml
development:
adapter: oracle_enhanced
url: <%= ENV['myapp_db_url'] %>
username: <%= ENV['myapp_db_username'] %>
password: <%= ENV['myapp_db_password'] %>
encoding: utf8
test:
adapter: oracle_enhanced
url: <%= ENV['myapp_db_url'] %>
username: <%= ENV['myapp_db_username'] %>
password: <%= ENV['myapp_db_password'] %>
encoding: utf8
production:
adapter: oracle_enhanced
url: <%= ENV['myapp_db_url'] %>
username: <%= ENV['myapp_db_username'] %>
password: <%= ENV['myapp_db_password'] %>
encoding: utf8