Около года назад перед нашей командой была поставлена задача стартовать разработку серверных частей ряда игровых MMO проектов. Специфика такого рода проектов помимо требований к гибкости, стабильности и масштабируемости также включает в себя:
Более того, в дальнейшем нашу команду предполагалось расширить, возможно за счет аутсорс разработчиков, в том числе и для задач поддержки. В этих условиях для успешной реализации было решено наравне с версионированием проектов, пакетированием и стандартизацией ряда шагов разработки внедрить и практику continuous delivery.
Цель данной статьи – рассказать о проделанных шагах, принятых решениях и описать полученный результат.
Исторически сложилось, что основным языком разработки серверных веб-приложений в нашей компании является PHP, поэтому это во многом предопределило выбор инструментов.
Итоговый список:
При выборе модели ветвления за основу была взята “A successful Git branching model”, описанная здесь с одним небольшим отличием: проводить A/B-тестирование было решено путем подготовки отдельных релизных веток, формирующихся из разного набора feature-веток. В результате роль ветки develop была полностью возложена на релизные ветки, и сама эта ветка исчезла. В противном случае при создании следующего релиза мы были бы вынуждены включать в него все выпущенные до этого feature, что не всегда являлось приемлемым.
Эту ситуацию можно продемонстрировать на следующем примере. Напомним, что согласно оригиналу:
И допустим, что уже выпущены два релиза – релиз 1.0 с фичей A и релиз 2.0 с фичами A и B, и необходимо выпустить релиз 1.1 с фичами A и C. Так как develop ветка на данный момент уже содержит в себе фичи А и B, то наиболее простым решением будет создание feature ветки С от ветки релиза 1, и последующий ее merge обратно:
Все проекты оформлены как composer-пакеты.
Для переиспользования функциональности от одного проекта к другому широко применяется выделение какой-то обособленой ее части в отдельный пакет.
Это сопровождается заменой одного пакета другим, разделением одного пакета на два или переносом функциональности из одного пакета в другой. В таких условиях для более тонкого контроля было используется семантическое версионирование пакетов.
Этот тип версионирования поддерживается в composer с использованием символа “~”, например:
В случае с PHP, говорить о сборке в классическом смысле, как процессе конвертации исходников проекта в исполняемый код, нельзя. Тем не менее, так как основной задачей по-прежнему является получение готового к использованию ПО, то название “сборка” вполне корректно.
Этапы сборки:
Для реализации сборки в корне каждого проекта находится сборочный phing-скрипт с target'ами:
Сборочный скрипт для большинства проектов одинаков и отличается лишь названием проекта: аттрибутом name, тега project.
Реализация автоматического тестирования проектов сделана при помощи двух фреймворков: Behat и PHPUnit.
Использование первого дает существенное преимущество не только для тестирования, но и для создания так называемой living documentation. Тесты на Gherkin являются одной из отправных точек при знакомстве с проектом нового программиста, при проведении code review, а также ряде других работ.
Несмотря на знакомство с материалами тут и тут, единых рекомендаций относительно глубины и детальности этих тестов у нас нет, поэтому их содержимое может варьироваться от например таких:
до таких:
PHPUnit используется не только для реализации unit-тестов, наличие и содержимое которых полностью остается за программистом, но и для запуска Behat тестов, с использованием небольшого workaround'а. Это дает возможность запускать все тесты одной командой, а также иметь единые отчеты по результатам работы тестов и покрытию ими кода.
Сборка производится с использованием CI-сервера Jenkins. При этом для каждой релизной ветки releases/X.Y заведено отдельное сборочное задание, которое на staging среде:
Само сборочное задание, равно как и сборочный скрипт были построены на основе описанных здесь. Именно этим и обусловлен столь богатый список дополнительных утилит.
В дополнение к указанному по ссылке выше списку плагинов были установлены:
Требовалось найти решение позволяющее одновременно управлять развертыванием нескольких приложений, каждое из которых может быть установлено на несколько групп серверов (testing, production).
Первоначально deployment осуществлялся phing-скриптом, который согласно файлу настроек выполнял ряд действий:
Это было не совсем удобно в силу полного отсутствия поддержки инсталляции на удаленные сервера.
После нескольких экспериментов с Capistrano, Magallanes и другими инструментами, в дополнение к этому скрипту было реализовано консольное приложение Installer. Оно копирует на нужную удаленную группу серверов инсталляционный скрипт с нужными настройками и выполняет его там.
Также в это приложение были заложены команды по получению возможных версий приложения и запросу установленной на серверах версии (на картинке показана возможность обновления проекта в production environment'е с версии 1.0.19 до 1.0.20):
А формат файлов настроек был заменен на более удобный .yml:
Данное консольное приложение было развернуто на сборочном сервере, к нему был сделан веб-интерфейс в виде параметризуемого сборочного задания Jenkins, выполняющего консольную команду:
где,
И это задание в свою очередь было отмечено как downstream project для сборочных заданий релизных веток с использованием плагина Parameterized Trigger Plugin.
В итоге нами была успешно решена задача реализации continuous delivery со следующей последовательностью шагов:
Используемая модель ветвления способствует тому, что разные ветки со временем начинают сильно отличаться друг от друга, это приводит к проблемам внедрения новых фич в старые релизы. Пока это не стало критичным, но есть мысль попробовать вернуть интеграционную ветку develop, а для подготовки A/B-версий использовать другую технику, возможно, что-то навроде feature toggles.
Есть интерес попробовать различного вида интеграции с трекером Jira. Как-то например автоматизировать:
Текущее время работы composer'а составляет порядка нескольких минут, а большое количество собственных пакетов приводит к сильно разросшейся секции repositories файлов composer.json. Хочется поэкспериментировать с Satis, для решения этих проблем.
Мы успешно решили поставленные перед нами проблемы:
Следует заметить, что данная схема почти не используется для фактического обновления проектов в production, так как не покрывает всех проблем выпуска нового и возможно не совместимого с предыдущей версией релиза. Ее основное применение быстрая и автоматизированная доставка новой функциональности на все сервера, где развернуто приложение, и обновление в тех местах, где это возможно, либо не критично – тестовые и предназначенные для закрытого бета-тестирования сервера.
Suerte!
- необходимость A/B-тестирования разных версий одной и той же игры
- возможность по максимуму переиспользовать функциональность от одной игры в другой
- высокую вероятность географической удаленности от разработчиков занимающихся клиентской частью игры
Более того, в дальнейшем нашу команду предполагалось расширить, возможно за счет аутсорс разработчиков, в том числе и для задач поддержки. В этих условиях для успешной реализации было решено наравне с версионированием проектов, пакетированием и стандартизацией ряда шагов разработки внедрить и практику continuous delivery.
Цель данной статьи – рассказать о проделанных шагах, принятых решениях и описать полученный результат.
Инфраструктура
Исторически сложилось, что основным языком разработки серверных веб-приложений в нашей компании является PHP, поэтому это во многом предопределило выбор инструментов.
Итоговый список:
- Git – система контроля версий
- Gitolite – управление репозиториями
- Composer – менеджер зависимостей
- Phing – сборочный и инсталляционный скрипты
- Jenkins – continuous integration сервер
- phpunit, behat – тесты
- phploc, phpmd, pdepend, phpcs, phpcpd, phpcb, phpdox – прочие утилиты
Модель ветвления
При выборе модели ветвления за основу была взята “A successful Git branching model”, описанная здесь с одним небольшим отличием: проводить A/B-тестирование было решено путем подготовки отдельных релизных веток, формирующихся из разного набора feature-веток. В результате роль ветки develop была полностью возложена на релизные ветки, и сама эта ветка исчезла. В противном случае при создании следующего релиза мы были бы вынуждены включать в него все выпущенные до этого feature, что не всегда являлось приемлемым.
Эту ситуацию можно продемонстрировать на следующем примере. Напомним, что согласно оригиналу:
At least all features that are targeted for the release-to-be-built must be merged in to develop at this point in time. All features targeted at future releases may not—they must wait until after the release branch is branched off.
И допустим, что уже выпущены два релиза – релиз 1.0 с фичей A и релиз 2.0 с фичами A и B, и необходимо выпустить релиз 1.1 с фичами A и C. Так как develop ветка на данный момент уже содержит в себе фичи А и B, то наиболее простым решением будет создание feature ветки С от ветки релиза 1, и последующий ее merge обратно:
Пакетирование и версионирование
Все проекты оформлены как composer-пакеты.
Для переиспользования функциональности от одного проекта к другому широко применяется выделение какой-то обособленой ее части в отдельный пакет.
Это сопровождается заменой одного пакета другим, разделением одного пакета на два или переносом функциональности из одного пакета в другой. В таких условиях для более тонкого контроля было используется семантическое версионирование пакетов.
Этот тип версионирования поддерживается в composer с использованием символа “~”, например:
"require": {
...
"alawar/packet-post-process-server": "~1.3",
...
},
“Сборка” проекта
В случае с PHP, говорить о сборке в классическом смысле, как процессе конвертации исходников проекта в исполняемый код, нельзя. Тем не менее, так как основной задачей по-прежнему является получение готового к использованию ПО, то название “сборка” вполне корректно.
Этапы сборки:
- выкачивание зависимостей через composer
- миграция БД, — обновление только структуры и статических данных базы данных
Для реализации сборки в корне каждого проекта находится сборочный phing-скрипт с target'ами:
- build – для выполнения этапов сборки
- runtests и runtest-with-coverage – для выполнения как сборки так и запуска тестов и сбора метрик
Сборочный скрипт для большинства проектов одинаков и отличается лишь названием проекта: аттрибутом name, тега project.
Тестирование
Реализация автоматического тестирования проектов сделана при помощи двух фреймворков: Behat и PHPUnit.
Использование первого дает существенное преимущество не только для тестирования, но и для создания так называемой living documentation. Тесты на Gherkin являются одной из отправных точек при знакомстве с проектом нового программиста, при проведении code review, а также ряде других работ.
Несмотря на знакомство с материалами тут и тут, единых рекомендаций относительно глубины и детальности этих тестов у нас нет, поэтому их содержимое может варьироваться от например таких:
Сценарий: Получение пользовательского бонус кода и списка возможных наград
# Пусть мы получили бонус код для какого-то игрока
Пусть мы успешно отправили запрос:
| action | uid |
| get-user-bonus-code | player1 |
Тогда мы получим ответ в соответствии с шаблоном "GetUserBonusCodeResponse.txt"
# Тогда запросив список возможных наград мы получим награды за использование выбранного бонус кода
Пусть мы успешно отправили запрос:
| action | code |
| get-rewards-info | Полученный бонус код |
Тогда мы получим ответ в соответствии с шаблоном "template8.txt"
до таких:
Сценарий: Получение и обработка данных
Пусть веб-сервис приложения получает данные по отчетам
И после этого запускается команда на обработку данных
Тогда в БД появятся обработанные согласно схеме данные
PHPUnit используется не только для реализации unit-тестов, наличие и содержимое которых полностью остается за программистом, но и для запуска Behat тестов, с использованием небольшого workaround'а. Это дает возможность запускать все тесты одной командой, а также иметь единые отчеты по результатам работы тестов и покрытию ими кода.
Сборочный сервер
Сборка производится с использованием CI-сервера Jenkins. При этом для каждой релизной ветки releases/X.Y заведено отдельное сборочное задание, которое на staging среде:
- выполняет сборочный phing-скрипт с target'ами “build runtests-with-coverage”
- собирает отчеты тестирования и результатов работы вспомогательных утилит
- в случае безошибочного завершения процесса создает в репозитории новый тег вида $VERSION_NO.$BUILD_NUMBER, где $VERSION_NO – номер версии, получаемый из названия ветки, например 2.1, а $BUILD_NUMBER – порядковый номер сборки для данного сборочного задания
Само сборочное задание, равно как и сборочный скрипт были построены на основе описанных здесь. Именно этим и обусловлен столь богатый список дополнительных утилит.
В дополнение к указанному по ссылке выше списку плагинов были установлены:
- EnvInject – для инициализации переменной $VERSION_NO
- ChuckNorris и CI-Game – just for fun
Деплоймент
Требовалось найти решение позволяющее одновременно управлять развертыванием нескольких приложений, каждое из которых может быть установлено на несколько групп серверов (testing, production).
Первоначально deployment осуществлялся phing-скриптом, который согласно файлу настроек выполнял ряд действий:
- создавал файлы, папки и симлинки
- делал checkout исходников нужной ветки/тега
- выполнял сборку проекта
- и так как каждый раз checkout выполнялся в новую папку вида 2012-01-01T23:59:59, то обновлял симлинк latest, указывающий на последнюю развернутую версию
Это было не совсем удобно в силу полного отсутствия поддержки инсталляции на удаленные сервера.
После нескольких экспериментов с Capistrano, Magallanes и другими инструментами, в дополнение к этому скрипту было реализовано консольное приложение Installer. Оно копирует на нужную удаленную группу серверов инсталляционный скрипт с нужными настройками и выполняет его там.
Также в это приложение были заложены команды по получению возможных версий приложения и запросу установленной на серверах версии (на картинке показана возможность обновления проекта в production environment'е с версии 1.0.19 до 1.0.20):
А формат файлов настроек был заменен на более удобный .yml:
Данное консольное приложение было развернуто на сборочном сервере, к нему был сделан веб-интерфейс в виде параметризуемого сборочного задания Jenkins, выполняющего консольную команду:
/home/projects/installer/installer.phar $command $recipe $environment
где,
- $command — имя выполняемой команды, например install, status, versions
- $recipe — код присваемый версии проекта, предназначенной для инсталляции
- $environment — опциональное имя группы серверов, на которые необходимо установить проект
И это задание в свою очередь было отмечено как downstream project для сборочных заданий релизных веток с использованием плагина Parameterized Trigger Plugin.
В итоге
В итоге нами была успешно решена задача реализации continuous delivery со следующей последовательностью шагов:
- разработчик вносит изменения в релизную ветку
- post-receive hook gitolite инициирует соответствующее этой ветке сборочное задание Jenkins
- сборочное задание проводит тестирование и помечает успешную версию тегом
- Jenkins запускает downstream project Installer с нужными параметрами для проекта и группы серверов, на которых проект надо обновить
- Installer, последовательно пройдя по всем серверам группы, разворачивает на них свежую версию и обновляет симлинк latest
В дальнейшем
Используемая модель ветвления способствует тому, что разные ветки со временем начинают сильно отличаться друг от друга, это приводит к проблемам внедрения новых фич в старые релизы. Пока это не стало критичным, но есть мысль попробовать вернуть интеграционную ветку develop, а для подготовки A/B-версий использовать другую технику, возможно, что-то навроде feature toggles.
Есть интерес попробовать различного вида интеграции с трекером Jira. Как-то например автоматизировать:
- создание веток под новые тикеты определенного типа
- обновление статуса и/или комментариев к тикетам в соответствии с результатами тестирования
- формирование change log'ов
Текущее время работы composer'а составляет порядка нескольких минут, а большое количество собственных пакетов приводит к сильно разросшейся секции repositories файлов composer.json. Хочется поэкспериментировать с Satis, для решения этих проблем.
Заключение
Мы успешно решили поставленные перед нами проблемы:
- для создания A/B-версий используются отдельные ветки в системе контроля версий
- пакетный менеджер позволяет переиспользовать функциональность от проекта к проекту
- тесты на Gherkin и их реализация помогают существенно упростить подключение к проекту новых разработчиков
- а описанная выше схема continuous delivery позволяет минимизировать время получения фидбека от разработчиков клиентской части игры
Следует заметить, что данная схема почти не используется для фактического обновления проектов в production, так как не покрывает всех проблем выпуска нового и возможно не совместимого с предыдущей версией релиза. Ее основное применение быстрая и автоматизированная доставка новой функциональности на все сервера, где развернуто приложение, и обновление в тех местах, где это возможно, либо не критично – тестовые и предназначенные для закрытого бета-тестирования сервера.
Suerte!