Как шарить папку с фичами между проектами

общие вопросы
, , , , , , , ,
#1

Всем привет.
Продукт, который собираемся покрывать тестами, как водится представлен бэкендом и фронтендом. Каждый в своём репозитории. В будущем бэкенд планируется дробить дальше по микросервисам.
На проекте пытаемся придерживаться BDD подхода и писать сценарии на разрабатываемые фичи. Правильный BDD рекомендует абстрагироваться от конкретной реализации сценариев и декларировать их в общем виде, который а) понятен бизнесу, б) не будет подвержен постоянному изменению по следам интерфейса, через который пользователь будет этим добром пользоваться (Desktop\Web\API\Mobile\etc.)

Возникла такая проблема\задача: как наиболее удобным образом шарить Gherkin(Cucumber) сценарии между разными репозиториями? То есть фичи\сценарии пишутся в одном месте, а их реализация уже идёт в каждом сервисе отдельно. Условно в UI мы проверяем через тыкание кнопок, в API дёргаем методы. Но в обоих вариантах реализуем один и тот же пользовательский сценарий Given-When-Then
На поверхности всплывают две фичи самого GIT, которые я лично раньше активно не трогал:

Сегодня поигрался с Submodules. Идея ясна, решает поставленную задачу, но чёт это оказалось совсем не просто и прямолинейно :slight_smile: Что я сделал - в сервис с кодом проекта подключал репозиторий со сценариями как Submodule. Код\текст сценариев из подмодуля видно отлично. Но вот с коммитами\бранчами\реквестами начинаются вопросы по удобству.

Основная проблема\претензия, которую пока сейчас готов сформулировать с Submodules - из прошлого опыта могу сказать, что в рамках работы над реализацией шагов сценария там (в сценарии) часто находятся неточности. То опечатка, то состав каких-нть данных уже изменился со времени написания, то ещё что всплывёт. Так вот получается, что когда создаёшь PR по тестам, то изменения в самих сценариях не видны. Они скрыты от ревью и вообще идут немного отдельным процессом, что несколько непривычно как минимум.
Следующим слоем - я начал переживать а какая каша там заварится когда над фича файлом начнут работать в параллель команды фронтенд\бэкенд и что там будет с конфликтами… Как жить с конфликтами в рамках одного репозитория дело привычное - а как быть с ними если проект подключен как подмодуль пока сложно представить.

В планах поиграться с Subtrees с такими же сценариями использования, но пока решил спросить опыт коммьюнити.
У кого-нть была похожая проблема?

Глянул похожие темы на форуме, но ответа для себя не нашёл.

#2

ну вообще сабмодуль как решение выглядит хорошо, главное понять, что вы в базовом проекте ссылаетесь на коммит сабмодуля, и что надо просто регулярно выполнять обновление сабмодуля
почему это хорошо? если у вас написаны фичи и здесь и сейчас они работают, то сломаться ничего не должно, потому что у вас жёстко зафиксирована версия сабмодуля; забрали изменения в сабмодуле и старые тесты перестали проходить? кто-то непорядочный поменял то, что менять не надо

1 лайк
#3

В общем попробовал я Git Subtree.
В ближайшем круге поиска обнаружились только две внятные статьи от одного автора раскрывающие суть и преимущества перед SubModules. Раз и Два

Для себя я увидел концептуальное различие в удобстве работы с файлами в общей папке. Можно делать коммиты как буд-то это обычная папка. Изменения в общей папке можно даже не выделять в отдельный коммит!
Но есть в некотором смысле слабое место - можно забыть сделать git subtree push в общую репу, чтобы залить все свои изменения. Если выполнить эту команду, то Git сам выделяет изменения только в общей папке через split и заливает в корневую репу изменения атомарно. Выглядит очень круто! Мне показалось это гораздо проще и удобнее чем Submodules.

Но на нашем проекте мы погоняли обе технологии и лично к моему сожалению решили придерживаться Git Submodules. Причины:

  • гарантия, что в общей папке Features точно не может быть различий по разным сервисам так как тебе не дают возможности забыть сделать коммит
  • более чёткая фиксация на конкретной версии в общем репозитории. В сервисном проекте, который в данном случае будет выступать в роли super-project можно выбирать на какой коммит встать.