Visual Studio Развертывание стратегий для большого количества выпусков одного и того же приложения - PullRequest
Новая
       40

Visual Studio Развертывание стратегий для большого количества выпусков одного и того же приложения

0 голосов
/ 11 февраля 2020

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

У меня возникли некоторые проблемы с обслуживанием и, в частности, с развертыванием одного распределенного приложения, у которого разные конфигурации в Web.Config.

Это приложение WebAPI (. NET Framework 4.6) С Entity Framework и двумя типами аутентификации. Windows или Forms (они НИКОГДА не используются вместе. Или windows или формы)

На данный момент существует одиннадцать различных конфигураций сборки, поскольку существует одиннадцать разные организации, и все они имеют разные конфигурации для этих разделов:

  1. <appSettings>
  2. <authentication>
  3. <connectionStrings>
  4. <membership>
  5. <sessionState>
  6. <smtp>

Я уже проанализировал решение для этого, и оно работает, но я чувствую, что это не лучший в плане управляемости и масштабируемости

Текущий шаблон

  1. I Удалены все конфигурации сборки, кроме Debug и Release
  2. I Добавлены только две другие конфигурации : Release For Windows Authenticated и Release For Forms Authenticated
  3. Я удалил эти части из файла web.config и сохранил как независимые .config файлы.

На данный момент у меня 66 (11 клиентов * 6 разделов) .config файлы. Я решил сгруппировать файлы Windows Authentications и Forms Authentications, которые равны togheter. Это следующие файлы:

  1. MembershipSettings: будет использоваться имя connectionString, поэтому никаких проблем в двух конфигурациях нет
  2. SessionState: то же, что и выше

Итак, я построил эту структуру файлов:

  • Root
    • Конфиги
      • Универсальный
        • Windows Аутентификация
          • MembershipSettings.config
          • SessionStateSettings.config
        • Аутентификация с помощью форм:
          • MembershipSettings.config
          • SessionStateSettings.config
      • Специальный
        • Клиент 1:
          • AppSettings.config
          • AuthenticationSettings.config
          • ConnectionStringSettings.config
          • SmtpSettings.config
        • Клиент n:
          • AppSettings.config
          • AuthenticationSettings.config
          • ConnectionStringSettings.config
          • SmtpSettings.config
* 1 124 * К этому моменту я удалил все свои файлы sh профилей publi * (.pubxml) и создал профиль sh publi для каждой организации (так что eleven .pubxml). Те, кто использует аутентификацию Windows, я буду использовать конфигурацию сборки Release Windows Authentication, те, кто использует аутентификацию с помощью форм, я буду использовать конфигурацию сборки Release Forms Authentication.

На публикуемой странице sh я буду игнорировать содержимое Root\Configs и вместо этого создайте ЕДИНСТВЕННУЮ ПАПКУ внутри, называемую Release, в которой я MERGE буду содержать содержимое Generic\[Windows Authentication|Forms Authentication] (в зависимости от того, какую аутентификацию мы собираемся использовать в производстве ) и Specific\Customer n\.

Когда я нажимаю publi sh, получается:

  • Root
    • Конфиги
      • Release
        • MembershipSettings.config (ОТ Generic\[Windows Authentication|Forms Authentication])
        • SessionStateSettings.config (ОТ Generic\[Windows Authentication|Forms Authentication])
        • AppSettings.config (ОТ Specific\Costumer n)
        • AuthenticationSettings.config (ИЗ Specific\Costumer n)
        • ConnectionStringSettings.config (ИЗ Specific\Costumer n)
        • SmtpSettings.config (ИЗ Specific\Costumer n)

В конце я реализовал атрибуты configSource и file внутри Web.WindowsAuthentication.Config и Web.FormsAuhentication.Config, указывающие на Configs\Release\[settingsFile].config для каждого раздела, используя Web.Config Transformations.

Альтернатива

Я могу просто поместите содержимое двух MembershipSettings.config и SessionStateSettings.config внутрь двух Web.WindowsAuthentication.Config и Web.FormsAuhentication.Config и используйте Transformations для выполнения той же работы. На данный момент мне больше не нужны эти два файла.

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

Развертывание в режиме непрерывного развертывания

На этом этапе я хотел использовать некоторые стратегии CD для развертывания каждого приложения, когда я sh на правильной ветке. Мой репозиторий хранится в GitLab, поэтому я решил использовать его бегун для выполнения этой работы.

Я написал некоторый скрипт с msbuild и sqlpackage, чтобы опубликовать sh приложение и обновить схему базы данных.

И это работает. Но опять же, я не уверен, что я делаю правильные вещи здесь

Вопросы

  • Это хороший шаблон? Я думаю, что нет
  • Это масштабируемое? Не совсем.
  • Безопасно ли? Нет, потому что я не использую Transformations и что-то добавленное в разработку web.config может очень легко потеряться на производстве
  • Есть что-то лучше? Я уверен, что да, но я не знаю, что
  • Почему вы не использовали панель поиска !? Я использовал его и использовал Google, Yahoo, Bing уже 3 дня, и ничего не было найдено.

Спасибо

...