Как разделить разработку backend и frontend?

Question

[Алексей Васильевич]

Всем привет!

Есть большой проект, в котором бэкенд и фронтэнд пилятся разными группами разработчиков. Как будет правильно и эффективно организовать их работу?

Git, Symfony2

1) один репозиторий, но с submodules - для фронтэндщиков (папки views, web)
2) разные репозитории

Поделитесь советом и опытом

Comments

[Владимир]

Лучше сделать два отдельных репозитория. Все что обьединяет frontend с backend это документация, где ее хранить и как шарить с обеими командами это уже другой вопрос.

Answer 1

[Игорь Воротнёв]

Теоретически конечно могут возникать ситуации, когда и бек, и фронт, лезут редактировать одно и то же место, в одном и том же файле, плюс-минус в одно и то же время. Что может приводить к merge conflicts.

Но, во-первых, такое должно происходить крайне редко. Во-вторых, если это происходит, то это вопрос не совсем корректных процессов или архитектуры. В третьих, такие конфликты легко резолвятся тимлидом.

Поэтому, лично я не вижу никакой проблемы в том, что работа идет в feature branches, каждый делает свою часть, а потом это все мерджится.

Comments

[Иван GiBSON]

Я тоже считаю что ничего разделять не надо

[Алексей Васильевич]

Речь ведь про единый репозиторий, верно?
На самом деле, конфликты иногда встречаются - на уровне шаблонов. То есть пока фронтэндщики gulp-ят css/js/спрайты - все норм. Но когда доходит до внесения изменений в шаблоны, то бывает, что оба разработчика должны править один и тот же файл. И да, пока они ресолвятся волевым решением тимлида )

[Игорь Воротнёв]

Алексей Васильевич, Да, единый. Если одновременные правки одного и того же файла, я написал в ответе - это сигнал о некорректных процедурах. Изменения шаблона фронтендером и бекендером должны быть разнесены в разные issues/tasks, и делаться раздельно. Один таск (логически первый) является блокирующим для второго. Соответственно, второй не может быть начат, пока не сделан первый. Тогда и конфликтов не возникнет.

Answer 2

[Night]

Попробуйте REST API, front работает с четко стандартизированным апи, бэкенд не парится о том как это выглядит.

Answer 3

[Александр Пашкевич]

Сразу скажу, что не имею огромного опыта, но скажу как делаем мы.

У нас совсем маленькая команда. В основном пишем веб-приложения(CRM и тд) на Laravel+Vue/AngularJS. Делаем один репозиторий на BitBucket, раздаем права и как бы все. Backend-еры не лезут в код фронта и наоборот. Следовательно никаких конфликтов не возникает в гите. Ну а если возникает, то там гит сам подсказывает, что да как делать. В основном это просто git add * git commit -m "message". И все конфликты уходят.

Никаких неудобств не испытываем с битбакетом. Опять же можно привязать ключи и не вводить постоянно пароль. И все шутро работает.

Answer 4

[Алексей Васильевич]

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

Comments

[Игорь Воротнёв]

Если нужно реально отделить кусок проекта и дать доступ только к нему сторонней команде разработчиков, при этом чтобы к остальной части проекта у них не было доступа, а члены внутренней команды имели доступ к этому куску - тогда, пожалуй, submodule будет разумным выходом. Либо subtree. Посмотрите на оба варианта, между ними есть полезные различия.

Answer 5

[Тимур Маликин]

Монорепозиторий, зачем себе усложнять жизнь.