Процесс Azure CICD для многоуровневого приложения - PullRequest
Новая
       47

Процесс Azure CICD для многоуровневого приложения

0 голосов
/ 29 марта 2019

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

Архитектура

Клиентское приложение через веб-интерфейс API достигает агрегатора, который выполняет вызовы SDK, а затем обновляет и улучшает данные.SDK имеет оболочки для других DAL или веб-API.Сервисы общаются напрямую с агрегатором.

Мы используем Visual Studio для разработки, и изначально решение содержало все слои в одном месте:

  • web apis
  • модели web apis
  • агрегатор
  • модели аггреагаторов
  • sdk
  • модели sdk
  • услуги
  • веб-задания
  • etc

Мы используем Microsoft Stack и Azure Devops для развертывания веб-API и других приложений, таких как веб-задания и службы.Для этого мы используем процесс CICD (мы определили определения сборки и выпуска + триггеры).

Сборка начинается, когда новый код отправляется в git.Релиз происходит при создании новой сборки.

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

Решение 1:

  • web apis
  • модели web apis

Решение 2:

  • агрегатор
  • модели агреагатора

Решение 3:

  • sdk
  • sdk модели

Решение 4:

  • услуги

Решение 5:

  • веб-задания

Решение N ...

  • и т. Д.

Чтобы соединить слой, мы решили использовать пакеты Nuget, чтобыsdk в одном nuget, sdk.models в другом и т. д.

Теперь проблема в том, скажем, если я хочу внести изменения в sdk.models, вот ручные шаги (без CICD) для обновлениявсе вещи:

  1. добавить изменения в пакет sdk.models
  2. push-пакет sdk.models в nuget
  3. обновить nugets в проекте sdk
  4. push sdkпакет в nuget
  5. обновить нюгет в агрегатеили проект
  6. отправьте пакет агрегатора в nuget
  7. обновите все клиентские приложения, чтобы иметь последний пакет агрегатора nuget

Pure madness ...

...Но это позволяет людям работать независимо на каждом слое.Что может рассматриваться как преимущество.

Теперь мы вернулись к CICD.Триггер связан с событием git push, и если фиксируется новый код, создается сборка, а затем определение выпуска публикует материал.Например, в случае sdk решение содержит два проекта: sdk и sdk.models, поэтому, если я добавлю новый код в sdk.models и нажму на git, то триггер активирует сборку для sdk и sdk.models, и когда сборка будет готовазатем release переводит оба пакета nuget в канал nuget.Но это не правильно, потому что sdk должен обновить ссылку на более новую версию пакета sdk.models и затем быть опубликованным.Единственный способ, которым я вижу, как это решить, это перенести sdk.models в другое решение / репо.Это нормально, за исключением того, что у нас будет больше решений и репозиториев для управления, и будет сложнее отлаживать и развивать ...

Вопрос: Как вы думаете, все, что я сказал, имеет смысл?Как улучшить / изменить это?Чтобы иметь более эффективную среду.Любые советы, критика или предложения, пожалуйста.

Спасибо за чтение.

...