Ваш вопрос неопределенный и открытый, поэтому нет простого и краткого ответа. Честно говоря, это может быть серия постов из нескольких постов или даже небольшая книга. Я постараюсь дать некоторые общие предложения, но я не буду вдаваться в подробности, чтобы избежать слишком длинного ответа.
Моно-репо против нескольких репо
Точно так же, как увлечение микросервисами несколько лет назад, вы должны сначала спросить себя, нужно ли вам это. Наличие всего вашего исходного кода в одном репозитории и решении может сделать его «устаревшим», и, конечно, лучше иметь 3-минутную сборку компонента, а не 30-минутную сборку всей системы при проверке в 1 строку Исправлена ошибка. Но стоят ли проблемы, перечисленные в вашем вопросе, в пользу более короткой сборки CI?
С другой стороны, Google может запускать практически все из одного репозитория, но у них есть группы людей, которые делают только управление своим моно-репо и системой сборки, потому что большое количество разработчиков, работающих над одним репо, имеют другой набор проблем. Это инженеры, не работающие над клиентскими приложениями. Если их работа делает другие команды более продуктивными, то это может быть полезным.
Вам нужно выяснить, что лучше для вас, но, учитывая проблему, которую вы описали в вопросе, возможно, у вас слишком много репозиториев / решений, и ваши процессы могут быть быстрее с меньшим количеством ошибок, если вы немного консолидируете.
Автоматизация
Следующая лучшая вещь - это просто использовать хорошие инженерные практики. Максимально автоматизируйте, чтобы снизить риск человеческих ошибок, в том числе автоматизировать процессы, которые подтверждают, что ручные процессы выполняются правильно.
- У вас есть push-пакеты конвейера CI или CD, так что вы не можете забыть отправить зависимости, как в вашем примере.
- Существуют инструменты, которые будут автоматически генерировать номер версии из истории мерзавцев на основе количества коммитов с момента регистрации файла конфигурации версий. Это не позволит вам забыть увеличить версию пакета при регистрации изменения в пакет.
- Пройдите тесты, чтобы убедиться, что пакет работает, прежде чем нажать на него. Вы можете сделать это так же просто, как убедиться, что зависимости существуют, но вы также можете пойти дальше и запустить тестовые программы, использующие этот пакет, чтобы убедиться, что обратная совместимость не нарушена и что новые функции действительно работают как положено. Запустите эти тесты перед отправкой пакета, поэтому, если тесты не пройдены, вы не отправите плохой пакет.
- У вас может быть конвейер, который будет автоматически создавать запросы на извлечение решений, использующих пакет, когда публикуется новая версия одного из ваших пакетов. Вы даже можете автоматически объединить его, но вам нужно убедиться, что у вас действительно хорошие тесты, чтобы избежать сбоя в пакетах с ошибками, особенно если вы выполняете автоматическое развертывание в успешных сборках.
- Будьте изобретательны и подумайте о других способах автоматизации своих процессов, чтобы упростить жизнь себе и своей команде.
Но будьте прагматичны в том, что вы автоматизируете. Нет смысла тратить неделю на полный рабочий день, чтобы автоматизировать то, что занимает у вас всего 5 минут раз в месяц, чтобы сделать это вручную Но если ручной процесс иногда идет не так, как надо, и это требует много часов или дней усилий, то это делает автоматизацию процесса более целесообразной.
Используйте современные функции
. Экосистема .NET сильно изменилась за последние 2-3 года с момента анонса .NET Core.Теперь упаковка с помощью MSBuild (dotnet pack или msbuild -t:pack) проще создавать пакеты, чем создавать файлы .nuspec и убедиться, что вы делаете правильные вещи, чтобы упаковывать зависимости проекта как зависимости nuget, получая все файлы в нужных местах,и т. д. Если ваша библиотека классов использует проекты в стиле SDK, то делать больше нечего.Если ваш проект является традиционным, вам нужно будет использовать PackageReference для ваших зависимостей NuGet (или указать <ProjectStyle>PackageReference</ProjectStyle> в качестве свойства MSBuild в файле проекта), а затем сослаться на пакет NuGet.Build.Tasks.Pack.
Версия приложения, а не каждого пакета
Как и точка моно-репо против нескольких репо, учитывая возможность создания версий всех пакетов в приложении с одним номером версии, а не управление версиями каждого пакета по отдельности.Да, это означает, что вы будете иногда (или, возможно, часто) публиковать новую версию пакета, в которой нет изменений кода по сравнению с предыдущей версией, но это значительно упрощает выпуск.В сочетании с упаковкой с MSBuild в вышеприведенном разделе вы можете создать файл Directory.Build.props в корне хранилища и установить для свойства приложения <Version> версию вашего приложения, и все проекты в репо будут иметь одинаковую версию.Итак, когда вы будете готовы к выпуску, поместите версию в один файл, и каждый проект и все пакеты NuGet будут иметь одинаковую версию.
Сводка
В идеальном мире каждый компонент будетбыть многократно используемым в разных приложениях, в отдельном хранилище исходного кода, каждый пакет индивидуально версионируется с использованием семантического версионированияНо в реальном мире это значительно усложняет время разработки.Ваши клиенты могут быть счастливы быстрее получать исправления ошибок и новые функции, даже если количество версий пакетов менее значимо.Итак, принимайте решения на основе данных.Если у вас часто возникают проблемы с версиями зависимостей, уменьшите свои зависимости, чтобы было меньше ошибок.
Не поймите меня неправильно, есть много веских причин иметь несколько проектов, несколько решений, несколькохранилища.Просто убедитесь, что причина, по которой вы делаете это, заключается в том, что это помогает вашей команде / компании быть более продуктивной, а не по идеалистическим причинам, которые замедляют вас или вызывают ошибки.