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

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

Комментарии (8)
Руслан
2020-05-18 09:44

Спасибо!

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

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

Ответить
Deworker Pro
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 выстаивать?)

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

Ответить
Deworker Pro
2020-05-22 05:49

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

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

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

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

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

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

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

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

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

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