Как организовать несколько репозиториев на github для сложного приложения?

Question

[MegaMufa]

Добрый день.

Есть проект, который хотим отдать в open source. Для этого планируем выложить код на github. ПО изначально создавалось с прицелом на свободное распространение, поэтому языки использовали мейнстримные, мускул вместо постгреса и т.д. Но вот с тем, в каком виде выложить код небольшие трудности.

Само ПО состоит из двух частей: REST сервер на php и singlepage приложения на ts + react. Сами по себе они разрабатывались независимо. Единственное, что их связывает - это для клиента надо указать адрес rest сервера, а для серверда добавить домен клиента в список допустимых доменов для CORS.

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

Еще на сервере используем apidocs. Те, коду надо сами себе сгенерят свежую. Но для удобства, надо бы где-то ее хранить готовую, например на github pages.

Получается, что кода довольно много и хранить это надо хоть и раздельно, но вместе. Решили для этого завести организацию на гитхабе и у нее наделать реп: для ядра, для доков, для примеров. Тут вроде все понятно получается.

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

Подскажите, у кого есть опыт ведения подобных составных проектов на гитхабе, как будет удобнее разработчикам, контрибьюторам и пользователям? Буду благодарен за любые соображения в этом плане.

Answer 1

[Алексей Ostin]

PHP оформляйте как composer-пакеты, тогда весь проект будет собираться легко и просто. Здорово, если сумеете настроить `composer build-project` для быстрого разворачивания. Еще есть решение поверх композера для упрвления конфигами и статикой: Puli. Попробуйте его, может подойдет вам.

Клиентский код лучше продублировать скомпилированными файлами (рядом с ts положить js и по возможности min.js). Зависимости опять же через менеджер npm/bower/... Если фронтенд - отдельное приложение, то, соответственно, в отдельную репу.

Документацию (ту, что из apidoc генерится) лучше держать поближе к коду (в том же репозитории) - будет легче бороться с рассинхронизацией кода и документации. Автоматически получите документацию с привязкой к версии кода.

Для общей документации - отдельный репозиторий + github pages (хотя, возможно оформлять и через wiki-разделы)

Можно сделать отдельный репозиторий с примером приложения, где будут указаны все зависимости и присутствовать пример конфига.

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

Comments

[MegaMufa]

Спасибо з подробный ответ. Так и сделаю. Только серверне ядро через composer не получится сделать. Приложение подобно wordpress устанавливается и работает. Разработчик может переопределять контроллеры и модели через IoC контейнеры, но основная логика неизменна. А вот дополнительные модули, да, будут через composer ставится. Еще раз спасибо.

Answer 2

[Владимир]

Всё раздельно.

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

Ничего страшного.