Перенос классического решения ASP.NET в Azure Repo

Наша команда разработчиков развертывает около 6 приложений ASP.NET (веб-формы, служба SOAP, служба RESTful и исполняемые файлы). Все эти приложения ссылаются на одни и те же несколько библиотек .DLL, которые содержат большую часть нашего бизнес-кода, и эти библиотеки ссылаются на несколько низкоуровневых фреймворков и библиотек безопасности (все это на C#). Сейчас все это размещено в TFVC в Azure.

Мы создаем новую организацию Azure и переносим все в Azure Git, и, что более важно, мы настраиваем CI/CD с помощью Pipelines. До этого момента у нас было только одно гигантское решение, которое мы используем для развертывания, которое содержит все. Проекты приложений просто используют ссылки проекта на проекты библиотек, и когда я создаю для развертывания, он создает все это. Затем мы просто независимо публикуем каждое приложение с помощью веб-развертывания на наших виртуальных машинах Azure.

Нам понадобится конвейер для каждого из этих приложений, и мы пытаемся найти лучший способ (1) структурировать наши проекты в нашем репозитории Repos и (2) как лучше всего ссылаться на библиотеки.

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


person LarryG    schedule 29.05.2019    source источник
comment
у вас уже есть правильное представление. библиотеки должны быть встроены в пакеты, а затем на них можно ссылаться из фида артефактов. Каждая библиотека и приложение должны быть собственным репозиторием, а не обязательно разными проектами, но я не знаю ваших приложений, поэтому вам придется выбирать самостоятельно. на первый взгляд это может показаться немного утомительным, но, по моему опыту, лучше всего иметь один большой проект.   -  person D.J.    schedule 29.05.2019


Ответы (1)


Должны ли библиотеки быть встроены в пакеты, а затем мы должны ссылаться на них из потока артефактов, который мы загружаем в конвейеры?

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

Проверьте эту ветку для получения дополнительных преимуществ nuget и эту ветку для выбрав ссылку на проект или NuGet.

должно ли каждое приложение и библиотека быть отдельным проектом в репозитории или лучше работать как один большой проект?

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

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

Так что, как сказал DJ, вы должны выбирать сами.

Вы можете проверить следующие темы для получения дополнительной информации по этой теме:

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

Выбор между одним или несколькими проектами в репозитории git ?

Надеюсь это поможет.

person Leo Liu-MSFT    schedule 30.05.2019