Реализация стратегии ветвления в DevOps для мультитенантного приложения - PullRequest
0 голосов
/ 18 декабря 2018

Я новичок в DevOps, и у меня есть решение с Umbraco в качестве CMS, мобильным приложением в качестве внешнего интерфейса для контента, добавленного в CMS, и веб-API .Net MVC для соединения CMS с мобильным приложением.У меня также есть WebJobs и Microsoft flow для некоторых задач планирования.

Теперь мне нужно реализовать DevOps для моего мультитенантного приложения, вот мой сценарий:

Решение будет иметь одно главное приложение, котороебудет служить главным списком функций для администратора, чтобы включить функции при создании нового сообщества.Несколько сообществ, имеющих отдельные базы данных, каждое сообщество имеет несколько функций (Feature1, Feature2).У разработчиков должен быть способ прямой интеграции и обратной интеграции функций.

После добавления функции в любое сообщество она может иметь собственные настройки в конкретной функции.В некоторых сценариях разработчикам также необходимо добавить эти изменения в сообщества master или sibling.Я также добавил изображение для лучшего понимания.

enter image description here

Теперь мне нужна помощь в создании стратегии ветвления для моего решения, которое отвечает всем вышеуказанным требованиям исвести к минимуму вероятность конфликтов при объединении филиалов.У меня в голове есть варианты ниже.

i) Должен ли я рассматривать каждую функцию как отдельную ветку?Если да, то как насчет управления изменениями, сделанными в сообществе в каком-либо отдельном сообществе?

ii) Должен ли я рассматривать каждое сообщество как отдельную ветвь?Если да, как я могу выделить код функции, который будет объединен с веткой сообщества?

iii) Должен ли я рассматривать общий код для всех сообществ?Если да, то как насчет изменений в сообществе?

После развертывания все будет на лету (в базе кода с использованием Visual Studio 2017).На какую стратегию я должен пойти?Или есть лучший подход, чем эти?Как мне разрешить конфликты слияния, если они сгенерированы после развертывания?Кроме того, в DevOps я должен пойти на Git или TFS?

Любое руководство будет оценено.

1 Ответ

0 голосов
/ 21 декабря 2018

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

Допустим, у вас есть произвольное приложение с 3 возможными функциями:

  1. Настраиваемые аватары,
  2. Пользовательуведомления,
  3. общедоступный API restful (или graphql, если это ваш джем).

Все эти функции будут находиться в одной кодовой базе, все они должны будут работать вместе, но онитакже не все функции могут быть интересны каждому арендатору.

Примечание: в этом случае «арендатором» может быть что угодно, например, разные страны для SaaS-подобной платформы или разные компании, если вы продаетедля предприятий.

Поскольку все функции должны работать в любом случае, вам нужно сохранить приложение как единое целое.Это означает, что у вас есть единая база продуктов / кодов (возможно, разделенная на микросервисы, если вы этого хотите), но вы можете развернуть ее с другими конфигурациями.

Вы можете развернуть продукт в банке под названием TheBank со всеми3 функции включены, вы также можете развернуть в небольшой компании под названием TheFlowerShop, которая требует только уведомлений пользователей (плюс основное предложение).В этом случае вы развернете ту же кодовую базу, но с некоторым способом решить, должна ли функция использоваться.Есть много способов сделать это, но обычно они все называются «Флажки функций» или «Переключатели функций».

Флаг функций, по сути, является своего рода конфигурацией, которую вы можете проверить во время выполнения, чтобыПосмотрите, как приложение должно действовать.Давайте рассмотрим простой случай, у вас может быть файл конфигурации JSON для вашей службы, который выглядит примерно так:

{
    "features": {
         { "name": "custom_avatars", "enabled": true }
         ....
    }
}

Это можно настроить при развертывании приложения и определить, какие функции включены или выключены., во время выполнения вы можете прочитать в этом файле и проверить, включена ли функция.Если функция с именем public_api отключена, вы не позволите пользователям генерировать токены для этого, и вы не будете разрешать HTTP-вызовы от чего-либо, кроме себя.Если пользовательские уведомления отключены, то, когда происходит системное событие, вы не отправляете уведомление на электронную почту пользователей, а просто игнорируете его.

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

В тот момент, когда вы начинаете делать разные ветви приложениядля разных развертываний вы попадете в огромный беспорядок.Вам придется дублировать исправления, и вы будете в основном управлять несколькими расходящимися версиями одной и той же базы кода, которые в конечном итоге будут расти друг от друга.В какой-то момент вы можете обнаружить, что исправления, примененные к одной ветви, не будут работать в другой ветви.

Придерживайтесь одного приложения, но сделайте его настраиваемым.

...