Вариант архитектуры для Continuous Integration на 1С-Битрикс проекте

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

Я уверен что существует множество вариантов разных схем внедрения Continuous Integration, и эта статья не претендует на роль единственной истинно верной.

В Обычном случае файловая структура нашего приложения организована примерно следующим образом:

Ordinaryfs

Папка /var/www/example.com - папка нашего сайта, в которой собственно и проводятся работы. Код в ней редактируется либо через ftp/sftp либо заливаются наработки через систему контроля версий.

Если у вас помимо системы контроля версий существует еще какая-то сборка фронтенда (компиляция исходников CSS-препроцессоров, склеивание и минификация всяких стилей и скриптов, обработка статического контента и прочее прочее), то выкладка ваших трудов на боевой сервер превращается в не самое быстрое занятие.

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

При достаточно регулярном деплое все эти рутинные операции надоедают, да и не всегда они покрывают растущие нужды проекта.

Хочется автоматизировать это дело и расширить перспективы для нашего функционала.

Предлагается следующая схема файлов:

Fsforci

Она требует некоторых пояснений.

  1. Появляется папка versions - это папка которая содержит последние задеплоенные версии нашего приложения. Фактически это закоммиченные изменения, собранные всеми требуемыми сборщиками и развернутые на боевом сервере. т.е. /var/www/versions/version#1/example.com - это аналог старого варианта /var/www/example.com содержащий все сделанные вами изменения.
  2. Появляется папка common - она содержит довольно крупную, и что самое главное, неизменяемую часть проекта, которую нет смысла плодить новую в каждом релизе. На нее мы просто будем делать симлинки вида /var/www/versions/version#1/example.com/bitrix -> /var/www/common/bitrix и /var/www/versions/version#1/example.com/upload -> /var/www/common/upload
  3. Появляется current, но это не папка, это симлинк на актуальную версию приложения из папки /var/www/versions. При этом все root в nginx мы направляем через этот симлинк, чтобы nginx'у было всё равно что там творится в папке /var/www/versions, он всегда будет видеть актуальную версию

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

  1. Мы закоммитили все наши изменения в гит. И теперь наша сборочно-деплойная система должна об этом узнать и закрутить свой таинственный механизм. Мы можем в интерфейсе нашей CI системы либо сами запустить этот механизм, либо настроить автоматический хук, который по каждому коммиту будет его запускать. Тем, кто любит поменьше ручных действий, понравится вариант автозапуска по пушу.
  2. Мы должны произвести сборку. Как вариант поднимается докер-контейнер со всем необходим софтом, пакетами и т.д. для сборки, и в него вытягивается код из репозитория, выполняются команды сборки и получившееся готовое к использованию. Далее для транспортировки на бой эта версия запаковывается в архив и помещается в какое-либо хранилище этих сборочных версий.
  3. Время переносить нашу версию на бой. Тут уже надежнее вариант ручной инициации деплоя. После того как приложение запаковано, CI система переправляет его в папку /var/www/versions боевого сервера, распаковывает и переключает симлинк current на актуальную версию. Надо не забыть перезапустить php-fpm, иначе php акселераторы сыграют с вами злую шутку, закешировав старый вариант кода.

Помимо этого, если у вас есть какие-то тесты, то их так же можно запустить на шаге №2 во время сборки, и если тесты не прошли, то можно отменить сборку, выслать ответственным уведомления об ошибках.

Так же на шаге №3 во время деплоя вы можете инициировать миграции базы данных. Если они у вас есть на битрикс проекте *муахахахаха*

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

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

{{ message }}

{{ 'Comments are closed.' | trans }}