Нужны предложения при нажатии на изменения существующего приложения heroku.

Question

В настоящее время я работаю над одним из приложений (abc.com), которое развертывается в иерархической и производственной среде Heroku.

Теперь мне нужно развернуть изменения на промежуточном сервере.

Когда я начал работать, я создал отдельную ветку dev от мастера и нажал все изменения под веткой dev.

В настоящее время этап работает от master branch (Некоторые изменения нажимаются на master другим разработчиком).

Так что мне нужны предложения для следующего

1. Должен ли я объединить мастер в Dev (мастер => Dev) или Dev к мастеру (DEV => мастер).
2. Если я объединил (master => dev), должен ли я установить все переменные среды.
3. И самое главное, как я могу взять на себя герою.

Вот моя конфигурация приложения

Ruby 1.9.3 
Rails 3.2.11 

Позвольте мне знать, что-нибудь нужно.

Answer 1

Вот несколько рекомендаций. Вы должны изучить стандартизованный рабочий процесс. Если ваш друг (или кто-то в этом отношении) толкает вас непосредственно к хозяину, это может вызвать много боли. Я оставлю рекомендацию в конце сообщения.

1. Поскольку вы не следите за каким-либо рабочим процессом, на данный момент это не имеет никакого значения. Если ваш код подходит для выхода в производство, слейте dev в master. Если вы просто играете, чтобы проверить все, объедините master в dev.

2. Нет. Переменные окружения устанавливаются в среде Heroku или используют что-то вроде dotenv gem. Неважно, какую ветку вы используете на Git. (Если, случайно, ваши переменные среды проверяются в Git, пожалуйста, удалите их сейчас и читать this. Вы не хотите конфиденциальные данные проверяются в репозиторий.)

3. Если вы хотите развернуть dev ветвь Heroku , просто используйте: git push staging dev. Это предполагает, что ваш пульт Git имеет имя staging. Если вы не уверены, используйте git remote -v, чтобы получить правильное имя.

Общее правило, которое мы применяем, состоит в том, что master всегда должно быть развертываемым. Для этого в моей компании мы используем GitHub Flow. Возможно, стоит рассмотреть унифицированный способ работы с Git и развертыванием.