Автоматизация разработки и развертывания с помощью хуков Git

Cloud Server, Ubuntu, VPS | Amber | Комментировать запись

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

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

Данный мануал расскажет вам, что такое хуки git, и научит реализовать код, который поможет автоматизировать задачи в среде разработки.

Примечание: Данный мануал протестирован на сервере Ubuntu 14.04, но на других дистрибутивах он должен работать аналогичным образом.

Требования

• Установленная система контроля версий git (инструкции можно найти в мануале Установка Git на Ubuntu 14.04).
• Базовые навыки работы с git. Полезную информацию вы найдете в мануалах Продуктивное использование Git и Использование веток Git.

Что такое хуки Git?

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

Хуки Git работают на основе событий. Когда вы запускаете определенные команды git, программное обеспечение проверяет каталог hooks в репозитории git и ищет в нем соответствующий скрипт.

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

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

Книга Pro Git описывает разные хуки по категориям:

• Клиентские хуки: это хуки, которые вызываются и выполняются на компьютере коммиттера. Они, в свою очередь, делятся на несколько отдельных подкатегорий:
  • Хуки коммитов рабочего процесса: диктуют действия, которые необходимо предпринять во время отправки коммита. Они используются для запуска проверок состояния, предварительно заполняют сообщения о коммитах и проверяют детали сообщений. Вы также можете использовать эти хуки для предоставления уведомлений при отправке коммита.
  • Почтовые хуки: эта подкатегория включает действия, которые предпринимаются при работе с патчами, отправленными по электронной почте. Проекты, такие как ядро Linux, представляют и просматривают патчи, используя метод электронной почты. Они похожи на хуки коммитов, но могут использоваться сторонними компаниями, которые несут ответственность за применение кода.
  • Другие хуки: к этой подкатегории относятся все остальные клиентские хуки, которые выполняются при слиянии, проверке кода, перезагрузке, переписывании и очистке репозиториев.
• Серверные хуки: эти хуки выполняются на серверах, которые используются для загрузки кода. Как правило, это будет основной git-репозиторий проекта. Эти хуки также делятся на подкатегории:
  • Pre-receive и post-receive: выполняются на сервере, который получает задачу push, для выполнения таких действий, как проверка целостности проекта и развертывание.
  • Хуки обновления: похожи на pre-receive, но работают по принципу ветвления для выполнения кода перед принятием каждой ветки.

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

Некоторые хуки также принимают параметры. Это означает, что когда git вызывает скрипт хука, он передает некоторые релевантные данные, которые скрипт может затем использовать для выполнения задач. В этой таблице описаны доступные хуки:

Настройка репозитория

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

mkdir ~/proj
cd ~/proj
git init
Initialized empty Git repository in /home/demo/proj/.git/

Теперь вы находитесь в пустом рабочем каталоге, который контролирует git. Перейдите в репозиторий, который хранится в скрытом файле.git в этом каталоге:

cd .git
ls -F
branches/  config  description  HEAD  hooks/  info/  objects/  refs/

В нем вы увидите ряд файлов и каталогов. Найдите каталог hooks:

cd hooks
ls -l
total 40
-rwxrwxr-x 1 demo demo  452 Aug  8 16:50 applypatch-msg.sample
-rwxrwxr-x 1 demo demo  896 Aug  8 16:50 commit-msg.sample
-rwxrwxr-x 1 demo demo  189 Aug  8 16:50 post-update.sample
-rwxrwxr-x 1 demo demo  398 Aug  8 16:50 pre-applypatch.sample
-rwxrwxr-x 1 demo demo 1642 Aug  8 16:50 pre-commit.sample
-rwxrwxr-x 1 demo demo 1239 Aug  8 16:50 prepare-commit-msg.sample
-rwxrwxr-x 1 demo demo 1352 Aug  8 16:50 pre-push.sample
-rwxrwxr-x 1 demo demo 4898 Aug  8 16:50 pre-rebase.sample
-rwxrwxr-x 1 demo demo 3611 Aug  8 16:50 update.sample

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

Вторая вещь, которую следует отметить – это то, что все файлы заканчиваются на .sample. Это потому, что git просто смотрит на имя файла, пытаясь найти файлы хуков для выполнения. Нарушение конвенции по именованию фалов git отключает скрипт. Чтобы включить любой из скриптов в этом каталоге, нужно удалить суффикс .sample.

