От нуля к развертыванию

Ветвление, редактирование, фиксация, объединение

Если вы следовали за шагами в Разделе 1.3.4, вы могли заметить, что GitHub автоматически показывает содержание файла README на основной странице репозитория. В нашем случае, так как проект сгенерирован с использованием команды rails файл README – тот, что поставляется с Rails ( рис. 1.8). Благодаря расширению файла .rdoc, GitHub знает что он имеет правильный формат, но его содержимое совершенно бесполезно, так что в этом разделе мы сделаем наше первое редактирование, изменив README с тем чтобы он описывал наш проект, а не фреймворк на котором он написан. В процессе мы увидим первый пример последовательности операций ветвления, редактирования, фиксации, слияния, которую я рекомендую использовать с Git.

Рис. 1.8. Начальный (и довольно бесполезный) файл README для нашего проекта на GitHub.

Git невероятно хорош в создании веток, которые фактически являются копиями репозитория, где мы можем произвести (возможно экспериментальные) изменения, не модифицируя родительские файлы. В большинстве случаев родительский репозиторий – master ветка, и мы можем создать новую рабочую ветку используя checkout с флагом -b:

$ git checkout -b modify-README
Switched to a new branch 'modify-README'
$ git branch
master
* modify-README

Здесь вторая команда, git branch, только перечисляет все локальные ветки, а звездочка * указывает, какая ветка в настоящий момент включена. Отметьте, что git checkout -b modify-README одновременно и создает новую ветку и переключает на нее, на что указывает звездочка перед modify-README веткой. (Если вы настроили алиас co в Разделе 1.3, можете использовать git co -b modify-README вместо этого.)

Полностью оценить достоинства ветвления можно только работая над проектом совместно с множеством разработчиков,^{18См. главу Git Branching в Pro Git для получения более подробной информации.} но ветки полезны даже для учебника единственного разработчика, такого как этот. В частности ветка master изолируется от любых изменений, которые мы производим в ветке посвященной определенной теме, так что даже если мы действительно наворотили лишнего, мы можем всегда отказаться от изменений, вернувшись в master ветку и удалив ветку в которой мы работали до этого. Мы увидим, как сделать это в конце раздела.

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

Редактирование

После создания локальной ветки мы отредактируем его (файл readme), чтобы сделать немного более наглядным. Мне нравится использовать язык разметки Markdown для этих целей и если вы будете использовать расширение файла .markdown тогда GitHub будет автоматически форматировать его в приятный для вас вид. Итак, сначала мы будем использовать Git версию Unix команды mv ("move"), чтобы изменить название, а затем заполним его содержимым Листинга 1.8:

$ git mv README.rdoc README.md
$ subl README.md

# Ruby on Rails Tutorial: первое приложение

