Instance de mise en scène sur Heroku


85

J'aimerais pouvoir pousser le code vers dev.myapp.compour le test, puis verswww.myapp.com pour une utilisation en production. Est-ce possible avec Heroku?

Réponses:


142

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

Merci - cela a du sens (je crains git). Question: Supposons que je travaille sur des changements de pointe sur la branche "edge". Comment puis-je pousser cette branche vers staging-myapp sans affecter myapp (qui est actuellement en cours d'exécution sur la branche principale)? Le fait git push staging edge work?
Tom Lehman

Dans l'intérêt de vous faire avancer, il vous suffit de fusionner le bord de votre branche intermédiaire et de le pousser. Votre branche de production est séparée et propre. Vous pouvez toujours créer une branche et apporter des modifications qui ne fusionnent que là-bas.
Luke Bayes

5
Au lieu de créer des applications avec la branche distante par défaut 'heroku' et après l'avoir supprimée, vous pouvez utiliser une solution beaucoup plus agréable comme:heroku create yourapp --remote your-remote
dombesz

2
Une fois que vous avez configuré cela, toutes vos herokucommandes doivent inclure --app stagingou --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.)
Paul A Jungwirth

3
@PaulAJungwirth Pour définir une application Heroku par défaut, utilisez quelque chose comme "git config heroku.remote staging". Plus d'informations dans la documentation Heroku sur devcenter.heroku.com/articles/multiple-environments .
grifaton le


10

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.


1
Que diriez-vous du contrôle d'accès pour qu'il n'apparaisse pas dans Google, etc. et que les gens ne tombent pas dessus et ne pensent pas que c'est la vraie chose? des solutions intéressantes?
brittohalloran

Oui, le moyen le plus simple est de sauter l'étape GoDaddy et d'accéder à la version «dev» de votre application directement depuis le domaine Heroku à l'aide de l'URL Heroku. (par exemple, stormy-lake-5483.heroku.com. ) Cependant, si vous voulez que «dev» soit hors de votre domaine comme décrit ici, vous pouvez toujours installer un fichier robots.txt pour en informer google, bing, et. Al. pour ne pas indexer votre site de développement. Cela aidera à le garder hors des moteurs de recherche.
Don Leatham

J'ai fini par ajouter un before_filtercrochet à mon application_controllerpour 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.
brittohalloran

8

Vous devriez vérifier le heroku_san

Il fait un très bon travail en jonglant avec les environnements sur heroku.


7

Les choses sont plus faciles maintenant. Voici comment procéder ...

Créez une application pour chaque environnement

$ 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

Définir les environnements Rails

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

Configurer les environnements

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.

Déployer

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.)


Le réglage RAILS_ENVet RACK_ENVà stagingest 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/…
Koen.

@ Koen- Essayer de gérer des configurations Rails complexes sans le contexte des environnements est totalement irréalisable dans mon expérience, que ce soit sur Heroku ou ailleurs. Si vous avez un ensemble complet de chaînes de connexion, de clés API, etc. pour votre application de test et un autre pour votre application de production, allez-vous vraiment définir ces variables de configuration individuellement pour chacune? C'est juste demander des ennuis - Heroku donne de mauvais conseils ici.
Yarin

Merci. Je recherche des staging qui obtiennent vraiment une vraie URL, probablement avec commithash. Je pense que c'est quelque chose que Zeit Now ou Netlify a rendu facile.
Polv
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.