Vagrant и компания

[Absinthe]

А. Неработоспособно. Все будет сильно тормозить, либо постоянно рассинхронизироваться (в зависимости от способа подключения).
Б. Нормальный рабочий вариант.
В. Как Б, но много минусов из-за состояния базы. Как откатиться на нужную версию, например?

Это называется "нечего на зеркало пенять если руки кривые".
8 хватает не только для PHPStorm с виртуалкой, но даже для комфортной разработки на Eclipse/Tomcat/JDK, которому для сборки проекта без GUI надо минимум 4.

Ты слишком назойливо постоянно всех по себе мерить пытаешься.
Мне 8 тоже не хватает. Как и не хватает 512 под виртуалку.

 

[fixxxer]

Но я не вижу причин отнимать у них эти гиги, когда на сервере разработки 64Г+ простаивает с кучей ядер и даст гораздо лучше производительность.

Ну дык я потому и за комбо. Пришел в офис, юзаешь базу на сервере, решил поработать глядя на горы и волны - слил себе снапшот.

 

[MiksIr]

А. Неработоспособно. Все будет сильно тормозить, либо постоянно рассинхронизироваться (в зависимости от способа подключения).

На самом деле работоспособно.
Более того, много лет у меня в офисе так и сидели - монтирование по самбе шары компьютера разработчика с файлами. Все весьма резво работало. Иногда только, когда кто-то выключит компьютер - все раком вставало (как правило nginx, блокирующийся полностью на заглохшей сетевой ФС).
Основные проблемы начались когда появились люди принципиально желающие работать на своих ноутах.
Пробовал варианты и без сетевой ФС... помнится, даже у котерова была какая-то утилитка синхронизации. С этим сложнее, иногда разработчик переключался на браузер и тыкал Ф5 быстрее, чем файл синхронизировался
В общем вполне рабочие варианты, то сейчас есть желание от них отойти. Во многом на перспективу, ну и что бы всякие блокировки не ловить.

В. Как Б, но много минусов из-за состояния базы. Как откатиться на нужную версию, например?

М... а зачем? Дай пример. Схема базы в миграциях прописана. Данные все-равно фейковые. Можно делать переодический бакап и откатить если что, только вот не помню, что бы когда-то нужно было.

А, если только в плане с откатом ревизии кода? Ну тутхорошее правило - "не меняй, не удаляй", которое всем вдалбливается. Помогает и при деплое, и с любой старой версией кода работает, хотя в общем, наверно, полезно было бы. Только, а как это делается в случае своей базы? Снепшоты на каждый комит?

 

[grigori]

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

 

[Absinthe]

На самом деле работоспособно.
Более того, много лет у меня в офисе так и сидели - монтирование по самбе шары компьютера разработчика с файлами. Все весьма резво работало. Иногда только, когда кто-то выключит компьютер - все раком вставало (как правило nginx, блокирующийся полностью на заглохшей сетевой ФС).
Основные проблемы начались когда появились люди принципиально желающие работать на своих ноутах.
Пробовал варианты и без сетевой ФС... помнится, даже у котерова была какая-то утилитка синхронизации. С этим сложнее, иногда разработчик переключался на браузер и тыкал Ф5 быстрее, чем файл синхронизировался
В общем вполне рабочие варианты, то сейчас есть желание от них отойти. Во многом на перспективу, ну и что бы всякие блокировки не ловить.

Когда ФС разные, то может быть либо быстро, либо надежно. И, поэтому, будет какая-то из проблем, особенно если файлы могут изменяться сразу на нескольких машинах (например, консольные генераторы кода).
А в способах Б и В ФС одна. Поэтому не нужно выбирать.

М... а зачем? Дай пример. Схема базы в миграциях прописана. Данные все-равно фейковые.

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

Только, а как это делается в случае своей базы? Снепшоты на каждый комит?

http://laravel.com/docs/5.1/seeding, в том числе и с помощью Faker.
Структура базы строится по миграциям, потом база инициализируется новыми объектами через ORM.

 

[MiksIr]

Когда ФС разные, то может быть либо быстро, либо надежно. И, поэтому, будет какая-то из проблем, особенно если файлы могут изменяться сразу на нескольких машинах (например, консольные генераторы кода).
А в способах Б и В ФС одна. Поэтому не нужно выбирать

Да какая же одна. Все-равно присутствует прослойка в виде файловой системы виртуалбокса. Которая, к слову, не блещет показателями. Помню, были где-то тесты, которые показывали, что NFS внутри виртуалбокса много производительнее, чем родное, да и SMB на чтение вроде опережала.

Структура базы строится по миграциям, потом база инициализируется новыми объектами через ORM.

Да, понял, в общем прикольно. Хотя операция не такая уж частая, можно в конфиге просто новую схему указать, и там развернуться - наверно, можно и автоматизировать такое. Спасибо.

 

[Absinthe]

Да, понял, в общем прикольно. Хотя операция не такая уж частая, можно в конфиге просто новую схему указать, и там развернуться - наверно, можно и автоматизировать такое. Спасибо.

Это уже оптимизировано на уровне инструмента миграций: обычно после последней дампится схема.