Это первое приложение для
[*Ruby on Rails Tutorial*](http://railstutorial.org/)
 [Майкл Хартл](http://michaelhartl.com/).

Фиксация

С произведенными изменениями мы можем посмотреть статус нашей ветки:

$ git status
# On branch modify-README
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       renamed:    README.rdoc -> README.md
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   README.md

В этой точке мы могли бы использовать git add . как в Разделе 1.3.2, но Git предусматривает флаг -a как сокращение для (очень частого) случая фиксации всех изменений к существующим файлам (или файлов, созданных с использованием git mv, которые не считаются новыми для Git):

$ git commit -a -m "Improve the README file"
2 files changed, 5 insertions(+), 243 deletions(-)
delete mode 100644 README.rdoc
create mode 100644 README.md

Будьте осторожны с использованием флага -a; если вы добавили какие-либо новые файлы в проект после последней фиксации, вы должны сообщить Git о них используя сначала git add.

Обратите внимание, что мы написали сообщение коммита в настоящем времени. Git моделирует коммиты как серии правок существующего кода и в этом контексте имеет смысл описать что каждый коммит делает, нежели что он делал. Кроме того, такое использование соответствует сообщениям о коммитах генерируемых самой командой Git. Более подробно об этом можно почитать из GitHub поста Shiny new commit styles.

Объединение

Теперь, когда мы закончили производить наши изменения, мы готовы объединить результаты с нашей master веткой:

$ git checkout master
Switched to branch 'master'
$ git merge modify-README
Updating 34f06b7..2c92bef
Fast forward
README.rdoc     |  243 --------------------------------------------------
README.md       |    5 +
2 files changed, 5 insertions(+), 243 deletions(-)
delete mode 100644 README.rdoc
create mode 100644 README.md

Отметьте, что вывод Git часто включает такие вещи как 34f06b7, которые связаны с внутренним представлением Git репозиториев. Ваши конкретные результаты будут отличаться в этих деталях, но остальное по своей сути должно соответствовать выводу, показанному выше.

После того, как вы объединили изменения, вы можете почистить свои ветки, стерев локальную ветку, используя git branch -d если вы с ней (веткой) закончили:

$ git branch -d modify-README
Deleted branch modify-README (was 2c92bef).

Этот шаг не является обязательным, и, фактически, это довольно распространено - оставлять рабочие ветки нетронутыми. Это позволяет переключаться между рабочей и master ветками, объединяя изменения каждый раз, когда вы достигаете естественной точки остановки.

Как упомянуто выше, вы также можете отказаться от изменений, относящихся к рабочей ветке, в таком случае используйте git branch -D:

# Только для иллюстрации; не делайте этого,
  если планируете в дальнейшем пользоваться веткой
$ git checkout -b topic-branch
$ <really screw up the branch>
$ git add .
$ git commit -a -m "Major screw up"
$ git checkout master
$ git branch -D topic-branch

В отличие от флага -d, флаг -D сотрет ветку даже если мы не объединили изменения.

Отправка

Теперь, когда мы обновили README, мы можем отправить изменения в GitHub чтобы увидеть результат. Так как мы уже сделали одну отправку (Раздел 1.3.4), на большинстве систем, мы теперь можем опустить origin master, и просто выполнить git push:

$ git push

Как и обещалось, GitHub приятно форматирует новый файл, используя Markdown ( рис. 1.9).

Рис. 1.9. Улучшенный файл README форматированный в Markdown.

Развертывание

Даже на этой ранней стадии, мы уже собираемся развернуть наше (все еще пустое) приложение Rails в production (# -окружение используемое когда вы разворачиваете ваше приложение для всеобщего использования). Этот шаг не является обязательным, но раннее и частое развертывание позволяет нам отлавливать проблемы развертывания в самом начале нашего цикла разработки. Альтернативный вариант - развертывание только после напряженных усилий изолированных в окружении разработки (development environment) - часто приводит к ужасным головным болям при интегрировании, когда приходит время запуска.^{19 Хотя это и не должно иметь значения для примеров приложений в Учебнике Rails, если вы волнуетесь по поводу случайного и/или преждевременного обнародования вашего приложения, есть несколько способов, которые могут помочь вам избежать этого; Один из них описан в Разделе 1.4.4.}

Раньше развертывание Rails-приложений было довольно болезненной процедурой, но экосистема развертывания Rails, стремительно развивалась в течение нескольких последних лет и теперь имеет различные замечательные опции. Они включают общедоступные хосты или виртуальные выделенные серверы, использующие Phusion Passenger (модуль для веб-серверов Apache и Nginx^{20Произносится "Engine X".} , компании предоставляющие полный комплекс услуг развертывания, такие как Engine Yard и Rails Machine, и облачные сервисы развертывания, такие как Engine Yard Cloud и Heroku.

Моим любимым сервисом для развертывания Rails является Heroku, который является хостинговой платформой, созданной специально для того, чтобы разворачивать Rails и другие Ruby веб-приложения. Heroku делает развертывание Rails приложений смехотворно легким - пока ваш исходный код находится в системе управления версиями Git. (Это - еще одна причина выполнить шаги установки Git из Раздела 1.3 если вы этого еще не сделали.) Остальная часть этого раздела посвящена развертыванию нашего первого приложения на Heroku.

Установка Heroku

Heroku использует базу данных PostgreSQL (произносится "post-gres-cue-ell", и часто называется "Postgres"), это означает что нам нужно добавить гем pg в production окружение для того чтобы позволить Рельсам общаться с Postgres

group :production do
  gem 'pg', '0.15.1'
  gem 'rails_12factor', '0.0.2'
end

Обратите внимание на добавившийся гем rails_12factor, который Heroku использует для работы со статическими ассетами, такими как изображения и таблицы стилей.

Как было отмечено в Разделе 1.2.4, хорошей идеей является явное указание ожидаемой нашим приложением версии Ruby:

ruby '2.0.0'
#ruby-gemset=railstutorial_rails_4_0

(Здесь я для удобства также добавил необязательную строку с RVM гемсетом. Вам следует заменить ’2.0.0’ на ’1.9.3’ если вы используете Ruby 1.9.3.) Применение этих изменений к Gemfile из Листинга 1.5 приводит к Листингу 1.9.

source 'https://rubygems.org'
ruby '2.0.0'
#ruby-gemset=railstutorial_rails_4_0

gem 'rails', '4.0.2'

group :development do
  gem 'sqlite3', '1.3.8'
end

gem 'sass-rails', '4.0.1'
gem 'uglifier', '2.1.1'
gem 'coffee-rails', '4.0.1'
gem 'jquery-rails', '3.0.4'
gem 'turbolinks', '1.1.1'
gem 'jbuilder', '1.0.2'

group :doc do
  gem 'sdoc', '0.3.20', require: false
end

group :production do
  gem 'pg', '0.15.1'
  gem 'rails_12factor', '0.0.2'
end

Для того чтобы установить его, мы запускаем bundle install со специальным флагом:

$ bundle install --without production

Опция --without production предотвращает локальную установку любых продакшен-гемов, в данном случае это pg и rails_12factor. (Если Bundler выдает ошибку связанную с readline, попробуйте добавить gem 'rb-read\-line', '~> 0.4.2' в ваш Gemfile.) Поскольку мы добавили только гемы для продакшен окружения, прямо сейчас эта команда не приведет к установке каких-нибудь локальных гемов, но это необходимо для добавления гемов pg и rails_12factor в Gemfile.lock. Мы можем закоммитить получившиеся изменения следующим образом:

$ git commit -a -m "Update Gemfile.lock for Heroku"

Некоторые читатели сообщили что для успешного развертывания на Heroku в этой точке им пришлось запустить локальную прекомпиляцию ассетов:

# Это должно быть использовано только если вы не можете задеплоить на Heroku.
$ rake assets:precompile
$ git add .
$ git commit -m "Add precompiled assets for Heroku"

(Здесь используется команда rake, о которую мы более подробно обсудим в Разделе 2.2.) Шаг прекомпиляции ассетов по идее не нужен и я не смог воспроизвести ситуацию в которой он был бы необходим, но количество получаемых сообщений об ошибках таково что я вынужден упомянуть здесь о решении.)

Затем мы должны создать и сконфигурировать новый Heroku аккаунт. Первый шаг это регистрация на Heroku; после подтверждения вашего email для завершения создания вашего аккаунта, установите необходимый для Heroku софт с помощью Heroku Toolbelt.^{21https://toolbelt.heroku.com/} Затем используйте команду heroku для входа в командную строку (для этого вам может понадобиться выйти и перезапустить ваш терминал):

$ heroku login

Наконец, перейдите в директорию вашего Rails проекта и используйте команду heroku для создания на Heroku серверах места под пример приложения (Листинг 1.10).

$ cd ~/rails_projects/first_app
$ heroku create
Created http://stormy-cloud-5881.herokuapp.com/ |
git@heroku.com:stormy-cloud-5881.herokuapp.com
Git remote heroku added

Команда heroku создает новый поддомен для нашего приложения, который незамедлительно доступен для просмотра. Однако там пока ничего нет, так что давайте займемся развертыванием.