Как правильно организовать рабочую среду для крупного проекта с GIT?

Question

[Антон Шелестов]

Всем привет.

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

Планирую разработку среднего проекта(информационный портал), используемые технологии и инструменты: Laravel, GIT, Gulp, возможно React - надо его сначала по изучать)

И теперь интересно как все это организовать и связать с Git

Дальше то что я представляю):

Модель ветвления для Git: мне понравилась вот эта модель https://habrahabr.ru/post/106912/ кажется весьма удобной
Планируется основной домен например site.ru
Тестовый домен testsite.ru - чтобы вся команда могла по тестировать сайт/новые фичи/исправленные баги
И затем после тестирования заливать все на основной домен.
С файлами то все понятно, но больше всего меня интересует как работать с MySQL при таком подходе.
Ведь получается то что база одна у site.ru
testsite.ru - использует базу site.ru?
А так же локальные версии сайтов какую используют базу?

Либо клонировать базы с site.ru на testsite.ru и локальный сайт?
Если база меняет структуру создавать миграции и потом применять миграции на site.ru?

А еще такая ситуация: на сайте будет много изображений(на пару гигов), все на гит заливать тупо...
для testsite.ru тоже как-то тупо дублировать все изображения.
Аналогично с локальной версией.

Мне представляется следующее решение:
использовать поддомен типа image.site.ru или новый домен типа imagesite.ru

Вот вроде все)
Вот эти моменты пока не могу понять как должны быть организованны.

Хотелось бы услышать как Вы решали подобные задачи для своих похожих проектов.

Надеюсь кто-то решился прочитать этот длинный вопрос))

Answer 1

[Alexander Pushkarev]

- Для изображений можно использовать s3, если же всё же захотите хранить у себя, то просто кидайте их в папку, которая в gitignore. И 2гб для изображений это не много, а очень мало.
- База должна клонироваться, а не использоваться одна и та же.
- Миграции для того и придумали, чтобы удобно можно было модифицировать базу.
- Должно быть 3 сайта: dev.site.ru, pre-prod.site.ru, site.ru. На первом разработка, на втором тест новых фич, ну и продакшн.

Comments

[Антон Шелестов]

- как раз про s3 думал) ну 2 гига это только начало)
s3 еще думаю будет более правильным, не придется ссылаться с тестовых сайтов на основной.
- ок, наконец то от кого-то это услышал, значит в правильном направлении думаю)
- получается сначала каждый работает с локальной копией, потом заливают на dev, затем на pre-prod тестируют какую-то пачку обновлений и на продакшн выкатывают рабочее обновление?

Answer 2

[zorca]

Во-первых использовать Bitbucket, там очень все гибко и удобно для командной работы, они даже сделали сейчас связку с Trello. что просто великолепно. Команда до 5 человек - халява. Потом можно четко настроить права каждого разработчика на запись. Картинки на несколько гигов - это не программная часть, безусловно ее не нужно хранить в гите, только картинки, качающиеся элементов интерфейса. Должна быть четкая инстуркция для вновь прибывающих по порядку работы с репозиторием - каждый обычно работает в своей ветке или в ветке фичи, если ему дано определенное задание, при каждом старте работы каждый разработчик должен подтянуть к себе в ветку обновы из центровой ветки разработки. Когда он все протестит у себя, сможет отправить свои имзенения на проверку в основную ветку. Никаких прав никому кроме старшего на запись в основную ветку! Иначе это будет хаос. Периодически все по команде будут также делать миграции в своих ветках. Ну и обязательно должен быть тимилид, который будет всем этим безобразием руководить, разруливать конфликты в репозитории, разделять и властвовать.

Comments

[Антон Шелестов]

Спасибо! у Bitbucket даже приват бесплатный

[zorca]

Антон Шелестов, да и возможности команд до 5 человек на команду

[Антон Шелестов]

zorca, а про MySql можете что-нибудь сказать?

[zorca]

Антон Шелестов, для разработки не нужна по сути ВСЯ база. Достаточно тестовых каких-то данных. А тестовые данные в локальной среде разработки можно организовать при помощи генераторов (чуть ниже уже подсказали Faker) и сидированием через классы, эта возможность помимо миграций встроена в Laravel. Внесли новый тип данных, сделали тестовый генератор этих данных. И пускай их на продакшене будет миллиард, зачем нам столько тянуть к себе? В общую же ветку разработки старший уже может подтянуть реальную базу. Что-то пошло не так с реальными данными? Меняем генератор, незачем опять же тонны данных тянуть на локалку. Я могу быть не прав, прошу воспринимать как личную точку зрения, проверенную на небольших проектах с 1 тимлидом и 3-4 падаванами. ))) Если для сдачи проекта достаточно небольшой базы данных, то мы просто держим ее в гите основном, обновляем ее на тестовом сервере и каждый разраб тянет ее по команде себе. Но это речь идет о WordPress. там просто нет приятных возможностей Laravel.

[Антон Шелестов]

zorca, Про Faker и сиды я знаю, но еще не было возможности их использовать.
Спасибо буду пробовать)

Answer 3

[Sergej]

Организовать можете как угодно.
Скажу как у нас, команда разрабов из 14 человек. Остальные это менеджеры, тестировщики и т.р.

GIT и процесс работы:
Bitbucket, Jira.
Используем Kanban.
Создается таск/баг/... с номером, который выставляется автоматически. Назначается исполнитель. Для назначений, есть проект-менеджер и т.п. В продукте JetBrains выбирается пункт - open task. Создается автоматически ветка с номером задачи (пущай будет test389).
Далее вы кодите или чем там занимаетесь, выливаете в репу на удаленную ветку test389.
По вашему коду проводят кодревью, если все норм то сливают в мастер.
При мердже с мастером, автоматически запускаются тесты.
Если все ок, выливают на дев сервер, там за дело берутся тестеры.
Когда тестеры все проверили и одобрили, изменения (обычно их пачка), выливаются на прод.

Хранение изображений
Вариантов много, но мы используем mongodb. Там уже более миллиона фотографий.

Базы
база должна быть одинаковая на всех видах сайта (тест, дев, прод...), для этого используются миграции.
Для фейковых данных можно использовать Faker.

P.S.
В гит вы храните только свой код, вендор там не нужен.

Comments

[Антон Шелестов]

Спасибо!
Т.е. к примеру пришел новый разработчик, клонирует себе проект на компьютер, composer install, artisan migrate. Получается актуальная структура базы, но пустая.
И дальше юзать Faker?
Просто еще не пользовался им, не знаю удобно ли.

[Sergej]

Антон Шелестов, Да, все верно. В миграциях тоже могут быть данные, которые необходимы.
Так же можно необходимые данные (скажем тестовые пользователи с разными ролями) засунуть в фикстуры фейкера.