Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Continuous Delivery hecho en Alawar

Anna | 31.05.2014 | нет комментариев

Около года назад перед нашей командой была поставлена задача стартовать разработку серверных частей ряда игровых MMO планов. Особенность такого рода планов помимо требований к эластичности, устойчивости и масштабируемости также включает в себя:

  • надобность A/B-тестирования различных версий одной и той же игры
  • вероятность по максимуму переиспользовать функциональность от одной игры в иной
  • высокую вероятность географической удаленности от разработчиков занимающихся клиентской частью игры

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

Цель данной статьи – рассказать о проделанных шагах, принятых решениях и описать полученный итог.

image

Инфраструктура

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

Итоговый список:

  • Git – система контроля версий
  • Gitolite – управление репозиториями
  • Composer – администратор зависимостей
  • Phing – сборочный и инсталляционный скрипты
  • Jenkins – continuous integration сервер
  • phpunitbehat – тесты
  • phplocphpmdpdependphpcsphpcpdphpcbphpdox – прочие утилиты

 

Модель ветвления

При выборе модели ветвления за основу была взята “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 обратно:

image

 

Пакетирование и версионирование

Все планы оформлены как composer-пакеты.

Для переиспользования функционалILD_NUMBER, где $VERSION_NO – номер версии, получаемый из наименования ветки, скажем 2.1, а $BUILD_NUMBER – порядковый номер сборки для данного сборочного задания
Само сборочное задание, равно как и сборочный скрипт были возведены на основе описанных тут. Именно этим и обусловлен столь богатенький список дополнительных утилит.

image

В дополнение к указанному по ссылке выше списку плагинов были установлены:

 

Деплоймент

Требовалось обнаружить решение разрешающее единовременно руководить развертыванием нескольких приложений, всякое из которых может быть установлено на несколько групп серверов (testing, production).

Изначально deployment осуществлялся phing-скриптом, тот, что согласно файлу настроек исполнял ряд действий:

  • создавал файлы, папки и симлинки
  • делал checkout исходников требуемой ветки/тега
  • исполнял сборку плана
  • и так как всякий раз checkout выполнялся в новую папку вида 2012-01-01T23:59:59, то обновлял симлинк latest, указывающий на последнюю развернутую версию

Это было не вовсе комфортно в силу полного отсутствия поддержки инсталляции на удаленные сервера.

Позже нескольких экспериментов с CapistranoMagallanes и другими инструментами, в дополнение к этому скрипту было реализовано консольное приложение Installer. Оно копирует на необходимую удаленную группу серверов инсталляционный скрипт с надобными настройками и исполняет его там.

Также в это приложение были заложены команды по приобретению допустимых версий приложения и запросу установленной на серверах версии (на картинке показана вероятность обновления плана в production environment’е с версии 1.0.19 до 1.0.20):

image

А формат файлов настроек был заменен на больше комфортный .yml:

image

Данное консольное приложение было развернуто на сборочном сервере, к нему был сделан веб-интерфейс в виде параметризуемого сборочного задания 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

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB