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

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

  • 00:01:07 - Прямой деплой через GitHub
  • 00:03:21 - Проблемы непосредственного деплоя
  • 00:04:21 - Выкладывание Docker-образов
  • 00:06:43 - Использование сборочного сервера
  • 00:08:29 - Формирование Pipeline
  • 00:10:01 - Шаг Checkout
  • 00:10:39 - Подъём девелоперского окружения
  • 00:11:15 - Запуск линтеров и тестов
  • 00:12:37 - Когда запускать E2E тесты
  • 00:14:23 - Сборка Docker-образов
  • 00:14:54 - Обзор первой версии
  • 00:16:28 - Скрытые проблемы сборки
  • 00:17:29 - Проверка production-образов
  • 00:19:02 - Неудобство автотестов на Staging
  • 00:19:39 - Тестирование после сборки
  • 00:20:11 - Создание тестового окружения
  • 00:21:27 - Дымовые Smoke-тесты
  • 00:22:30 - Обзор второй версии
  • 00:22:54 - Сборка тестовых эмуляторов
  • 00:23:39 - Обзор результата
  • 00:24:32 - Тестовая конфигурация
  • 00:25:28 - Дополнительные анализаторы
  • 00:27:52 - Итоговый пайплайн
Скрытый контент
Комментарии (9)
Руслан

Спасибо!

Ответить
Bondarenko Alexandr

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

Ответить
Дмитрий Елисеев

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

Ответить
Bondarenko Alexandr

Спасибо!

Ответить
Arunas

Спасибо :)

Ответить
Максим

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

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

Ответить
Дмитрий Елисеев

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

Ответить
Максим

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

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

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

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

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

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

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

Ответить
Дмитрий Елисеев

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

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

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

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

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

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

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

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

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

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