Как построена разработка системы

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

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