Написание проектов с использованием GIT - это хорошо и уже более менее мне понятно. Но вот в начале разработки я задумался, а как же хранить версии БД, как сливать их разным разработчикам и так далее?
Далеко не отходя от разработки, хотелось бы поинтересоваться, как вы ограничиваете часть разработчиков от тех или иных файлов? Репозиторий же один и там, как правило, лежит весь проект, соответственно, каждый новый разработчик получает полные исходники, как быть?
По второму вопросу: если это критически необходимо - дробить проект (и код соответственно) на подпроекты.
Отдельно админка, отдельно сайт, отдельно какое нибудь внутренее апи с математикой итд.
Отлично! Только вот полностью проходя по пунктам документации, совсем другое получается. Например, после создания новой миграции ($ php vendor/bin/phinx create MyNewMigration) содержимое файла кардинально отличается, что влечет за собой полное отсутствие понимания дальнейшей работы. Кроме официальной документации, мануалов не нашел. Не знаю, как быть.
hrvasiliy:
Не понял содержимое какого файла отличается. Каждая миграция это отдельный файл - некое атомарное изменение базы.
Разработчик начинает работу, создает себе ветку в git.
Создает миграции какие ему нужны.
Периодически заливает к себе из develop изменения других участников, накатывает их миграции, убеждается что его миграции не конфликтуют с миграциями из девелопа будучи накачены поверх.
Заканчивает работу, сливает все в девелоп.
hrvasiliy: как абсолютно правильно написал Тимур Рамазанов "Updating or switching branches is then very simple: nuke the database, load a dump to establish the baseline, run the scripts"
hrvasiliy: при чем тут дампы??
Миграция это запрос который изменяет структуру базы!
Ну в крайнем случае какие то служебные справочники.
Вот Вам пример одной миграции с живого проекта joxi.ru/V2Vn6aqIl79Y2v
Вот Вам пример другой миграции с контентом joxi.ru/1A5bLyjh8Lg7rE
Дмитрий Энтелис: Понял, буду пробовать вникать. А по поводу того, что у меня содержимое файла отличается так это вот docs.phinx.org/en/latest/migrations.html#creating-... После создания миграции, в моем файле отсутствуют методы up и down, я так понимаю, они должны были создаться сами или же это ручками дописывать?
hrvasiliy: странно, у меня они сами создаются. ну допишите руками, делов то.
На всякий случай посмотрите что в phinx.yml прописано
и делали ли Вы init php vendor/bin/phinx init
Миграции - это что-то вроде системы контроля версий для вашей базы данных. Они позволяют команде программистов изменять структуру БД, в то же время оставаясь в курсе изменений других участников. Миграции обычно идут рука об руку с конструктором таблиц для более простого обращения с архитектурой вашего приложения.
Это начало документации по миграциям в фреймворке laravel. Предлагаю с ними ознакомиться на его примере. laravel.su/docs/5.0/migrations
По большому счету, миграция - это класс с двумя методами up() и down(). Первый для внесения изменений в БД, второй для отката изменений. Допустим, мы пишем модуль для сайта, подразумевающий добавление колонки в таблицу users. Тогда мы создаем класс AddColumnToUsers расширяющий класс миграций и реализуем методы up и down. В первом пишем код на добавление колонки, в down - на удаление колонки. И применяем миграцию локально. Заливаем в git, другой разработчик ее выкачивает и применяет у себя. Для заполнения БД используется сидер, с похожим механизмом
С миграциями не все гладко, хоть это и стандарт. Например, если в разных ветках разный набор миграций, то при переключении веток БД может оказаться в "несогласованном" с кодом состоянии. А что такое сиды? Никогда не слышал.
Тимур Рамазанов: Как быть тогда? Как люди делают хорошие проекты? Как вообще можно организовать нормальную работу в команде не думая о версионном контроле БД?
hrvasiliy: такие проблемы (именно серьезные проблемы) могут возникнуть, я думаю, в очень сложных по части контроля версий проектах. Мне кажется, в очень многих проектах на такое не напороться. Когда я сам об этом задумался и гуглил, нашел вот это - stackoverflow.com/questions/6409204/database-migra... Там человек рассказывает о процессе в их проекте. Вкратце: "Updating or switching branches is then very simple: nuke the database, load a dump to establish the baseline, run the scripts"
Как вариант: хранить метаданные БД в виде скрипта. Разработчик вносит изменения в структуру - выражает всю БД в скрипт. Изменения по структуре в таком виде проще мониторить.
Ограничивать по веткам, каждый делает кусочек кода в своём, потом собирать
