Напортил базу - просто переподнял, и опять чистая база

ок, ок

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

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

вот, также работаю: срезы, тесты, дампы.

"Тут можно рассказать про замечательный Docker, но у меня как-то исторически сложился сугубо негативный опыт работы с ним. Сам ни разу не настраивал, но каждый раз, когда приходил в проект и говорили: «У нас тут Docker, развернуть окружение — дело получаса», в итоге всё затягивалось в лучшем случае дня на три, а потом и сами разработчики признавались, что докер у них никогда не работал. " ?

https://habrahabr.ru/post/319582/

"Тут можно рассказать про замечательный Docker, но у меня как-то исторически сложился сугубо негативный опыт работы с ним. Сам ни разу не настраивал, но каждый раз, когда приходил в проект и говорили: «У нас тут Docker, развернуть окружение — дело получаса», в итоге всё затягивалось в лучшем случае дня на три, а потом и сами разработчики признавались, что докер у них никогда не работал. " ?

а это много где. я тоже часто слышу про реплику mysql, но нормально она нигде в итоге не работаеи

Так, позвольте я подитожу. Сообщество рекомендует строить процесс разработки вот так: 1. У каждого разработчика запущена ОС в виртуалбоксе на своей локальной машине 2. В виртуалке установлен докер и развернута дев версия проекта 3. На хост машину прокинута папка с кодом проекта 4. База наполняется из заранее заготовленного дампа с тестовыми данными 5. Чтобы ходить на дев версию проекта можно руками прописать все домены в hosts или юзать http://xip.io/ 6. Таким образом можно заранее заготовить образ виртуалки для своего проекта и раздавать его разработчикам для упрощения развертывания. 7. Для упрощения связи между разработчиками можно поднять VPN сеть. Например войти на версию проекта коллеги. Все верно? Может что-то еще порекомендуете?

Что-то мне подсказывает что в моей схеме есть костыль.

а почему не юзать обычный докер, нафига виртуалка?

у некоторых стоит винда, да

а почему не юзать обычный докер, нафига виртуалка?

если в качестве хоста юзается винда... да и на макс ос докер ставить не очень :(

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

Вот чел пишет

http://silentsokolov.github.io/2014/12/26/nedostatki-lokalnoj-razrabotki-s-pomoshchju-vagrant-i-docker.html

если в качестве хоста юзается винда... да и на макс ос докер ставить не очень :(

докер для винды и для мака это тоже виртуалка

но не надо ебаться с /etc/hosts

тогда к чему вопрос про зачем виртуалка?))

если докер это виртулка

докер для винды и для мака это тоже виртуалка

я потому и не ставлю его на свой мак, кругом костыли :)) Уже лучше тогда явно поставить виртаулку с линуксом и в него докер.

или нет?

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

у меня виртуалка с докером поднимается вагрантом, который создаёт NFS шару. По NFS вроде годно работает. Хотя стресс тестов не делал.

если докер это виртулка

к тому, что он хендлит пробросы портов и т.д.

я потому и не ставлю его на свой мак, кругом костыли :)) Уже лучше тогда явно поставить виртаулку с линуксом и в него докер.

+1

к тому, что он хендлит пробросы портов и т.д.

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

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

где?

и выставить интернал сетевой интерфейс что бы порты не пробрасывать а по апишнику ходить

у меня виртуалка с докером поднимается вагрантом, который создаёт NFS шару. По NFS вроде годно работает. Хотя стресс тестов не делал.

ну вот по ссылке выше писалось про тормоза как раз с варгантом.

(владельцем Mac OS и Linux повезло можно использовать NFS, где все довольно быстро)

парень в статье просто не разобрался, что NFS в винде тоже прекрасно работает.

(владельцем Mac OS и Linux повезло можно использовать NFS, где все довольно быстро)

блин, я до варганта еще не дошел.

блин, я до варганта еще не дошел.

Вагрант уже использовать не кошерно

Вагрант уже использовать не кошерно

а что кошерно?

а что кошерно?

А смотря для чего.

Где-то докер. Где-то нативно

Где-то кубернетес и coreos

А смотря для чего.

для организации среды разработки :)

для организации среды разработки :)

Сайтики делать? Докер тебе бро

Еще из докера хорошие билд машины выходят

Сайтики делать? Докер тебе бро

там выше куча всего написано на эту тему :) лучше прочесть

Где-то кубернетес и coreos

вообще вы не в ту степь пошли

Так, позвольте я подитожу. Сообщество рекомендует строить процесс разработки вот так: 1. У каждого разработчика запущена ОС в виртуалбоксе на своей локальной машине 2. В виртуалке установлен докер и развернута дев версия проекта 3. На хост машину прокинута папка с кодом проекта 4. База наполняется из заранее заготовленного дампа с тестовыми данными 5. Чтобы ходить на дев версию проекта можно руками прописать все домены в hosts или юзать http://xip.io/ 6. Таким образом можно заранее заготовить образ виртуалки для своего проекта и раздавать его разработчикам для упрощения развертывания. 7. Для упрощения связи между разработчиками можно поднять VPN сеть. Например войти на версию проекта коллеги. Все верно? Может что-то еще порекомендуете?

Вообще отличная схема, кстати.

вообще вы не в ту степь пошли

Обоснуйте

