Структура CI/CD Pipeline

Система тестирования и деплоя со сборочным сервером. Продумывание шагов проверки кода и сборки образов для запуска в CI/CD Pipeline.

Скрытый контент
Комментарии (9)
Руслан
2020-05-18 09:44

Спасибо!

Ответить
Bondarenko Alexandr
2020-05-18 16:20

Спасибо за материал! Скажите, а как можно поступить с фикстурами, если e2e тесты лежат в отдельном проекте? Например, в проекте мобильного приложения. Есть какие-нибудь варианты, кроме вызова команды заполнения тестов вручную?

Ответить
Дмитрий Елисеев
2020-05-19 16:16

Вручную. Либо в папке выше проектов добавить общий sh-скрипт или Makefile, который в каждом проекте команды загрузки фикстур вызовет и потом тесты запустит.

Ответить
Bondarenko Alexandr
2020-05-19 16:29

Спасибо!

Ответить
Arunas
2020-05-19 16:02

Спасибо :)

Ответить
Максим
2020-05-19 16:48

Класс!) Все по полочкам! Просто о сложном) У вас все таки талант преподавания. Мне кажется аналогов вашим урокам на русском языке нет) Спасибо вам!) Интересно, а если мы будем делать микросервисы не в монолите, то нам придётся для каждого микросервиса такой Pipeline выстаивать?)

С нетерпением жду такого же разбора доменной модели, ограниченных контекстов, микросервисов) Жду не дождусь!)))

Ответить
Дмитрий Елисеев
2020-05-22 05:49

Да, для каждого отдельный репозиторий со своими тестами и деплоем. И помимо этого можно сделать отдельный pipeline с тестами для проверки совместной работы всех сервисов.

Ответить
Максим
2020-05-23 03:08

Возможно ли продолжение этого большого образовательного урока «распил» монолита на микросервисы? Или может запланирован разбор этого вопроса в отдельном видео? Хотелось бы услышать ваше мнение!

Вопросов в этой части накапливается много.

В ваших уроках вы часто следовали денормализации данных. Ограниченный контекст дублировал все необходимые данные для своей работы. Что если такие данные используются во нескольких микросервисах: города, страны, регионы, категории мероприятий, локации (места, площадки), организации?

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

В микросервисах я встречал хранение в сервисе только ID, а уже он сам делает запросы, проверки, в другие сервисы по прямому взаимодействию RPC или через события. Как быть с отказоустойчивостью и независимостью?)

В ваших уроках всегда рассматривался вариант создания: комментатора, покупателя, участника на основании авторизованного пользователя. В этом случае мы брали ID пользователя и присваивали его комментатору. А что если мы сначала добавили какого-то человека, который необходим для работы системы и он не имеет аккаунта в системе, например: сотрудник, участник, ребенок (3 года), а потом мы захотим его связать с аккаунтом. Как лучше поступать? Изменять ID в таких системах мы не можем. Приходит в голову только одна мысль: ссылка на аккаунт или персону по ID: Organization -> Person или Organization -> Account. Это правильный подход?

Извиняюсь за длинный текст. Спасибо за ответ!)

Ответить
Дмитрий Елисеев
2020-06-07 05:06

Возможно ли продолжение этого большого образовательного урока «распил» монолита на микросервисы?

Возможно, что здесь или в другом проекте это сделаем.

Что если такие данные используются во нескольких микросервисах: города, страны, регионы, категории мероприятий, локации (места, площадки), организации?

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

В микросервисах я встречал хранение в сервисе только ID, а уже он сам делает запросы, проверки, в другие сервисы по прямому взаимодействию RPC или через события. Как быть с отказоустойчивостью и независимостью?)

Отказоустойчивость процессов достигается именно за счёт очереди: отвалившийся сервис вернётся и свою очередь обработает. А на фронтенде при отвалившемся сервисе просто его виджет не загрузится.

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

А что если мы сначала добавили какого-то человека, который необходим для работы системы и он не имеет аккаунта в системе, например: сотрудник, участник, ребенок (3 года), а потом мы захотим его связать с аккаунтом.

Тогда ему добавить второе поле вроде user_id.

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий