Всем привет! Сегодня я бы хотел рассказать о том, какие есть способы устроить бранчи под каждую задачу и как мы это сделали у себя в Alawar. Здесь рассматривается простой приём с apache2, который позволяет получить отличный результат и может быть полезна как веб-разработчиками, так и системным администраторам. Стоит отметить, что аналогичные решения уже освещались на хабре (например, тут), но часто они написаны для слишком узкой аудитории и не дают ответы на все вопросы и, главное, часто усложняют задачу. Цель же конкретно этой статьи, – показать, как на самом деле всё просто.
Итак, начнём.
Несколько лет назад у нас была проблема, которая заключалась в том, что было достаточно трудозатратно подготовить отдельную тестовую площадку на сервере под каждую задачу. На тот момент использовалась одна ветка (trunk) в репозитории для всех разработчиков и один тестовый сервер. Для крупных задач, конечно же, вручную готовились отдельные инстансы, но это была скорее вынужденная мера, чем нормальное решение. Всё это периодически приводило к конфликтам в коде по ходу разработки, и самое печальное,– к неожиданным поломкам одной задачи, из-за проведённых работ в рамках другой задачи.
Любое изменение в коде сопровождается соответствующим тикетом в багтрекере. Тикеты разного масштаба выполняются по несколько десятков в неделю. Тестировать необходимо каждый тикет по отдельности.
Репозиторий, при решении данной задачи не критичен, можно использовать любой, где есть возможность вести разработку в отдельной ветке, так что я специально не буду заострять на этом вопросе внимание.
На самом деле мы долгое время так и делали, но не для всех задач, т.к. это занимало действительно много времени. Поэтому создавали только то, что нужно и по возможности только необходимый минимум.
2. Настроить по 1-2 тестовых стенда на разработчика
Такой подход позволяет разработчику показать одну задачу и делать вторую, но остальные задачи при такой конфигурации уже не посмотришь. И возникает путаница, когда разработчик переключает тестовый стенд на другую задачу.
3. На тестовом сервере менять правила формирования и обработки URL-ов
Например сделать все ссылки в проекте по такому принципу: http:// test.local / (task-number) / (host) / (uri).
Был и такой вариант, но требовал очень большого рефакторинга, так что здравый смысл не позволил нам пойти по такому пути. Но это не значит, что этот метод не подойдёт другим.
4. Виртуалка под каждую задачу
Идея в том, что хосты и пути всегда одни, код от нужной задачи, БД и прочие сервисы – свои. С точки зрения тестирования это, наверное, идеальный вариант.
В нашем случае один полноценный инстанс кода, вместе с БД, вместе со статикой и т.д. – это десятки гигабайт данных. Одно поднятие такого инстанса с нуля занимало бы у нас достаточно долгое время. Вдобавок, под все текущие задачи требовался бы не один терабайт данных. Но самое главное, в этом случае нам недостаточно было бы просто дать ссылку на реализованную задачу, чтобы показать результат заказчику. Нужно было бы её предварительно ещё и запустить, а такой вариант не казался нам удобным.
5. Использовать виртуальные хосты
В apache2 есть параметры UseCanonicalName и VirtualDocumentRoot (Ссылка на документацию). Они позволяют использовать субдомены хоста как часть пути к док. руту проекта и всё это без рестарта apache2. Благодаря этим параметрам фактически мы можем указать в хосте путь к инстансу + uri чтобы получить нужный нам ответ.
Где (site-identifier) может принимать значения вида:
• ru – в этом случае понимаем, что нужно показать основной сайт в зоне .ru
• com – основной сайт в зоне .com
• test.ru – субдомен test основного сайта в зоне .ru
• data.export.com – субдомен data.export основного сайта в зоне .com
Для проектов, где нет понятия основного сайта, применимы следующие правила:
• example.com – в этом случае понимаем, что нужно показать сайт example.com
• test. example.com – субдомен test. example.com
• data.export. example.com – субдомен data.export. example.com
• и т.д.
В итоге, набирая адрес в браузере: http://task-1234.example.com.test.local/some/page/?someParams=value мы однозначно знаем, что сервер отдаст ответ с ветки кода задачи task-1234, обработчик сайта example.com/some/page/?someParams=value.
Чтобы всё стало работать так, как мы это задумали, потребовалось зафиксировать пути к док.руту следующим образом:
И обучить проект определять имя хоста, согласно нашим правилам.
Из особенностей могу отметить, что для систем, где важен регистр пути к файлу, (task-number) и (site-identifier) должны быть в нижнем регистре.
Пример конфигурации тестовой площадки Apache2:
Автоматизацию деплоя можно провести разными средствами (скрипт на bash-е, phing, ant и т.д.).
Такой способ заключается в прописывании последовательности команд, которые необходимо выполнить, чтобы поднять инстанс вашего проекта. Для большинства веб-проектов он будет выглядеть примерно так:
1. Спросить task-number (или получить в качестве параметра имя ветки);
2. Создать бранч в репозитории, если его нет;
3. Создать папку под бранч (если её нет);
4. Сделать чекаут(ы) кода;
5. Настроить права на запись в нужные папки/файлы;
6. Настроить конфигурацию проекта;
7. Проставить нужные симлинки;
8. (выполнить другие специфичные проекту действия);
9. Выполнить инициализационные скрипты проекта;
10. При желании запустить тесты, чтобы убедиться, что всё ок.
Если вы знаете другие способы подготовки тестовых площадок под каждую ветку, которые в данной статье не описаны, напишите про них в комментариях, думаю, это будет очень полезно всем читателям
Итак, начнём.
Несколько лет назад у нас была проблема, которая заключалась в том, что было достаточно трудозатратно подготовить отдельную тестовую площадку на сервере под каждую задачу. На тот момент использовалась одна ветка (trunk) в репозитории для всех разработчиков и один тестовый сервер. Для крупных задач, конечно же, вручную готовились отдельные инстансы, но это была скорее вынужденная мера, чем нормальное решение. Всё это периодически приводило к конфликтам в коде по ходу разработки, и самое печальное,– к неожиданным поломкам одной задачи, из-за проведённых работ в рамках другой задачи.
Немного об особенностях проекта
Речь идёт об одном из наших крупных проектов (сайты alawar.ru, alawar.com и т.д.), суть которого – предоставлять разный контент с разных доменов на разных языках. В рамках одного проекта задействовано порядка сотни доменов и поддоменов.Любое изменение в коде сопровождается соответствующим тикетом в багтрекере. Тикеты разного масштаба выполняются по несколько десятков в неделю. Тестировать необходимо каждый тикет по отдельности.
Репозиторий, при решении данной задачи не критичен, можно использовать любой, где есть возможность вести разработку в отдельной ветке, так что я специально не буду заострять на этом вопросе внимание.
Какие у нас были варианты
1. Создавать конфигурацию сервера вручнуюНа самом деле мы долгое время так и делали, но не для всех задач, т.к. это занимало действительно много времени. Поэтому создавали только то, что нужно и по возможности только необходимый минимум.
2. Настроить по 1-2 тестовых стенда на разработчика
Такой подход позволяет разработчику показать одну задачу и делать вторую, но остальные задачи при такой конфигурации уже не посмотришь. И возникает путаница, когда разработчик переключает тестовый стенд на другую задачу.
3. На тестовом сервере менять правила формирования и обработки URL-ов
Например сделать все ссылки в проекте по такому принципу: http:// test.local / (task-number) / (host) / (uri).
Был и такой вариант, но требовал очень большого рефакторинга, так что здравый смысл не позволил нам пойти по такому пути. Но это не значит, что этот метод не подойдёт другим.
4. Виртуалка под каждую задачу
Идея в том, что хосты и пути всегда одни, код от нужной задачи, БД и прочие сервисы – свои. С точки зрения тестирования это, наверное, идеальный вариант.
В нашем случае один полноценный инстанс кода, вместе с БД, вместе со статикой и т.д. – это десятки гигабайт данных. Одно поднятие такого инстанса с нуля занимало бы у нас достаточно долгое время. Вдобавок, под все текущие задачи требовался бы не один терабайт данных. Но самое главное, в этом случае нам недостаточно было бы просто дать ссылку на реализованную задачу, чтобы показать результат заказчику. Нужно было бы её предварительно ещё и запустить, а такой вариант не казался нам удобным.
5. Использовать виртуальные хосты
В apache2 есть параметры UseCanonicalName и VirtualDocumentRoot (Ссылка на документацию). Они позволяют использовать субдомены хоста как часть пути к док. руту проекта и всё это без рестарта apache2. Благодаря этим параметрам фактически мы можем указать в хосте путь к инстансу + uri чтобы получить нужный нам ответ.
Наш выбор
В итоге мы выбрали вариант с виртуальными хостами и определили следующий формат адресов: http:// (task-number). (site-identifier). test.local / (uri).Где (site-identifier) может принимать значения вида:
• ru – в этом случае понимаем, что нужно показать основной сайт в зоне .ru
• com – основной сайт в зоне .com
• test.ru – субдомен test основного сайта в зоне .ru
• data.export.com – субдомен data.export основного сайта в зоне .com
Для проектов, где нет понятия основного сайта, применимы следующие правила:
• example.com – в этом случае понимаем, что нужно показать сайт example.com
• test. example.com – субдомен test. example.com
• data.export. example.com – субдомен data.export. example.com
• и т.д.
В итоге, набирая адрес в браузере: http://task-1234.example.com.test.local/some/page/?someParams=value мы однозначно знаем, что сервер отдаст ответ с ветки кода задачи task-1234, обработчик сайта example.com/some/page/?someParams=value.
Чтобы всё стало работать так, как мы это задумали, потребовалось зафиксировать пути к док.руту следующим образом:
/data/projects/projectName/branches/(task-number)/application/publicИ обучить проект определять имя хоста, согласно нашим правилам.
Из особенностей могу отметить, что для систем, где важен регистр пути к файлу, (task-number) и (site-identifier) должны быть в нижнем регистре.
Пример конфигурации тестовой площадки Apache2:
<VirtualHost *:80>
UseCanonicalName Off
VirtualDocumentRoot /data/projects/projectName/branches/%1/application/public
ServerName test.local
ServerAlias *.test.local
Options -Indexes
CustomLog /dev/null combined
</VirtualHost>
Автоматический деплой
В конечном счёте были написаны скрипты для автоматизированного деплоя, которые создают нужную ветку кода в репозитории, делают распаковку и настройку локального инстанса на тестовом сервере за пару минут, но это уже отдельная тема, здесь расскажу об этом в общих словах.Автоматизацию деплоя можно провести разными средствами (скрипт на bash-е, phing, ant и т.д.).
Такой способ заключается в прописывании последовательности команд, которые необходимо выполнить, чтобы поднять инстанс вашего проекта. Для большинства веб-проектов он будет выглядеть примерно так:
1. Спросить task-number (или получить в качестве параметра имя ветки);
2. Создать бранч в репозитории, если его нет;
3. Создать папку под бранч (если её нет);
4. Сделать чекаут(ы) кода;
5. Настроить права на запись в нужные папки/файлы;
6. Настроить конфигурацию проекта;
7. Проставить нужные симлинки;
8. (выполнить другие специфичные проекту действия);
9. Выполнить инициализационные скрипты проекта;
10. При желании запустить тесты, чтобы убедиться, что всё ок.
Итак,
на проектах, которые могут использовать apache2 в качестве сервера, вы сможете легко использовать описанный в этой статье способ идентификации нужной версии сайта через виртуальные хосты.Если вы знаете другие способы подготовки тестовых площадок под каждую ветку, которые в данной статье не описаны, напишите про них в комментариях, думаю, это будет очень полезно всем читателям