Вернитесь в рабочий каталог:

cd ../..

Развертывание на локальный веб-сервер с помощью хука post-commit

В первом примере будет использоваться хук post-commit, который может развернуть код на локальном сервере после каждого коммита. Этот хук не стоит использовать для производственной среды, но он позволяет вам просмотреть важные, но плохо задокументированные элементы, о которых вы должны знать.

Для начала установите веб-сервер Apache:

sudo apt-get update
sudo apt-get install apache2

Чтобы скрипт изменил корневой каталог веб-сайта /var/www/html (это document root по умолчанию в Ubuntu 14.04, при необходимости измените его), нужно иметь права на запись. Измените права собственности на каталог:

sudo chown -R `whoami`:`id -gn` /var/www/html

Теперь создайте файл index.html:

cd ~/proj
nano index.html

В файл нужно добавить простой HTML.

<h1>Here is a title!</h1>
<p>Please deploy me!</p>

Добавьте новый файл, чтобы git мог отслеживать файл:

git add .

Теперь, прежде чем отправить коммит, нужно настроить хук post-commit для репозитория. Создайте этот файл в каталоге .git/hooks проекта:

vim .git/hooks/post-commit

Прежде чем добавить что-либо в этот файл, нужно немного узнать о том, как git устанавливает среду при запуске хуков.

Кратко о переменных среды и хуках git

Прежде чем начать работу со скриптом, нужно понять, какие переменные среды git задает при вызове хуков. Чтобы заставить скрипт работать, в конечном итоге нужно будет отключить переменную среды, которую git задает при вызове хука post-commit.

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

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

К счастью, Марк Лонгэйр разработал метод тестирования каждой из переменных, которые git устанавливает при запуске хуков. Этот метод включает в себя следующие строки в различных скриптах хуков git:

#!/bin/bash
echo Running $BASH_SOURCE
set | egrep GIT
echo PWD is $PWD

Примечание: Версия может отличаться.

Ниже приведены результаты тестов этой версии git (включая рабочий каталог, который git просматривает при запуске каждого хука). Локальным рабочим каталогом для тестирования /home/demo/test_hooks, а пустым удаленным каталогом был /home/demo/origin/test_hooks.git.

• Хуки: applypatch-msg, pre-applypatch, post-applypatch

• • Переменные среды:
  • GIT_AUTHOR_DATE=’Mon, 11 Aug 2014 11:25:16 -0400′
  • GIT_AUTHOR_EMAIL=demo@example.com
  • GIT_AUTHOR_NAME=’Demo User’
  • GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
  • GIT_REFLOG_ACTION=am
  • Рабочий каталог: /home/demo/test_hooks
• Хуки: pre-commit, prepare-commit-msg, commit-msg, post-commit
  • Переменные среды:
  • GIT_AUTHOR_DATE=’@1407774159 -0400′
  • GIT_AUTHOR_EMAIL=demo@example.com
  • GIT_AUTHOR_NAME=’Demo User’
  • GIT_DIR=.git
  • GIT_EDITOR=:
  • GIT_INDEX_FILE=.git/index
  • GIT_PREFIX=
  • Рабочий каталог: /home/demo/test_hooks
• Хуки: pre-rebase
  • Переменные среды:
  • GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
  • GIT_REFLOG_ACTION=rebase
  • Рабочий каталог: /home/demo/test_hooks
• Хуки: post-checkout
  • Переменные среды:
  • GIT_DIR=.git
  • GIT_PREFIX=
  • Рабочий каталог: /home/demo/test_hooks
• Хуки: post-merge
  • Переменные среды:
  • GITHEAD_4b407c…
  • GIT_DIR=.git
  • GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
  • GIT_PREFIX=
  • GIT_REFLOG_ACTION=’pull other master’
  • Рабочий каталог: /home/demo/test_hooks
• Хуки: pre-push
  • Переменные среды:
  • GIT_PREFIX=
  • Рабочий каталог: /home/demo/test_hooks
• Хуки: pre-receive, update, post-receive, post-update
  • Переменные среды:
  • GIT_DIR=.
  • Рабочий каталог: /home/demo/origin/test_hooks.git
