Добавление промежуточной среды в рабочий процесс

В настоящее время у меня есть две среды, в которых я работаю: development локально и production на Heroku.

Я хотел бы добавить среду staging на Heroku, чтобы убедиться, что все идет так, как ожидалось, прежде чем отправлять приложение пользователям. Желательно, чтобы среда staging имела те же настройки и данные, что и среда production.

Какие шаги необходимы для выполнения вышеуказанного?


person Fellow Stranger    schedule 13.10.2013    source источник


Ответы (3)


Во-первых, предрасположенность. Мне нравится, когда мои пульты heroku git настроены как промежуточные и производственные, чтобы вы могли легко использовать git push staging/production для развертывания на каждом из них. Я буду использовать эту настройку, чтобы объяснить, как создать промежуточную среду.

  1. создайте config/environments/staging.rb, который вы скопируете из `config/environments/production.rb'
  2. добавьте запись database.yml для промежуточной базы данных (на самом деле это не нужно для героку, но не помешает)
  3. Сделайте резервную копию файла .env (если он у вас есть)
  4. Установите плагин heroku-config от heroku plugins:install git://github.com/ddollar/heroku-config.git
  5. извлеките настройки среды из heroku (рабочий сервер) с помощью heroku config:pull --remote production
  6. внесите изменения в файл .env и не забудьте добавить эти значения в конфигурацию: RACK_ENV=staging RAILS_ENV=staging, чтобы он использовал конфигурацию промежуточной среды.
  7. разветвите среду heroku с помощью heroku fork -a production staging (это имена приложений heroku, которые вам нужны вместо производства/постановки)
  8. Сделайте `heroku config:push --remote staging'
  9. Обязательно правильно разверните код в промежуточной среде.

Вы также можете прочитать это руководство, я думаю, что использовал его, чтобы начать работу с несколькими окружениями на героку: https://devcenter.heroku.com/articles/multiple-environments#managing-staging-and-production-конфигурации

person berislavbabic    schedule 13.10.2013
comment
Большое спасибо за подробное объяснение. Я начал с того, что обдумал концепцию удаленной установки промежуточной/производственной среды, и как только это было реализовано, я начал задаваться вопросом: каковы фактические преимущества разделения рабочей и промежуточной сред? Обычно у меня было бы две локальные ветки: master/development, и когда разработка была отправлена ​​и проверена на тестовом удаленном сервере, я бы объединил development -> master и отправил его на рабочий удаленный сервер. - person Fellow Stranger; 16.10.2013
comment
У вас должна быть промежуточная среда, такая же, как и у вашей производственной среды, чтобы увидеть, как приложение действительно работает в производственной среде, и иметь возможность протестировать функции владельца продукта перед их запуском в производство. Большинство проблем, которые TDD на самом деле не может уловить, — это, например, регрессии css, которые вы можете легко пропустить, или где-то может сломаться вечно ревущий ад ассетов. Короче говоря, у промежуточной среды должна быть та же конфигурация, что и у рабочей, вам не обязательно иметь тот же зверь сервера, просто убедитесь, что стек полностью такой же, вплоть до развертывания. - person berislavbabic; 16.10.2013
comment
когда я запускаю команду heroku config:pull, я получаю config:pull не команду heroku. Загруженный инструментарий несколько дней назад для Mac: heroku-toolbelt/3.2.1 (x86_64-darwin10.8.0) ruby/1.9.3 - person jpw; 05.01.2014
comment
@jpwynn вам нужно установить плагин heroku-config, извините, я забыл добавить это. devcenter.heroku.com/articles/ - person berislavbabic; 11.01.2014
comment
Кто-нибудь еще получает ошибки PG :: DataCorrupted при попытке миграции после выполнения шагов babinho? - person Ben Wheeler; 01.05.2014

Я обнаружил, что heroku fork -a PRODUCTION_APP_NAME NEW_STAGE_APP_NAME - это более быстрый и простой способ сделать это... он создает новое приложение, копирует все (включая базу данных postgres). Затем я вошел и вручную понизил аддоны до меньших планов, когда это имело смысл (например, база данных начального уровня).

На самом деле, мы начали использовать относительно новый heroku pipeline:promote для автоматического (и ОЧЕНЬ быстрого) управления скомпилированным слагом из промежуточной стадии в производственную. (Это предполагает, что у вас есть какие-либо настройки, специфичные для env, через настройки или переменные среды, поэтому слаг кода тот же.)

person jpw    schedule 05.01.2014

Обратите внимание, что процедура, описанная berislavbabic, не рекомендуется в соответствии со следующим руководством на сайте Heroku: https://devcenter.heroku.com/articles/multiple-environments#managing-staging-and-production-configurations

Вы можете подробно прочитать там, но рекомендуется оставить промежуточную среду такой же, как и производственную среду, и просто использовать форк heroku для копирования из рабочей среды в промежуточную.

person Andrea    schedule 10.06.2014