Как настроить управление исходным кодом для нескольких продуктов, зависящих от одной библиотеки классов

Question

Я технический директор и единственный разработчик в моей компании. Я готовлюсь нанять нашего первого разработчика и, возможно, второго в течение следующих 6-12 месяцев. Мне стыдно сказать, что я никогда не использовал контроль исходного кода как часть моего рабочего процесса. Я думаю, что команда разработчиков из одного члена позволила мне быть немного ленивым. Дело не в том, что я этого не хотел, у меня просто небольшой ментальный блок о том, как начать с ним работать.

У нас есть 5 веб-приложений, которые я создаю и поддерживаю. Мы используем ASP.NET, и каждое веб-приложение ссылается на одну .NET Class Library (DLL), которая была скопирована в «bin». папка для каждого приложения. Я занимаюсь разработкой с помощью одного Visual Studio «решения». это включает в себя библиотеку классов и все веб-приложения. Я немного раздут, я уверен, но этот метод позволил мне минимизировать ошибки, позволяя мне выполнять глобальные операции поиска и замены для всех моих приложений (и библиотеки классов) одновременно.

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

Вот вопросы, с которыми мне нужна помощь:

<Ол>

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

Если я делю приложения на отдельные проекты, я не уверен, как поступить с библиотекой классов, копия которой нужна каждому проекту. Например, предположим, что изменения в одном из приложений (назовите его «проект 1») требуют изменения библиотеки классов ... если библиотека классов находится в отдельном проекте (назовите его «проект 2») кажется "грязным" для меня этот проект 1 будет зависеть от последних изменений в проекте 2 для правильной работы. Или вы просто вносите свои изменения в проект 2 (библиотеку классов), регистрируете их, а затем копируете недавно скомпилированную dll в проект 1 (но не должна ли новая копия dll, копируемая в проект 1, записываться в ГТК как-то). Я запутался, даже когда я пишу это ...

Заранее благодарим за помощь.

Answer 1

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

<Ол>

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

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

Answer 2

В одном решении Visual Studio может быть несколько проектов. В прошлом я делал так, чтобы проект ASP.NET и проект библиотеки классов имели одно и то же решение. Вы можете сделать так, чтобы ваш проект ASP.NET ссылался на проект библиотеки классов (добавьте ссылку, а затем перейдите на вкладку «Проекты», чтобы показать другие проекты в том же решении). Таким образом, всякий раз, когда вы изменяете библиотеку классов, приложение ASP.NET будет собираться с использованием самой последней версии библиотеки классов. Вы можете настроить несколько решений - по одному для каждого приложения ASP.NET с каждым решением, включая проект класса libary.

Вы также можете установить одно большое решение со всеми вашими проектами ASP.NET, а также с вашей библиотекой классов, но с этим может быть довольно сложно работать, особенно с несколькими разработчиками, работающими над различными страницами ASP.NET.