J'aimerais pouvoir pousser le code vers dev.myapp.com
pour le test, puis verswww.myapp.com
pour une utilisation en production. Est-ce possible avec Heroku?
J'aimerais pouvoir pousser le code vers dev.myapp.com
pour le test, puis verswww.myapp.com
pour une utilisation en production. Est-ce possible avec Heroku?
Réponses:
Votre interface avec Heroku est essentiellement une branche Git. La gemme Heroku fait du travail via son API, mais dans votre référentiel Git, il ne s'agit que d'une nouvelle branche distante.
heroku create yourapp # production
git br -D heroku # delete the default branch
heroku create staging-yourapp # staging
git br -D heroku # delete the default branch
Une fois que vous avez configuré plusieurs applications sur Heroku, vous devriez pouvoir configurer votre référentiel Git comme ceci:
git remote add staging git@heroku.com:staging-yourapp.git
git push origin staging
git remote add production git@heroku.com:yourapp.git
git push origin production
Je travaille généralement dans une branche «active» et j'utilise Github pour mon maître.
En supposant que ce soit le cas pour vous, votre flux de travail de déploiement ressemblerait probablement à ceci:
git co -b working
# do some work
# push to github:
git co master
git merge working
git push
# push to staging:
git co staging
git merge master
git push origin staging
# push to production
git co production
git merge master
git push origin production
heroku create yourapp --remote your-remote
heroku
commandes doivent inclure --app staging
ou --app production
. Existe-t-il un moyen de définir une valeur par défaut? (Demander comme commentaire b / c cela semble trop ciblé pour être une question SO à part entière.)
Cela explique tout ce que vous devez savoir si vous êtes un débutant comme moi: http://devcenter.heroku.com/articles/multiple-environments
Un élément clé de la question initiale concerne la liaison de l'application de développement à un sous-domaine (dev.myapp.com) de l'application principale (www.myapp.com). Cela n'a été abordé dans aucune des réponses.
Étape 1: Configurez les versions de production ('myapp') et de préparation ('staging-myapp') de votre application, comme indiqué dans la réponse de Luke Bayes
Étape 2: Dans votre système de gestion de domaine (par exemple GoDaddy):
Create a CNAME record: dev.myapp.com
that points to: proxy.heroku.com
Étape 3: Configurez Heroku pour acheminer dev.myapp.com vers staging-myapp:
heroku domains:add dev.myapp.com --app staging-myapp
Une fois que l'enregistrement CNAME a eu le temps de se propager, vous pourrez exécuter votre application intermédiaire sur dev.myapp.com.
before_filter
crochet à mon application_controller
pour attraper TOUT dans la mise en scène et forcer l'utilisateur à se connecter en tant qu'administrateur, puis définir un cookie administrateur afin que je puisse toujours voir l'application du point de vue d'un `` non-administrateur ''. Travaille plutôt bien pour moi.
Vous devriez vérifier le heroku_san
Il fait un très bon travail en jonglant avec les environnements sur heroku.
Les choses sont plus faciles maintenant. Voici comment procéder ...
$ heroku create myapp --remote production
$ heroku create myapp-staging --remote staging
Cela créera des dépôts distants nommés pour chaque application, que vous pouvez voir dans .git/config
.
Vous pouvez maintenant utiliser les commutateurs --app ou --remote pour cibler une application particulière:
$ heroku info --app myapp-staging
$ heroku info --remote staging
Pour les applications Rails, Heroku utilise par défaut l'environnement «production» . Si vous souhaitez que votre application de préparation s'exécute dans un environnement de préparation , créez l'environnement dans votre projet et définissez les variables d'environnement RAILS_ENV et RAKE_ENV correspondantes sur l'application:
$ heroku config:set RACK_ENV=staging RAILS_ENV=staging --remote staging
Si vous avez d'autres variables de configuration, vous devrez également les transmettre pour chaque environnement.
$ heroku config:set AWS_KEY=abc --remote staging
$ heroku config:set AWD_SECRET=123 --remote staging
...etc
C'est une énorme douleur alors j'utilise juste mon joyau snappconfig et je cours
$ rake heroku:config:load[myapp-staging]
pour charger les fichiers de configuration YAML de mon projet dans Heroku.
Maintenant, vous poussez simplement vers Heroku comme ceci:
$ git push staging master
$ git push production master
et migrez comme ceci:
$ heroku run rake db:migrate --remote staging
$ heroku run rake db:migrate --remote production
(Voir Gérer plusieurs environnements pour une application | Centre de développement Heroku pour plus d'informations et de raccourcis.)
RAILS_ENV
et RACK_ENV
à staging
est déconseillé par Heroku: "Il peut être tentant de créer un autre environnement personnalisé tel que" staging "et de créer un fichier config / environnements / staging.rb et de le déployer sur une application Heroku avec RAILS_ENV = staging. Ce n'est pas une bonne pratique . Au lieu de cela, nous vous recommandons de toujours exécuter en mode production et de modifier tout comportement en définissant vos variables de configuration. " Plus d'informations ici: devcenter.heroku.com/articles/…
git push staging edge work
?