GitHub и система управления версиями Git, на которой он основан, являются фантастическими инструментами для управления проектами и совместной работы над ними — на основе кода или другими способами.
В этой статье мы рассмотрим варианты для того, чтобы проекты Git и GitHub лучше вписывались в рабочие процессы разработчиков, обеспечивая плавный и практичный
процесс развертывания.
Я разделю эти параметры на различные типы доступных наборов инструментов, которые позволяют использовать опции от автоматического запуска тестов и проверок кода до развертывания вашего кода на сервере.
Зачем это делать?
Когда эти автоматизированные процессы запущены и работают, вы и ваша команда можете сосредоточиться исключительно на кодировании, утверждении и объединении кода, а не тратить часы на развертывание и повторяющиеся задачи каждый раз, когда новая сборка или изменение готовы.
Недостатки автоматизации
Основная проблема с автоматическим развертыванием изменений заключается в том, что изменения автоматически внедряются. Вы должны доверять своей команде и коду, который они пишут. Вот почему автоматическое развертывание обычно сопряжено с автоматическим тестированием, и инструменты, представленные ниже, отражают это.
Конечно, это также означает, что любые мелкие проблемы также быстро решаются. Автоматизация должна быть в паре с коммуникацией. Если отправка в основную ветвь репозитория может привести к активным сборкам, это должно быть ясно, когда это произойдет, и кто может это сделать.
Начальная настройка процесса автоматизации может занять некоторое время, чтобы получить право. Важно взвесить, действительно ли это нужно вашей команде или рабочему процессу. Сложите количество времени, которое вы тратите на тестирование и развертывание новых сборок — и если это каждый раз больше, чем несколько минут, то оно того стоит.
Git Hooks
Git имеет набор встроенных хуков, которые можно использовать для автоматизации, и они часто являются нашим первым портом вызова для обработки задач после определенных действий Git. Они делятся на серверные и клиентские хуки.
Перехватчики на стороне сервера предназначены для таких событий, как прослушивание сетевых операций, например, когда репозиторий получает push. Хуки на стороне клиента запускаются при действиях, которые происходят на компьютере разработчика, таких как коммиты и слияния.
В документации Git есть полный список хуков. Я посмотрю на пару здесь, чтобы вы начали. Надеюсь, вы начнете понимать, как они могут быть полезны в ваших собственных проектах и текущих (ручных) рабочих процессах. Хуки — это файлы, которые могут содержать команды на любом языке, на котором может работать хост-система, что обеспечивает большую мощность и гибкость.
pre-commit
Этот хук на стороне клиента запускается до любого другого хука и до того, как будут зафиксированы какие-либо изменения. Это идеальное место для запуска тестов или других проверок вашего кода.
Давайте добавим немного базового JavaScript в наш небольшой проект (и да, здесь есть преднамеренная ошибка):
document.onload = function() { alert("Hello World") };
Мы будем использовать JSHint для проверки JavaScript на наличие ошибок. (Вы можете найти инструкции по установке здесь .)
Переименуйте hooks/pre-commit.sample в 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 репозиторий, указав флаг --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, поэтому не забудьте изменить пути в соответствии с вашими настройками .
Эта команда извлечет текущий репозиторий в указанный рабочий каталог, но без каких-либо данных контроля версий.
Нам нужно сделать исполняемый хук:
chmod +x post-receive
На локальном компьютере клонируйте репозиторий в обычном режиме, используя выбранный вами инструмент, и добавьте новый пульт для живого сервера (не забудьте изменить сведения о сервере на свой веб-сервер и данные пользователя):
git remote add prod ssh://[email protected]/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 или непрерывной интеграции. :
Сервисы непрерывной интеграции (CI)
Существует множество сервисов, которые могут следить за изменениями в ваших репозиториях GitHub и не только развертывать их для вас, но и выполнять другие функции, такие как запуск тестов и сборочные процессы для вас.
Переходя к новому и более сложному примеру, мы могли бы использовать CI для автоматизации процесса сборки проекта. Во-первых, потянув ветку Master репозитория, запустив bash-скрипт для запуска процесса сборки и развертывания, а затем напишу об обновлениях. CI и веб-службы могут находиться на одном сервере или на разных серверах в зависимости от ваших предпочтений.
Давайте кратко рассмотрим некоторые из самых популярных.
Дженкинс
Вам нужно будет настроить свой собственный сервер Jenkins, что означает, что вы получаете полный контроль, но это требует обслуживания. К счастью, он поддерживает множество платформ, включая Docker, если вы просто хотите сначала поэкспериментировать.
Jenkins достигает большей части своей функциональности с помощью плагинов, а благодаря своему возрасту, природе и популярности с открытым исходным кодом у него много плагинов. Например, есть плагины для Git , GitHub и Twitter .
Дженкинсу требуется много настроек, и иногда составление инструкций, необходимых для построения желаемого рабочего процесса, может потребовать много исследований.
Travis
Опять же, инструкции по интеграции Travis с GitHub устарели в документации GitHub. Теперь это еще проще: прочитайте документы Travis, чтобы узнать больше.
Travis не требует установки хостинга или сервера, поэтому, если вы хотите попробовать CI, не тратя слишком много времени на настройку, это хорошая отправная точка. Однако расширение его за пределы (всесторонних) интеграций по умолчанию потребует дополнительной настройки. Например, Tweeting требует доступа к веб- хукам .
У Трэвиса есть привычка медлительно замечать обновления в ваших репозиториях — особенно в своем собственном файле конфигурации. Эти проблемы могут быть трудно решить, так как у вас нет доступа к самому серверу Travis.
Другие коммерческие услуги
Непрерывная интеграция становится все более популярной, поэтому появилось множество новых сервисов и приложений, многие из которых были выпущены создателями инструментов, которые вы, возможно, уже используете, и которые будут плотно вписываться в существующие цепочки инструментов и рабочие процессы. Вот некоторые примеры:
- https://buddy.works/
- https://www.atlassian.com/software/bamboo/
- https://www.jetbrains.com/teamcity/
- https://codeship.com/
- https://circleci.com/
- https://saucelabs.com/
- https://about.gitlab.com/gitlab-ci/
- http://deploybot.com/
Заворачивать
Надеемся, что это краткое введение прояснило для вас несколько вещей относительно того, как работает этот тип развертывания. Мы, безусловно, прошли долгий путь со времени отправки файлов по FTP на ваш сервер!
Если у вас есть какие-либо вопросы о процессах, описанных выше, пожалуйста, дайте мне знать в комментариях.