Я хотел бы знать, имеет ли смысл разделять проект, над которым я работаю, на два репозитория вместо одного.
Из того, что я могу сказать:
- Интерфейс будет написан на html + js
- Бэкэнд в .net
- Внутренний интерфейс не зависит от внешнего интерфейса, а внешний интерфейс не зависит от внутреннего интерфейса.
- Интерфейс будет использовать успокоительный API, реализованный в бэкэнде.
- Веб-интерфейс может быть размещен на любом статическом http-сервере.
На данный момент хранилище имеет такую структуру:
корень:
- внешний интерфейс/*
- бэкенд / *
Я считаю ошибкой держать оба проекта в одном репозитории. Поскольку оба проекта не имеют зависимостей между собой, они должны принадлежать отдельным репозиториям и, если необходимо, родительскому репозиторию с подмодулями.
Мне сказали, что это бессмысленно и что мы не получим никакой выгоды от этого.
Вот некоторые из моих аргументов:
- У нас есть два модуля, которые не зависят друг от друга.
- Наличие истории обоих проектов в долгосрочной перспективе может усложнить ситуацию (попробуйте поискать в истории что-то во внешнем интерфейсе, пока у вас есть половина коммитов, которые совершенно не связаны с ошибкой, которую вы ищете)
- Конфликт и слияние (Этого не должно быть, но если кто-то подтолкнет к бэкэнду, он заставит другого разработчика вытянуть изменения бэкэнда, чтобы подтолкнуть изменения внешнего интерфейса.)
- Один разработчик может работать только с бэкэндом, но ему всегда придется использовать внешний интерфейс или наоборот.
- В конце концов, когда будет время для развертывания. В некотором смысле, веб-интерфейс может быть развернут на нескольких статических серверах при наличии одного внутреннего сервера. В любом случае, люди будут вынуждены либо клонировать с ним весь бэкэнд, либо создать собственный скрипт для отправки на все серверы только внешнего интерфейса или для удаления бэкенда. Проще всего нажать / вытащить только внешний или внутренний интерфейс, чем оба, если нужен только один.
- Встречный аргумент (один человек может работать в обоих проектах). Создайте третий репозиторий с субмодулем и развивайте его. История хранится в отдельных модулях, и вы всегда можете создать теги, в которых версии бэкэнда / внешнего интерфейса действительно работают синхронно. Наличие обоих фронтэнда / бэкенда в одном репо не означает, что они будут работать вместе. Это просто объединяет обе истории в одно большое репо.
- Наличие внешнего интерфейса / бэкенда в качестве подмодулей облегчит задачу, если вы захотите добавить фрилансера в проект. В некоторых случаях вы действительно не хотите предоставлять полный доступ к базе кода. Наличие одного большого модуля усложнит ситуацию, если вы захотите ограничить то, что «посторонние» могут видеть / редактировать.
- Ввод ошибки и исправление ошибки, я вставил новую ошибку в веб-интерфейс. Тогда кто-то исправит ошибку в бэкэнде. С одним хранилищем откат до новой ошибки также откатит бэкэнд, что может затруднить его исправление. Мне бы пришлось клонировать бэкэнд в другой папке, чтобы он работал во время исправления ошибки во внешнем интерфейсе ... затем попытался бы исправить ситуацию ... Наличие двух хранилищ будет безболезненным, потому что перемещение HEAD одного репо выиграло не меняй другой. И тестирование против другой версии бэкэнда будет безболезненным.
Может ли кто-нибудь дать мне больше аргументов, чтобы убедить их, или хотя бы сказать, почему бессмысленно (более сложно) разделять проект на два подмодуля. Проект новый, а кодовой базе - пара дней, поэтому исправление еще не скоро.
источник
Некоторые из ваших аргументов верны, а некоторые нет.
Это на самом деле не совсем верно. Чтобы иметь возможность общаться, и передний и внутренний должны иметь общий интерфейс (описание). Это делает его слабым аргументом в пользу наличия обоих в общем хранилище. Но только слабый аргумент, поскольку он не имеет большого значения.
Это фиктивный аргумент. Если вы хотите посмотреть, как исправлена конкретная ошибка, посмотрите в трекере ошибок, для которого фиксация содержит исправление. И если вы хотите узнать, как развивался конкретный фрагмент кода, вы посмотрите историю отдельного файла (или, самое большее, несколько). В любом случае наличие в хранилище других файлов, возможно из других модулей, не должно усложнять ситуацию.
Это фиктивный аргумент. Я не знаю ни о какой (наполовину приличной) VCS, где вам нужно синхронизировать весь репозиторий, прежде чем вы сможете зафиксировать / отправить свои изменения. Самое большее, вам нужно синхронизировать папки, которые содержат измененные файлы (и часто только сами файлы).
Это тот же фиктивный аргумент, что и предыдущий.
В зависимости от того, как люди предполагают, что развертывание будет выполнено, это может быть действительным аргументом. Если развертывание будет выполнено путем распаковки zip-файла / tarbal на сервере, то не имеет значения, как организованы ваши репозитории. Если развертывание будет выполнено путем извлечения (части) хранилища на сервере, то может быть хорошей идеей использовать отдельные хранилища для модулей, которые развертываются отдельно.
Это верный аргумент, но он не такой сильный.
Это верный аргумент.
Это ложный аргумент, потому что это будет означать, что после двух исправлений в одном модуле вы не сможете вернуть первый. Любая полуприличная VCS позволит вам откатить почти любой старый коммит (хотя это часто будет означать, что вы делаете новый коммит, который отменяет эти изменения, иногда даже для вершины HEAD).
На самом деле это довольно хороший аргумент. Наличие двух репозиториев облегчает тестирование сценариев, в которых развернутые внешние и внутренние части могут (слегка) не синхронизироваться.
источник
Этот пост немного устарел, но я хотел бы внести свой вклад. В то время как ваш бэкэнд на самом деле не знает о внешнем интерфейсе, ему нужно иметь запросы, соответствующие API бэкэнда. Если вы рассматриваете свой бэкэнд как REST API, то вы можете определить интерфейсный файл, такой как интерфейс YAML. Сейчас есть действительно 3 проекта, которые вы можете разделить на разные репозитории по своему усмотрению:
Определение API является зависимостью в двух других проектах. Допустим, вы использовали maven в качестве инструмента внедрения зависимостей. Тогда все зависит от того, насколько строго вы хотите заниматься версионированием. Вы можете увеличивать версию проекта определения API каждый раз, когда вносите изменения, чтобы гарантировать, что проекты всегда находятся в совместимом состоянии, но требуют больше накладных расходов, или вы можете использовать что-то вроде SNAPSHOTS в maven и выполнять управление версиями только после того, как вы довольны интерфейсом, который не требует чрезмерных затрат, но часто может иметь несовместимости. Но до тех пор, пока вы применяете определение API в вашем front и back-end, вы будете хорошо разделять проекты на разные репозитории.
Эти вопросы больше касаются управления зависимостями. Даже если проекты не разделены и находятся в одном и том же хранилище, веб-сайт довольно легко переводится в состояние, в котором внешний и внутренний интерфейсы не синхронизированы. На самом деле единственный способ остановить это - определить контракт между ними, но вы хотите сделать это так, чтобы не связывать реализации фронт-и бэк-энда, так же, как если бы вы кодировали вместо интерфейса реализации в программировании ОО.
Кроме того, чтобы упреждающе справиться с критикой, что это создает накладные расходы на поддержание этого файла интерфейса, Swagger, например, может даже создавать заглушки кода для различных языков программирования и сред, таких как JAX-RS. Таким образом, вы можете создать интерфейс в выбранной вами технологии и затем реализовать этот интерфейс. Это также добавляет очень хорошую документацию к вашему бэкэнду, облегчая для фронт-энда разработчиков свою работу.
источник