• Хуки: pre-auto-gc
  • (неизвестно, так как его сложно надежно запустить)
• Хуки: post-rewrite
  • Переменные среды:
  • GIT_AUTHOR_DATE=’@1407773551 -0400′
  • GIT_AUTHOR_EMAIL=demo@example.com
  • GIT_AUTHOR_NAME=’Demo User’
  • GIT_DIR=.git
  • GIT_PREFIX=
  • Рабочий каталог: /home/demo/test_hooks

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

Работа над скриптом

Теперь, когда у вас есть представление о среде, можно начать писать скрипт.

Поскольку git-хуки являются стандартными скриптами, нужно сказать git, какой интерпретатор использовать:

#!/bin/bash

После этого можно использовать git для распаковки последней версии репозитория после коммита в каталоге веб-сервера. Чтобы сделать это, нужно сделать корневой каталог Apache рабочим каталогом. Также нужно установить каталог git в репозитории.

Нужно убедиться в том, что каждая такая транзакция прошла успешно, даже если содержимое рабочего каталога конфликтует:

#!/bin/bash
git --work-tree=/var/www/html --git-dir=/home/demo/proj/.git checkout -f

Хук почти готов. Теперь нужно сфокусироваться на переменных среды, которые устанавливаются каждый раз при запуске хука post-commit. В частности GIT_INDEX_FILE имеет значение .git/index.

Этот путь связан с рабочим каталогом, в этом случае с /var/www/html. Поскольку git index не существует в этом месте, скрипт выдаст ошибку, если оставить все как есть. Чтобы избежать этой ситуации, можно вручную отключить эту переменную. Добавьте в сценарий такую строку:

#!/bin/bash
unset GIT_INDEX_FILE
git --work-tree=/var/www/html --git-dir=/home/demo/proj/.git checkout -f

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

Сохраните и закройте файл.

Сделайте файл исполняемым:

chmod +x .git/hooks/post-commit

Теперь, наконец, можно зафиксировать в коммите изменения, которые вы сделали в нашем репозитории git. Убедитесь, что вы вернулись в правильный каталог, а затем зафиксируете изменения:

cd ~/proj
git commit -m "here we go..."

Если вы теперь посетите доменное имя или IP-адрес своего сервера в браузере, вы увидите созданный файл index.html:

http://server_domain_or_IP
Here is a title!
Please deploy me!

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

echo "<p>Here is a change.</p>" >> index.html
git add .
git commit -m "First change"

Снова откройте браузер. Теперь вы увидите:

Here is a title!
Please deploy me!
Here is a change.

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

Развертывание на отдельном сервере производства с помощью хуков

В этом примере мы продемонстрируем лучший способ обновления производственного сервера. Сделать это можно с помощью модели push-to-deploy, которая будет обновлять веб-сервер после каждой загрузки в пустой репозиторий git.

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

На производственной машине создайте еще один веб-сервер, простой репозиторий git, в который будут вноситься изменения, и git-хук, который будет выполняться всякий раз, когда будет получен push-сигнал.

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

Настойка хука post-receive

На сервере производства установите веб-сервер.

sudo apt-get update
sudo apt-get install apache2

Передайте права на document root текущему пользователю:

sudo chown -R `whoami`:`id -gn` /var/www/html

Установите git на эту машину:

sudo apt-get install git

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

mkdir ~/proj
cd ~/proj
git init --bare

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

Теперь нужно создать еще один хук git. На этот раз нужен хук post-receive, который запускается на сервере, получающем git push. Откройте этот файл в редакторе:

nano hooks/post-receive

Опять же, начать нужно с определения типа скрипта. После этого можно добавить ту же команду проверки, которую вы использовали в файле post-commit, нужно только обновить пути:

#!/bin/bash
git --work-tree=/var/www/html --git-dir=/home/demo/proj checkout -f

Поскольку это пустой репозиторий, параметр –git-dir должен указывать на каталог верхнего уровня этого репозитория.

Также нужно добавить в скрипт дополнительную логику. Если вы случайно загрузите на этот сервер ветку test-feature, ее развертывать не нужно. Этот сервер должен собирать только ветку master.