Так, позвольте я подитожу. Сообщество рекомендует строить процесс разработки вот так: 1. У каждого разработчика запущена ОС в виртуалбоксе на своей локальной машине 2. В виртуалке установлен докер и развернута дев версия проекта 3. На хост машину прокинута папка с кодом проекта 4. База наполняется из заранее заготовленного дампа с тестовыми данными 5. Чтобы ходить на дев версию проекта можно руками прописать все домены в hosts или юзать http://xip.io/ 6. Таким образом можно заранее заготовить образ виртуалки для своего проекта и раздавать его разработчикам для упрощения развертывания. 7. Для упрощения связи между разработчиками можно поднять VPN сеть. Например войти на версию проекта коллеги. Все верно? Может что-то еще порекомендуете?

а где тут CI?

а где тут CI?

а каким местом CI к разработке?) На CI у меня деплой: сборка контейнеров, тесты и деплой.

а каким местом CI к разработке?) На CI у меня деплой: сборка контейнеров, тесты и деплой.

CI самым непосрественным местом, разработка без CI это мягко говоря странно

тесты где разрабы гонять будут?

CI самым непосрественным местом, разработка без CI это мягко говоря странно

а расскажи что оно будет делать?

а расскажи что оно будет делать?

собирать проект, прогонять тесты, билдить артефакты

тесты разные, от unit тестов до сквозных тестов

собирать проект, прогонять тесты, билдить артефакты

опять же... это все надо перед билдом. Зачем это разработчикам?

их задача пушить код в репо и чтобы он работал. Деплой это отдельная тема. Не?

Я честно не понимаю :)

их задача пушить код в репо и чтобы он работал. Деплой это отдельная тема. Не?

причем деплой к CI?

это по моему уже другая тема

мне просто интересно

изначально был вопрос как организовать дев

а кто как дальше работает с CD CI Это дело каждого

изначально был вопрос как организовать дев

максимально просто

чем меньше сущностей тем лучше

в общем я не придумаю чем мне CI поможет в разработке. CI срабатывет когда я мержу master > production и тогда уже сборка контейнеров, тесты, и деплой на продакшен.

чем меньше сущностей тем лучше

расскажите это разработчикам ядра линукс))))

CI срабатывает сразу, как изменилась хотя-бы строка кода

у кого как

совсем не обязательно делать именно так

расскажите это разработчикам ядра линукс))))

взять уникальный в своем роде проект это так репрезентативно

CI срабатывает сразу, как изменилась хотя-бы строка кода

у меня работа всех 5-ти сценариев CI перед деплоем занимает около 12 минут. Выкачка всех заивисомосте. запаковска, тесты и пушы в регистри... так что мне такое вариант не годиться :)

Я оптимизировал как смог :)

ERROR: S client not available

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

Я оптимизировал как смог :)

оки, тогда какую роль выполняет докер?

какую проблему решает

какую проблему решает виртуалка?

оки, тогда какую роль выполняет докер?

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

виртуалка решает проблему независимости от ОС

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

PHP?

виртуалка решает проблему независимости от ОС

docker

PHP?

да

под виндой нет докера

докер тулс это поделье

под виндой нет докера

нет есть

нет нет

докер тулс это поделье

docker for windows

вот и договорились

точнее есть но очень костыльно, так же и под мак ос

дальше говорить в общем то не очем)

точнее есть но очень костыльно, так же и под мак ос

а чем костыли от разработчиков докера хуже ваших костылей?

дальше говорить в общем то не очем)

?

Так, позвольте я подитожу. Сообщество рекомендует строить процесс разработки вот так: 1. У каждого разработчика запущена ОС в виртуалбоксе на своей локальной машине 2. В виртуалке установлен докер и развернута дев версия проекта 3. На хост машину прокинута папка с кодом проекта 4. База наполняется из заранее заготовленного дампа с тестовыми данными 5. Чтобы ходить на дев версию проекта можно руками прописать все домены в hosts или юзать http://xip.io/ 6. Таким образом можно заранее заготовить образ виртуалки для своего проекта и раздавать его разработчикам для упрощения развертывания. 7. Для упрощения связи между разработчиками можно поднять VPN сеть. Например войти на версию проекта коллеги. Все верно? Может что-то еще порекомендуете?

поднимите “нативный” докер, разверните образ окружения, прокиньте туда рабочую папку с проектом (если это возможно) или уже с собранным проектом который обновляется при сборке, отдельно поднимите контейнер с базой

куда и заливайте дампы

все эти контейнера будут доступны на localhost

производительности docker for windows должно хватить с головой

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

докер фор виндовс та же самая виртуалка

так что оверхед одинаковый

точнее есть но очень костыльно, так же и под мак ос

собсна у дева получается процесс следующим образом: он качает с гита проект, запускает скачанный конфиг докера - ему выкачиваются все образы и стартовый скрипт воссоздает базу, файлы там генерит какие надо, права и это все. Далее чел подлючает к проекту шторм, запускает тестовый код и проверяет работоспособность системы. Ну и начинает пахать.

так что оверхед одинаковый

эм, Я ничего не имел ввиду по поводу оверхеда по производительность, имелся ввиду оверхед в управлении всем этим добром

собсна у дева получается процесс следующим образом: он качает с гита проект, запускает скачанный конфиг докера - ему выкачиваются все образы и стартовый скрипт воссоздает базу, файлы там генерит какие надо, права и это все. Далее чел подлючает к проекту шторм, запускает тестовый код и проверяет работоспособность системы. Ну и начинает пахать.

а что значит подключается штормом? Открывает папку проекта в шторме или как?

докер фор виндовс та же самая виртуалка

Виндовс для разработчика это уже оверхед, если разработчик не .net

эм, Я ничего не имел ввиду по поводу оверхеда по производительность, имелся ввиду оверхед в управлении всем этим добром

vagrant up vagrant ssh

Виндовс для разработчика это уже оверхед, если разработчик не .net

ну это да