Рабочий процесс Git / Rails / Shared Hosting (Dreamhost) - PullRequest
Новая
       10

Рабочий процесс Git / Rails / Shared Hosting (Dreamhost)

4 голосов
/ 07 августа 2009

Это в первую очередь вопрос об эффективном использовании Git. Сначала я должен сказать, что я не специалист по Rails (по крайней мере, в производственном смысле) и определенно новичок в Git, однако у меня был некоторый опыт использования SVN.

Моя проблема в том, что я пытаюсь создать приложение rails, но не знаю, как лучше сохранить локальную разработку на моем компьютере, но могу развернуть ее на моей учетной записи общего хостинга на Dreamhost.

Я подумал, что Git позволит мне это сделать, но я не совсем уверен, как. Я думал о создании репозитория Git на сервере и о том, чтобы мои локальные вещи помещались на него после каждого коммита. Я прочитал несколько уроков по Git, но все еще не понимаю, что делать. Альтернативой этому было бы просто использовать FTP и копировать файлы, но это кажется неправильным.

У кого-нибудь есть несколько первых шагов и / или команд, которые я могу использовать? Этот метод развертывания сомнительный или есть лучший способ сделать это?

Ответы [ 3 ]

8 голосов
/ 29 июня 2010

Я управляю сайтом Rails для духового оркестра в Висконсине в настройке, очень похожей на то, что вы описываете, хотя в настоящее время он работает на hostingrails.com. Я размещаю свой код на github , хотя нет никаких причин, по которым вы не можете разместить его в частном порядке. Мой поток развился за последние полтора года, поэтому возьмите из этого только то, что вам нужно в краткосрочной перспективе.

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

Мой рабочий процесс сохраняет как минимум 2 ветви :

  • current_release: Код живого производства. Аварийные исправления сделаны здесь.
  • master: Готовые функции готовы к выпуску. Эти функции ждут здесь, чтобы быть протестированными вживую. Аварийные исправления объединяются с current_release.
  • <feature_name>: Возможности в разработке. Я стараюсь не иметь более 3 таких выдающихся в любой момент времени. Аварийные исправления объединяются, и master часто объединяется для поддержания актуальности функции.

Наличие этой настройки позволяет мне работать над несколькими вещами одновременно. Неделя за неделей (поскольку это далеко не занятие на полный рабочий день), я делаю следующее:

  1. Я редактирую в тематических ветках. Я переключаюсь назад и вперед, скучаю, волнуюсь, что угодно. Иногда я объединяю две функции, которые растут вместе.

    [edit]<br> $ git commit<br> $ git push github [feature]

  2. Готовые функции, готовые к предстоящему развертыванию, поочередно объединяются с веткой master.

    $ git checkout master<br> $ git merge [feature]<br> [fix immediate problems or inconsistencies]<br> $ git commit<br> $ git push github master<br> $ git branch -d [feature]

  3. Я размещаю веб-сайт по частному URL (случается, это stage.madisonbrass.com). Среда staging всегда вытягивается из ветви master.

    $ cap staging deploy # <code>master теперь доступен на stage.madisonbrass.com

  4. Бэм, пока я тестирую, я обнаружил аварийную ошибку на общедоступном веб-сайте. К счастью, у меня current_release работает отдельно, и поэтому я могу отдельно исправить и развернуть его.

    $ git checkout current_release<br> [fix bug]<br> $ git commit<br> $ git push github current_release<br> $ cap production deploy

  5. Я возвращаюсь в ветку master и начинаю с объединения аварийного исправления.

    $ git checkout master<br> $ git merge current_release

  6. Я продолжаю тестирование master. Надеемся, что новые проблемы не появятся, но если они исправятся, я исправлю их в master, я объединю эти изменения в current_release и выполню другое развертывание.

    $ git checkout current_release<br> $ git merge master<br> $ git push github current_release<br> $ cap production deploy

  7. Я разрушаю свою промежуточную среду, чтобы она не попала в указатель поисковой системы.

    $ git staging teardown

4 голосов
/ 07 августа 2009

То, что я делаю, - это общий, пустой Git-репозиторий (созданный с помощью git init --shared --bare), который является «основным» репозиторием и где я запускаю свою работу. Пустой репозиторий не имеет рабочего каталога. Для моего веб-каталога я клонирую главный репозиторий, чтобы у него был рабочий каталог, и все файлы были там. Оттуда я git pull любую новую работу, которую я совершил.

Я всегда занимаюсь разработкой на отдельной машине с клоном репозитория и тестовой средой разработки. Когда я заканчиваю функцию, я помещаю ее на мастер, а затем захожу на рабочий сервер и перетаскиваю ее в рабочий каталог.

Это только я для не очень важных проектов. Это можно расширить еще множеством шагов, проверок и противовесов для важной работы.

0 голосов
/ 07 августа 2009

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

Мой обычный рабочий процесс включает в себя среду разработки и учетную запись GitHub. Мы используем Capistrano (который довольно прост для изучения и понимания), чтобы управлять отправкой на GitHub, а затем соответствующим развертыванием на хостинге, в вашем случае Dreamhost, через SSH / SCP.

Таким образом, вам не придется беспокоиться о том, что на самом деле находится в вашем производственном репозитории, а также о том, что вам не нужно выполнять задачи по его обслуживанию. Работает также довольно быстро и может быть легко адаптирован для случаев, когда вы решите сменить хостинг на сервере.

...