#git #развертывание
Первый раз работаю в небольшой команде на внутрикорпоративном проекте. Изучить гит
более-менее осилил. Теперь мучаюсь с деплоем. Суть такова:
Используем стандартную схему веток (master, develop, topic). Программируем и верстаем
у себя на локалке. Есть боевой сервер. Он же и git-сервер. Он же и тестовый сервер
:) Сервер содержит 2 веб-приложения. Первое мы пуллим из master-ветки — релиз готов,
второе — из develop — тестируем, прежде чем мастер пулить.
Так вот, чтобы банально выложить малюсенькое изменение feature ветки в продакшн (или
хотя бы в тест) мне приходится превозмогать рутину:
Переключиться с feature на develop, обновить ветку.
Смержить feature, запушить develop
Переключиться на master, обновить её
Смержить develop, запушить master
Подключиться к боевому серверу сделать пулл на develop-приложении
Подключиться к боевому серверу сделать пулл на master-приложении
???
"А тут ещё букву поправьте, пожалуйста"
goto 1
Это можно ли как-то всё упросить? Я уверен, что-то делаю неправильно.
Ответы
Ответ 1
Пункты 1-2 - это очень упрощенный (где убрано к примеру тестирование) процесс, который
делает каждый разработчик. Это его обычный цикл.
Пункт 3-4 - это релиз. Он не должен делать обычным разработчиком. Он делается релиз-менеджером
(или ответственным человеком, назначенным на этом). Он не делается на каждый чих, а
по процессу - раз в две недели или два раза в день.
Пункты 5-8 делаются нажатием одной (максимум двух кнопок) или запуском одного скрипта.
Он запускается на специальном билд сервере (для маленькой такой компании это может
быть одна машина и для сборки, и для тестов и для репозитория). Сам скрипт сборки обычно
делает следующее
git clone / git archive
прогон скрипта, который фиксит конфиги, шаблоны (вы же не хотите показывать всем
программистам пароли к базе на проде?)
запуск скрипта, который процессит css, минимизирует js и тому подобное.
прогон юнит тестов (они здесь, так как после минимизации могут быть проблемы:) )
архивирование и занесение архива в надежное место
подключаемся к прод серверу(серверам) и заливаем туда архив.
архив распаковывается на сервере в отдельную папку, правится конфиг nginx/apache
или симлинка и сервер рестартует. (можно конечно остановить сервер, перетереть файлы
и запустить сервер, но если что то пошло не так...).
на проде проганяются минимальные тесты (к примеру, что главная страница возвращает
200 код, а не 500).
и в git добавляется тег с ссылкой на релиз.
Этот скрипт пишеться один раз и потом подганяется по мере надобности.
также этот скрипт следует дополнить, что бы он мог работать и с develop веткой.
Теперь упрощаем жизнь. В хуки на гит сервере добавляем этот скрпит, что бы при пуше
в девелом/мастер автоматом запускалось и, как результат, деплоилось на тестовый сервер/прод.
Мердж в мастер обычным программистам запрещается.
Теперь все выглядит так. Разработчик взял фичу, сделал под нее ветку, сделал. После
мержда в девелом (или через мердж реквест) его код автоматом выливается на тестовое
окружение. Если вдруг так случилось, что он все сломал - он должен фиксить.
Если так не подходит, можно скрипт запускать на CI - один с самых популярных - jenkins.
В результате деплой - это просто нажать одну кнопку.
Q/A
а почему не пулить прямо на боевом сервере? Если кто то уведет сервер, у него будет
доступ к полной истории разработки. Это нужно?
у меня никто не уведет историю гита, поэтому я буду пулить. уже было
зачем сколько сложностей с скриптом? А представьте, что багу нашли среди ночи и нужно
срочно фиксить. Наличие такого скрипта сильно упрощает жизнь.
а можно без тестов? можно. Но лучше сделать какие-то минимальные.
Ответ 2
Давайте для начала разделим сущности. В процессе задействованы:
Боевой сервер.
Тестовый сервер.
Сервер git
Некоторый "агент деплоя". Сейчас вы развёртываете (деплоите) руками, хорошо бы делегировать
эту задачу серверу непрерывной интеграции (continuous integration server, CI server).
В простейшей версии это реализуется хуками на сервере git.
Исходный код приложения
Дистрибутив приложения — в вашем случае это минимизированные с помощью Gulp файлы.
В данный момент задачи всех серверов выполняет один, а дистрибутив хранится вместе
с кодом. Давайте тем не менее рассматривать их как отдельные и стремиться к низкой
связности между ними (как в ООП между классами). Это даст нашей системе гибкость и
гораздо большую масштабируемость. В частности, не будем полагаться на то, что что-то
лежит рядом на одном диске или доступно по локальной сети.
Что нужно сделать:
Отделить дистрибутив от кода. При коммите запускаем gulp, получаем минимизированные
файлы, (опционально) пакуем их в архив, перемещаем на сервер и там разворачиваем. Минимизированный
код хранить не нужно, т.к. мы всегда можем его получить из исходного.
Реализовать в коде сценариий развёртывания. Хотя бы предусмотреть место для действий,
производимых на сервере: заполнение конфигов, перезагрузка сервисов и т.п. Как говорилось
выше, это делается через git-hook и/или сервер CI.
Автоматизировать реакцию на изменения в репозитории: при пуше в определённые ветки
должно происходит развёртывание в определённом окружении. Поскольку сценарий развёртывания
у нас теперь в коде, мы можем его.
И в организации работы:
Пересмотреть порядок релизов. Сейчас вы как будто бы релизите каждую опечатку и релизить
может каждый. Стоит так же подумать о защите ветки master (в том числе от своих неосторожных
действий).
Работающий пример
Предлагаю проводить эксперимент на примере GitLab.com (т.е. будем использовать облачный
сервис). Выбор субъективный, вот аргументы за:
Есть возможность создавать бесплатные приватные репозитории. (Т.е. ваш коммерческий
код в относительной безопасности.)
В комплекте есть GitLab CI, тесно интегрированный с репозиторием.
Доступны (в том числе для приватных репозиториев) бесплатные раннеры — условно, виртуальные
машины, на которых мы будем выполнять наши задачи.
Аргумент против: если проект будет расти, когда-нибудь бесплатной лицензии не будет
хватать для всех задач.
Рабочий пример с конвейерами и логами выложен на GitLab.com.
Основной файл, описывающий выполняемый сценарий, лежит в корневой папке проекта и
называется .gitlab-ci.yml.
image: alpine
stages:
- gulp
- test
- package
- deploy
cache:
paths:
- node_modules/
gulp:
stage: gulp
image: node:latest
before_script:
- npm install
script: node_modules/.bin/gulp compress
artifacts:
paths:
- dist
expire_in: 10 minutes
test:
stage: test
script: ls dist
script: echo 'run tests here'
package:
stage: package
script: tar -czvf packaged.tar.gz dist
artifacts:
paths:
- packaged.tar.gz
deploy_prod:
stage: deploy
script: echo 'deploy on master'
only:
- master
deploy_test:
stage: deploy
script: echo 'deploy on develop'
only:
- develop
Зависимости мы вынесем в конфиг для npm — package.json. В файле gulpfile.js описана
задача compress, обеспечивающая минимизацию.
Скриншот окна конвейеров CI:
Результат работы: архив packaged.tar.gz, в нём dists/hello.js, в нём
!function(t,e,i){t.title="New title"}(window,document);
