Этот раздел будет полезен всем кто участвует в доработках системы, а также будет интересен в целом всем, т.к. применяются несколько интереных подходов к разработке системы.
В первую очередь, используется система контроля версий 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. Две базы необходимы для корректной разработки, когда пишутся долгие задачи и правки БД из них являются критичными.
Сейчас в каждой сессии делается один запрос на получение всех параметров.
Но параметры разумно кэшировать, поэтому в следующем релизе сделаем кэширование параметров, и тогда запросов к базе не будет.
Сейчас же, если надо обойтись без запросов, то сохраните параметры в конфиге приложения.