Разделение решения .NET / Git-репо для нескольких приложений - PullRequest
Новая
       24

Разделение решения .NET / Git-репо для нескольких приложений

6 голосов
/ 14 сентября 2010

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

Несколько других полезных деталей, прежде чем говорить об ответах:

  1. Приложения развертываются на общем сетевом диске, а не на отдельных компьютерах, поэтому у меня есть полный контроль над тем, когда они развернуты и что развертывается с ними
  2. Библиотеки DLL не используются приложениями после их создания. Каждое приложение имеет в своей папке полную копию всех DLL, PDB и конфигурационных файлов.
  3. В настоящее время я только один делаю релизы, но еще один или два могут закончить делать релизы, поэтому я хотел бы помнить об этом.

Я крутил пару идей в моей голове, но ни одна из них не кажется удовлетворительной. Я рассмотрел просто держать все в одном решении / одном репозитории Git. Я также думал о разделении решения на несколько репозиториев Git с использованием подмодулей, но подмодули громоздки. Я также думал о том, чтобы сделать каждое приложение своим собственным решением, а все библиотеки - еще одним. Тогда возникает вопрос: могу ли я открыть несколько решений в Visual Studio? Библиотеки часто должны меняться вместе с приложениями, поэтому слишком большое их разделение на отдельные решения или репозитории Git затруднит синхронизацию библиотек и приложений. Еще одна проблема, которую я имею, - это ветвление. Если я разделю решение на несколько репозиториев Git, у меня могут быть ветки для каждого приложения, но если я оставлю один репозиторий Git, у меня может быть только один набор веток для всего.

Я, возможно, даже не задаю себе правильные вопросы, и также возможно, что у меня просто умственный блок, мешающий мне решить простое решение. В любом случае, я обращаюсь к SO-сообществу, чтобы дать мне несколько идей. Я надеюсь, что все ясно, но если нет, я буду рад разъяснить.

Ответы [ 2 ]

2 голосов
/ 14 сентября 2010

Хотя они могут быть громоздкими, я думаю, что субмодули - это то, что нужно.Я просто собираюсь предположить, что ваша структура каталогов выглядит примерно так: 

mainapp
 \mainappdir
   \somefiles
    ...
|
|
 \library1
|
 \library2

В этом случае вы хотите, чтобы library1 и library2 были подмодулями (это, вероятно, очевидно).Они на самом деле не так уж и плохи, просто к чему-то, к чему нужно привыкнуть в Git IMHO.

Еще один путь, который стоит рассмотреть, - это символическое связывание library1 и library2 в вашей файловой системе для использования обоими приложениями.В этом случае каждая библиотека может быть собственным репозиторием, но не управляться с помощью субмодулей (хотя я думаю, что вам придется добавить их в файл .gitignore).Используя символические ссылки в каждом приложении, управление репо / исходным кодом будет осуществляться только в двух библиотечных каталогах.Вытягивание / разветвление в одном месте может повлиять на оба приложения, не требуя администрирования библиотечных файлов каждого приложения.

0 голосов
/ 14 сентября 2010

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

Что касается действий в Git, то имеет смысл иметь отдельные репозитории для каждой логической единицы работы (приложения или библиотеки) или, по крайней мере, отдельные ветви в одном репозитории.

Удачи и не унывай. Это будет полезно для вас в долгосрочной перспективе.

...