Этот раздел будет полезен всем кто участвует в доработках системы, а также будет интересен в целом всем, т.к. применяются несколько интереных подходов к разработке системы.

В первую очередь, используется система контроля версий git и модель ветвления git flow.

Это означает, что вся разработка ведется в ветке develop, а какие-то новые крупные функциональные модули пишутся в отдельных ветках feature/branch_name. Для работы с ними необходимо использовать готовые команды git flow.

Когда подходит время выпускать новый релиз, то на базе ветки develop создается ветка release/version, которая является тестовой версией нового релиза. Какое-то время вся команда работает с ней, тщательно тестируя и в конце концов релиз пушится в ветку master.

Конечно же не обходится и без исправления багов, для этого используются отдельные ветки hotfix/version, которые пушатся сразу в ветку master.

Полный список команд git flow можно посмотреть на оф. странице.

Т.к. неотъемлемой частью системы является база данных, то для автоматизации работы с ней написаны несколько гит-хуков.

Все описываемые ниже хуки необходимо поместить в папку .git/hooks/ вашего репозитория.
Скачать архив со всеми файлами можно по ссылке.
Необходимо будет поменять в файле _post-checkout.php имя баз данных для ветки develop и master.

Хук pre-commit

Сначала хочется отметить, что все запросы на изменение (update, delete, alter и др) с помощью yii-логов записываются в отдельный файл: protected/runtime/sql_update.log

И на хук pre-commit вызывается php-скрипт, который разбирает этот файл, создавая миграцию и добавляя новые файлы миграций в индекс гита:

php -q ./.git/hooks/_pre-commit.php
git add ./ygin/migrations/

Хук pre-commit использует для создания миграции файл protected/runtime/sql_update.txt (не sql_update.log). Предполагается, что разработчик самостоятельно очистит его вручную от ненужных запросов и поменяет расширение с .log на .txt. Это сделано для избежания попадания в миграцию лишних запросов к базе данных.

В результате работы скрипта могут быть созданы 2 миграции - на изменение структуры таблицы (alter) и на изменение содержимого (insert/update/delete). Сделано так, потому что изменения структуры таблицы невозможно откатить по транзакции и такое разделение позволяет снизить число телодвижений в случае наличия ошибки в миграции.

Хук post-merge

Следующий хук срабатывает на post-merge, который запускает прогон миграций, которые могли придти в коммитах.

Хук post-checkout

И последний хук post-checkout меняет текущую базу данных проекта в зависимости от того, с какой веткой будет идти работа. У каждого разработчика должно быть две базы данных - для работы в ветках develop, feature и для веток release, master, hotfix. Две базы необходимы для корректной разработки, когда пишутся долгие задачи и правки БД из них являются критичными.

13 июля 2013

Автор: Михаил Абрамов

Комментарии (2)

Добавить комментарий
  • er
    25.09.2013, 15:29:05

    Здраствуйте. Спасибо за проект. А можно ли как нибудь из настроек сайта выбрать значение, не обращаясь к базе данных?
    • mixa
      26.09.2013, 10:46:45

      Настройки сайта хранятся в базе данных и далее прокидываются в стандартные параметры приложения: можно получить через Yii::app()->params['param_name'].
      Сейчас в каждой сессии делается один запрос на получение всех параметров.
      Но параметры разумно кэшировать, поэтому в следующем релизе сделаем кэширование параметров, и тогда запросов к базе не будет.
      Сейчас же, если надо обойтись без запросов, то сохраните параметры в конфиге приложения.