Возможно, вы заметили в таблице для post-receive, что git передает хэш коммита старой ревизии, хэш коммита новой ревизии и ссылку, которая вставляется в скрипт как стандартный ввод. Это можно использовать, чтобы проверить, является ли ref главной веткой или нет.

Сначала нужно прочитать стандартный ввод. Для каждой загруженной ссылки в качестве стандартного ввода в сценарий будут загружаться три фрагмента информации (старая ревизия, новая ревизия, ссылка), разделенные пробелом. Эти данные можно прочитать с помощью цикла while:

#!/bin/bash
while read oldrev newrev ref
do
git --work-tree=/var/www/html --git-dir=/home/demo/proj checkout -f
done

Итак, теперь у вас есть три переменных, основанных на загруженных данных. Для загрузки ветки master объект ref будет содержать данные типа refs/heads/master. Проверьте, поддерживает ли этот формат объект ref, который получает сервер, с помощью if:

#!/bin/bash
while read oldrev newrev ref
do
if [[ $ref =~ .*/master$ ]];
then
git --work-tree=/var/www/html --git-dir=/home/demo/proj checkout -f
fi
done

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

Теперь нужно добавить текст, описывающий текущую ситуацию и предпринятые действия. Добавьте блок else, чтобы уведомить пользователя о том, что данные в не master ветку добавлены успешно, даже если действие не приведет к развертыванию:

#!/bin/bash
while read oldrev newrev ref
do
if [[ $ref =~ .*/master$ ]];
then
echo "Master ref received.  Deploying master branch to production..."
git --work-tree=/var/www/html --git-dir=/home/demo/proj checkout -f
else
echo "Ref $ref successfully received.  Doing nothing: only the master branch may be deployed on this server."
fi
done

Сохраните и закройте файл.

Сделайте скрипт исполняемым:

chmod +x hooks/post-receive

Настройка удаленного сервера на клиентской машине

Вернитесь на клиентский сервер (разработки) и откройте этот каталог:

cd ~/proj

Добавьте в файл удаленный сервер как production. Вам нужно знать имя пользователя, которое вы использовали на сервере производства, а также его IP-адрес или доменное имя. Вам также необходимо знать местоположение репозитория по отношению к домашнему каталогу пользователя. Команда будет иметь примерно такой вид:

git remote add production demo@server_domain_or_IP:proj

Загрузите текущую ветку master на сервер производства:

git push production master

Если у вас не настроены SSH-ключи, вам может потребоваться ввести пароль пользователя вашего сервера производства. Вы должны увидеть примерно такой вывод:

Counting objects: 8, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 473 bytes | 0 bytes/s, done.
Total 4 (delta 0), reused 0 (delta 0)
remote: Master ref received.  Deploying master branch...
To demo@107.170.14.32:proj
009183f..f1b9027  master -> master

Как видите, в выводе команды находится текст хука post-receive. Если вы посетите доменное имя или IP-адрес производственного сервера в веб-браузере, вы увидите текущую версию проекта:

Here is a title!
Please deploy me!
Here is a change.

Похоже, хук успешно загрузил код в производство.

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

Создайте новую ветку test_feature и проверьте ее:

git checkout -b test_feature

Сейчас вы работаете в ветке test_feature. Теперь внесите изменения, которые, возможно, будут загружены в производство. Зафиксируйте их в этой ветке.

echo "<h2>New Feature Here</h2>" >> index.html
git add .
git commit -m "Trying out new feature"

Теперь откройте IP или домен машины производства в браузере. Вы увидите:

Here is a title!
Please deploy me!
Here is a change.
New Feature Here

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

Вы можете выгрузить ветку test_feature на удаленный сервер:

git push production test_feature

Вы увидите новое сообщение от хука post-receive:

Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 301 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Ref refs/heads/test_feature successfully received.  Doing nothing: only the master branch may be deployed on this server
To demo@107.170.14.32:proj
83e9dc4..5617b50  test_feature -> test_feature

Если вы снова запустите сервер производства в браузере, вы увидите, что ничего не изменилось. Это ожидаемое поведение, поскольку загруженное изменение не было в ветке master.

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

git checkout master
git merge test_feature

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

git push production master

В браузере введите домен или IP-адрес сервера производства, и вы увидите:

Here is a title!
Please deploy me!
Here is a change.
New Feature Here

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