GitHub, равно как и система контроля версий Git, на которой он основан, это фантастические инструменты для организации работы и взаимодействия в проектах, независимо от того, связаны эти проекты с кодом или нет.

В этой статье мы рассмотрим способы, позволяющие улучшить интеграцию Git и GitHub в рабочий процесс разработчиков, облегчая и механизируя процесс развертывания.

Я разделил все эти способы по типам используемых инструментов: отдельно инструменты для автоматического тестирования и отдельно проверяющие развертывание на сервере.

Зачем это нужно

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

Недостатки автоматизации

Основная проблема с автоматическим развертыванием изменений это и есть автоматическое развертывание изменений. У вас должна быть уверенность в своей команде и в написанном коде. Именно поэтому автоматическое развертывание обычно совмещается с автоматическим тестированием и это отразилось на представленных ниже инструментах.

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

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

Хуки Git

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

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

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

Хук pre-commit

Клиентский хук запускается до любого другого хука и до коммита любых изменений. Это лучшее место для добавления тестов и прочих проверок вашего кода.

Добавим простой код JavaScript (в котором мы заранее сделали ошибку) в наш небольшой проект:

document.onload = function() {
    alert("Hello World")
};

Мы будем использовать JSHint для выявления ошибок в JavaScript ( инструкция по установке JSHint).

Переименуем файл hooks/pre-commit.sample (этот файл расположен в скрытом каталоге .git вашего проекта) в hooks/pre-commit` и изменим содержимое этого файла на следующее:

#!/bin/sh
jshint index.js

Попытаемся сделать коммит изменений:

$ git commit -m "adding Javascript file"

И получим следующее сообщение об ошибке:

index.js: line 5, col 25, Missing semicolon.
1 error

Добавим недостающую точку с запятой и попытаемся еще раз. Коммит пройдет без каких-либо проблем.

Хук post-receive

Этот серверный хук срабатывает после завершения получения переданных изменений в удаленном Git-репозитории. В нашем примере, мы передаем последнюю версию нашего простого сайта в каталог веб-сервера для развертывания.

У меня есть существующий сайт, состоящий из index.html и нескольких страниц еще, которые мы будем использовать в следующих примерах. Вы можете создать свой сайт или использовать пример из демо-репозитория.

Клонируйте репозиторий, используя флаг --bare, чтобы в репозитории была только информация из системы контроля версий, а не наш код:

$ git clone --bare https://github.com/sitepoint-editors/GitHub-Auto-Deploy.git GitHub-Auto-Deploy.git

Теперь создадим хук:

$ cd GitHub-Auto-Deploy.git/hooks
$ vi post-receive

Добавим в файл с хуком следующие строчки:

#!/bin/sh
git --work-tree=/var/www/html --git-dir=/var/repo/GitHub-Auto-Deploy.git checkout -f

Примечание: указаны рабочие каталоги в Ubuntu, в вашей системе они могут отличаться.

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

Нам надо сделать наш хук выполняемым:

$ sudo chmod +x post-receive

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

$ git remote add prod ssh://user@domain.com/var/repo/GitHub-Auto-Deploy.git

Для развертывания на рабочий сервер вместо репозитория введите:

$ git push prod master

Если вы посмотрите теперь в каталог var/www/html, то вы найдете там автоматически скопированный файл index.html.

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

Один из вариантов это использование команд rsync или scp в хуке post-receive на GitHub. Другой вариант, особенно, если ваше приложение нуждается в процессе сборки перед запуском (Github ограничивает доступные команды) — это использование хука post-receive для запуска скриптов на сервере приложения, проверяющего код на GitHub (с опцией -f) и запускающему остальные необходимые команды. Как видите, все стало несколько сложнее, нам пора перейти к следующему набору инструментов.

Автоматическое развертывание непосредственно с GitHub

На GitHub есть документация об автоматизации развертывания на платформы интеграции, некоторые из которых также являются хостинг-провайдерами.

Буду честным, большая часть изученной мной документации оказалась некорректной, неточной или бесполезной, поэтому я добавлю ссылки на документацию нескольких популярных хостинг-провайдеров, а для остальных я предлагаю вам использовать post-receive или методы непрерывной интеграции:

Сервисы непрерывной интеграции

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

Перейдя к новому и более сложному примеру, мы могли бы использовать сервис непрерывной интеграции для автоматизации процесса сборки проекта. В первую очередь после получения ветки Master из репозитория запускается скрипт bash, выполняющий сборку и развертывание, затем генерируется твит об обновлении. Сервис непрерывной интеграции может физически находится на одном сервере с веб-сервисом или на разных, в зависимости от ваших предпочтений.

Рассмотрим самые популярные из них.

Jenkins

Для использования вам надо настроить свой сервер с Jenkins, это даст вам полный контроль над ним, но заставит тратить время на поддержку. К счастью, Jenkins поддерживает многие платформы, в том числе Docker, если вы хотите для начала поэкспериментировать.

Большая часть функциональности Jenkins достигнута за счет плагинов, а благодаря сложившемуся за долгие годы open-source сообществу этих плагинов много. Например, есть плагины для Git, GitHub и Twitter.

Jenkins требует долгой настройки и временами совмещение всех имеющихся инструкций для создания подходящего рабочего процесса требует изучения.

Travis

Инструкции по интеграции с Travis, имеющиеся на GitHub, на данный момент устарели. Но решается это просто: для этого есть документация на сайте Travis.

Travis не требует какой-либо настройки сервера или хостинга, поэтому он подойдет тем, кто не хочет тратить на это время. Тем не менее, расширение его за пределы дефолтных настроек потребует дополнительного конфигурирования. Например, Tweeting требует доступ к веб-хукам.

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

Другие коммерческие сервисы

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

Заключение

Надеюсь, это краткое введение разъяснит вам отдельные вопросы, касающиеся работы развертывания. Мы определенно прошли долгий путь со времен отправки файлов на сервер с помощью FTP.

Источник: http://prgssr.ru/development/razvertyvanie-s-github-na-server.html

⤧  Next post Настройка экрана входа lightdm-gtk-greeter ⤧  Previous post Подсветка синтаксиса исходного кода на сайте