Разработка в .NET. Изначально был один ASP проект который был организован как отдельный солюшн, который прекрасно хранился в своем SVN хранилище (хранилище 1). Потом был организован второй солюшн с отдельным проектом который жил в своем хранилище (хранилище 2). Потом вдруг (сюрприз!) у этих проектов обнаружилось много общего и появился отдельный проект в который была вынесена часть общего кода. Потом появился третий проект который использовал что-то от первого и т.д.
Вопрос вот в чем: как правильно организовать структуру хранилища (я сейчас прихожу к мысли что я бы все проекты клал в одно хранилище в виде плоской структуры), и как правильно организовывать солюшены? Стоит ли все проекты включать в единый солюшн? Если нет, то без билд-сервера (а его у нас нет) большой риск переделать что-то в общей библиотеке и неузнать об этом никогда. Или отрефакторить только ту часть кода, что находится в твоем солюшене. С другой стороны билдить все проекты в солюшене — это долго. Ну не смертельно долго, но надоедает и сильно раздражает.
Зависимость между проектами выглядит приблизительно так:
Здравствуйте, Mazenrab, Вы писали:
M>Добрый день.
M>Разработка в .NET. Изначально был один ASP проект который был организован как отдельный солюшн, который прекрасно хранился в своем SVN хранилище (хранилище 1). Потом был организован второй солюшн с отдельным проектом который жил в своем хранилище (хранилище 2). Потом вдруг (сюрприз!) у этих проектов обнаружилось много общего и появился отдельный проект в который была вынесена часть общего кода. Потом появился третий проект который использовал что-то от первого и т.д.
А почему не хранить каждый проект в отдельном репозитории. Общая кодовая база соот-но тоже в отдельном репозитории и можно в nuget пакет завернуть, а у проектов в зависимость поставить этот пакет.
Ну, и конечно же, надо организовывать continuous integration систему. Это не сложно и избавит от многих проблем. В том же teamcity есть нугет-галерея из коробки.
Re[2]: Как правильно организовать проекты и солюшены
Здравствуйте, xednay89, Вы писали:
X>Здравствуйте, Mazenrab, Вы писали:
M>>Добрый день.
M>>Разработка в .NET. Изначально был один ASP проект который был организован как отдельный солюшн, который прекрасно хранился в своем SVN хранилище (хранилище 1). Потом был организован второй солюшн с отдельным проектом который жил в своем хранилище (хранилище 2). Потом вдруг (сюрприз!) у этих проектов обнаружилось много общего и появился отдельный проект в который была вынесена часть общего кода. Потом появился третий проект который использовал что-то от первого и т.д.
X>А почему не хранить каждый проект в отдельном репозитории. Общая кодовая база соот-но тоже в отдельном репозитории и можно в nuget пакет завернуть, а у проектов в зависимость поставить этот пакет.
X>Ну, и конечно же, надо организовывать continuous integration систему. Это не сложно и избавит от многих проблем. В том же teamcity есть нугет-галерея из коробки.
Ну сложность только одна. Мне не хватает ясности кто следит за тем чтобы компоненты не порушили проекты в которых они участвуют Это задача CI- сервера?
Re[3]: Как правильно организовать проекты и солюшены
Здравствуйте, Mazenrab, Вы писали:
M>Ну сложность только одна. Мне не хватает ясности кто следит за тем чтобы компоненты не порушили проекты в которых они участвуют Это задача CI- сервера?
Смотря, что значит "порушили". Да, то, что все собирается должен проверять CI-сервер. А логику должны проверять тесты, запускаемые тем же сервером.
Re[4]: Как правильно организовать проекты и солюшены
Здравствуйте, xednay89, Вы писали:
X>Смотря, что значит "порушили". Да, то, что все собирается должен проверять CI-сервер. А логику должны проверять тесты, запускаемые тем же сервером.
Здравствуйте, Mazenrab, Вы писали:
M>Разработка в .NET. Изначально был один ASP проект который был организован как отдельный солюшн, который прекрасно хранился в своем SVN хранилище (хранилище 1). Потом был организован второй солюшн с отдельным проектом который жил в своем хранилище (хранилище 2). Потом вдруг (сюрприз!) у этих проектов обнаружилось много общего и появился отдельный проект в который была вынесена часть общего кода. Потом появился третий проект который использовал что-то от первого и т.д.
В нашей компании используется проектный подход. На каждый проект создаётся своя ветка в репозитории (или отдельный репозиторий).
Как решается задача, которую Вы описали:
1. Чтобы выделить код, общий для обоих проектов, создаётся проектная команда, т.к. это отдельный проект. Эта команда может состоять из одного человека и, более того, она может работать в рамках одного из других проектов: в Вашем случае — в рамках первого или второго проектов.
2. После того, как вынесение общего кода закончено, происходит его интеграция с первым проектом. Это опять-таки отдельный проект.
3. Затем происходит интеграция со вторым проектом. Это опять-таки отдельный проект.
В Вашем случае можно объединить шаги 1 и 2. Тогда библиотека развивается параллельно с развитие проекта 1, а проект 2 — интегрируется с устоявшимися и стабильными версиями библиотеки.
При таком подходе проект 2 можно продолжать хранить в отдельном svn хранилище, как Вы это и делали.
Здравствуйте, Mazenrab, Вы писали:
M>Вопрос вот в чем: как правильно организовать структуру хранилища (я сейчас прихожу к мысли что я бы все проекты клал в одно хранилище в виде плоской структуры), и как правильно организовывать солюшены?
Универсального рецепта нет, самый простой:
Один репозиторий, несколько солюшнов — по одному на каждый продукт. Каждый солюшн включает в себя общие проекты (только те, что ему нужны) и проекты, нужные только для определённого продукта.
Любители экстрима могут нагородить несколько билд-конфигураций в одном солюшне, но я бы так не делал, на практике получается сплошное минное поле.
Билдсервер нужен в обязательном порядке, как вы ещё тесты да и просто ошибки в коммитах отслеживать собираетесь?
Для разнесения проектов по разным репо нужен опять-таки билд-сервер + nuget для подтаскивания общей части в отдельные проекты. Если над проектами работают разные команды — это может что-то и даст. Но скорее всего у всех будет открыты две студии вместо одной, вот и вся разница.
P.S. От ломающих исправлений в общих сборках простые юнит-тесты спасают далеко не всегда, проверено. Комбинация из ассертов + автоматизированного тестирования работает куда лучше.
