Как управлять ссылочными версиями в парадигме многопрофильных решений - PullRequest
Новая
       69

Как управлять ссылочными версиями в парадигме многопрофильных решений

0 голосов
/ 08 января 2020

Я сталкиваюсь со следующей ситуацией: 

<ul> 
  <li>MySolution1</li> 
  <ul> 
<li>Project1a 
<li>Project1b
   </ul> 
    <br/>
  <li>MySolution2</li> 
  <ul> 
<li>Project2a 
<li>Project2b
   </ul> 
    <br/>
     <li>MyUtilitySolution</li>
    
     <ul> 
<li>ProjectUtilityA
<li>ProjectUtiliyB
</ul> 
</ul>

Теперь MySolution1 и MySolution2 полностью не связаны, но имеют один и тот же код, который определен в MyUtilitySolution. Например, некоторый служебный код в ProjectUtilityA, скомпилированный как dll.

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

Кроме того, все эти решения имеют версии в своем собственном репо Git.

Затем у меня может быть разработчик, работающий над MySolution1, другой - над MySolution2, а третий - над MyUtlitySolution.

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

Как вы справляетесь с этой ситуацией и каков наилучший метод?

Я не вижу еще какой-то другой вариант, использующий репозиторий артефактов (Azure Aartifact, Nexus ..) и создающий версионные пакеты nuget из моего кода Utility. Тогда каждое решение должно теперь указывать, с какой версией моей библиотеки утилит работать, но мне интересно, есть ли другие простые решения.

Многое

...