Что же такое автоматическое развертывание проектов (деплой)? Для себя мы определили его как процесс переноса кода и структуры базы данных с локальной машины разработчика («песочницы», если угодно) на сервер (или кластер серверов), на котором в будущем и будет работать этот проект. В том числе в этот процесс входят и различного рода подготовительные операции, как, например, очистка и подогрев кэша.
Зачем он нужен? Каждый из нас на своем пути прошел разные варианты переноса проекта на «боевой» сервер: это и ftp (на нашей памяти были разработчики, которые сразу писали код на сервере, взаимодействуя с ним исключительно по ftp), и sftp, и rsycn, и git pull — все эти способы имеют множество недостатков, а главное, что они требуют монотонной рутинной работы. Мы решили, что лучше потратить это время на разработку, а всю монотонность доверить машине.
Требования к системе деплоя
Для начала мы определились с требованиями к подобной системе:
- должна быть возможность развертывать проект сразу на несколько площадок или на одну из них по выбору — для каждого проекта у нас есть, как минимум, две площадки (боевая и тестовая), кроме того, некоторые проекты используют кластер серверов,
- разворачивать проекты нужно из репозитория, а, кроме того, должна быть возможность развернуть разные ветки репозитория на разные площадки,
- должна быть возможность быстро откатиться к предыдущему релизу,
- процесс обновления должен быть максимально незаметным для пользователей сайта,
- система должна быть расширяемой и позволять вводить любые дополнительные операции, которые нам потребуются (установка пакетов composer, миграции бд и т.д.),
- сама система должна быстро разворачиваться и настраиваться для любого проекта,
- должна быть написана на php — очевидно, что у php-разработчика настроено окружение для работы с php и заставлять его настраивать ради деплоя окружение для работы с, например, ruby — бессердечно.
Скрипты деплоя для php
Мы начали искать подходящее готовое решение. Jenkins, Capistrano и т.д. были отброшены сразу же, несмотря на их популярность. Нам нужен был скрипт, написанный на php.
Тогда мы обратились к репозиторию на github, который выручал нас не раз. В нем авторы собирают наиболее полезные и удобные библиотеки для php. На момент написания статьи в разделе «Deployment» были только deployer, rocketeer и морально устаревший ныне phing.
Мы решили использовать именно rocketeer, прежде всего потому, что автор открыто пишет, что вдохновлялся capistrano, а с capistrano у нас был долгий и по большей части положительный опыт работы. Rocketeer из коробки поддерживает большую часть необходимого нам функционала, имеет удобный phar скрипт для своей работы, имеет багтрекер на github, документирован, легко и быстро настраивается для проекта с помощью команды ignite.
Требования к проектам для настройки rocketeer
Однако нам пришлось реструктурировать и свои проекты, для того, что бы применить к ним rocketeer. Конечно, это было совсем не обязательно, но, согласитесь, что в случае если тебе достается проект от другого разработчика, а ты уже знаешь где и что лежит, то это приятно греет душу.
Итак, вот структура файлов, которую мы используем для проектов на «1С-Битрикс: Управление сайтом»:
- .rocketeer папка с настройками деплоя для rocketeer.
- documents папка, в которой должна содержаться вся документация по проекту.
- examples папка, в которой должны лежать примеры файлов настройки «1С-Битрикс: Управление сайтом».
- - .settings.php
- - dbconn.php
- frontend папка, в которой будут лежать файлы, необходимые для сборки frontend.
- lib папка, в которой будут лежать файлы классов, которые были написаны специально для проекта.
- vendor папка с библиотеками, загруженными с помощью composer.
- web папка, которая будет доступна из web.
- - bitrix папка с файлами, принадлежащими дистрибутиву «1С-Битрикс: Управление сайтом».
- - local папка со всеми компонентами, шаблонами и модулями, которые потребовались для проекта.
- .gitignore служебный файл git, который исключает некоторый файлы и папки из репозитория.
- README.MD файл в формате markdown с кратким описанием проекта.
- composer.json файл настройки composer.
- composer.phar файл со скриптом Composer.
- rocketeer.phar файл со скриптом Rocketeer.
Требования к настройке сервера
Появились так же и требования к настройке сервера. В общем случае, rocketeer создает на сервере папку releases, в которой в отдельных папках клонирует базовый репозиторий. На том же уровне, что и папка releases, rocketeer создает символическую ссылку current, которая ведет на текущий активный релиз — все это позволяет быстро и незаметно переключать для пользователя сайта релизы. Там же есть и папка shared. Она предназначена для того, чтобы сохранять файлы между релизами. Например, мы в ней храним папку uploads для битрикса и файлы с настройками проекта на сервере (.settongs.php и dbconn.php).
Учитывая нашу структуру и структуру репозитория, получаем, что document root виртуального хоста должен указывать на «/папка_сайта/current/web/».
Хотите больше автоматизации?
Чтобы не создавать постоянно из проекта в проект одну и ту же структуру папок, мы сделали проект для composer.
Теперь, чтобы развернуть скелет проекта достаточно выполнить в консоли
composer create-project marvin255/bitrix-base
и вы получите всю структуру проекта, свежие версии composer, rocketeer и bitrixsetup.php. Чисто и быстро.
Как же заставить это работать?
Возможно, вначале настройка деплоя покажется вам сложной и ненужной, но мы гарантируем: стоит только попробовать и вы не сможете отказаться от rocketeer.
Для примера, алгоритм из нашего внутреннего регламента по созданию нового проекта:
- Разработчик сообщает серверному специалисту, что нужно настроить проект, сообщает название проекта латиницей.
- Разработчик создает репозиторий в своем аккаунте в gitlab и инициирует проект пустым README.MD файлом.
- Разработчик клонирует репозиторий на свой локальный стенд.
- Разработчик создает структуру папок согласно статье 3 данного регламента и наполняет все служебные файлы (.gitignore, composer.json, README.MD и т.д.) или разворачивает стандартный проект с помощью команды composer create-project marvin255/bitrix-base.
- Разработчик копирует в папку web файл bitrixsetup.php и с помощью него устанавливает «1С-Битрикс: Управление сайтом».Разработчик настраивает в файле /web/local/php_interface/init.php подключение файла /vendor/autoload.php.
- Разработчик инициирует composer командой php composer.phar install.
- Серверный специалист сообщает разработчику все данные по тестовому серверу.
- Разработчик настраивает в проекте Rocketeer согласно статье 6 данного регламента.
- Разработчик вносит все изменения с локальной машины в репозиторий.
- Разработчик на тестовом сервере создает ssh-ключ для пользователя проекта с помощью команды ssh-keygen. Ключ должен создаваться по стандартному пути ~/.ssh/id_rsa.pub, без указания пароля.
- Разработчик добавляет открытую часть ключа, созданного ранее, в deploy keys проекта в корпоративный gitlab.
- Разработчик добавляет домен корпоративного gitlab в authorized_keys для пользователя проекта.
- Разработчик создает на тестовом сервере в домашней папке проекта папки shared/web/upload и shared/web/bitrix/backup.
- Разработчик создает на тестовом сервере в домашней папке проекта файлы shared/web/bitrix/.settings.php и shared/web/bitrix/php_interface/dbconn.php и указывает в них верные данные для подключения к серверной базе данных.
- Разработчик переносит базу данных с помощью дампа с локальной машины на тестовый сервер.
- Разработчик заходит в папку проекта на своем локальном стенде в командной строке и выполняет команду php rocketeer.phar deploy.
- Разработчик проверяет работоспособность тестового сайта.