Какова разумная структура для многоязычного проекта в системе контроля версий? - PullRequest
Новая
       28

Какова разумная структура для многоязычного проекта в системе контроля версий?

3 голосов
/ 30 апреля 2009

На работе мы разрабатываем крупномасштабное приложение с довольно большим количеством интерфейсных, серверных и вспомогательных компонентов. Обычно внешний интерфейс разрабатывается на C #, а внутренний - на Java, хотя его части также разрабатываются на C # и, возможно, позже на C ++.

Выбор языка и платформы не является произвольным; мы пытаемся взвесить относительные достоинства каждого из них по времени разработки, стоимости цепочки инструментов, знакомству с языком конкретной командой разработчиков и т. д. Однако все эти компоненты объединяет то, что все они необходимы для полной работы продукт, и что они разрабатываются одновременно независимыми (но очень общительными) командами.

Ранее мы использовали Team Foundation Server для нашего кода .NET и Subversion для нашего кода Java; Поскольку было четкое разделение обязанностей команд, это вызвало небольшую проблему, кроме неудобства размещения двоичных файлов (в данном случае WAR-файлов), сгенерированных из одного дерева исходных текстов, в другое, а также высоких накладных расходов на поддержание синхронизации ветвей и версий. С этим проектом степень разделения между командами намеренно намного меньше, и ожидается, что объем ветвления / слияния будет значительно выше; в результате мы переходим к унифицированной VCS, а точнее к Subversion.

Это подводит меня к сути вопроса: как эффективно смешивать код Java и C #? На практике код .NET будет зависеть от кодовой базы Java; двоичные файлы Java требуются для запуска чего-либо, кроме кода модульного тестирования (для интеграционных тестов уже требуются двоичные файлы, и QA, приемочное тестирование и т. д., безусловно, также делают это). То, что мы сейчас имеем в виду, выглядит примерно так: 

/trunk
    /java
        /component1
        /component2
        /library1
        /library2
    /net
        /assembly1
        /assembly2
        /...
        project.sln

Идея состоит в том, что все дерево исходных текстов находится под одной веткой; код .NET зависит от кода Java, поэтому мы добавим в решение шаг после сборки, который (скорее всего) вызовет сценарий ant для компонентов Java. Это позволяет выполнять разветвление всей кодовой базы (для разработчиков .NET) или только компонентов Java (для разработчиков Java).

Проблемы с этим решением:

  1. Что происходит, когда одна из двух кодовых баз становится настолько большой, что ее копирование для каждой ветви становится непрактичным? (наши мысли: разделить на отдельные репозитории для кода .NET и Java и использовать svn: externals, любые входные данные для этого будут значительно приветствуются).
  2. Мы используем Eclipse для разработки Java. Как мы управляем «общим» рабочим пространством (т. Е. Какие проекты требуются для каких компонентов, граф зависимостей и т. Д.)? До сих пор у нас было относительно немного Java-компонентов, поэтому каждый разработчик мог одновременно хранить их все в рабочей области. С увеличением количества компонентов Java и разработчиков Java я не понимаю, как мы можем продолжать это делать; какие-либо предложения о том, как сохранить версию рабочей области (в виде файлов решений) при сохранении синхронизации между двумя базами кода?

Мне бы очень хотелось услышать ваше мнение!

1 Ответ

1 голос
/ 30 апреля 2009

1: Я считаю, что лучше всего группировать вещи по компонентам, а не по языкам. Если для одного компонента требуется несколько языков интерфейса, вам все равно нужно разработать, протестировать и выпустить их как один. Таким образом, разделение компонента на несколько репозиториев не хорошая идея.

Если одна часть кода тесно связана с другой, храните ее вместе. Лучше разделить компоненты по репо. (Это относится даже к внутренней структуре, где, особенно по мере роста вещей, трудно, если вы упаковываете вещи по типу, а не по функциям, то есть в MVC, нет трех огромных пакетов для каждой категории, вместо этого сохраните FooView, FooModel и FooController жесткий.)

svn: внешние могут работать, и с более поздними версиями, я думаю, вы можете использовать «внутренние», то есть ссылки на другие каталоги в том же репо. Это намного проще, чем управлять отдельными репозиториями, особенно с тегами и ветвлениями. (Дрожь)

2: разработчики всегда могут настроить разные рабочие пространства или использовать рабочие наборы. Коммерческие выпуски Eclipse имеют лучшую поддержку для совместного использования настроек рабочего пространства, чем вариант ОС. (Не пробовал, только работал и был разочарован одной ОС)

Я сделал C ++ (MSVS) и Java (Eclipse) в одном репо, и он работает довольно хорошо. Также C ++ / Python аналогично. Убедитесь, что ваша система сборки поддерживает сборку и тестирование всего (даже если ваши IDE собирают только одну часть).

...