Структура 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 - Итоговый пайплайн
Скрытый контент
Комментарии (12)
Руслан

Спасибо!

Ответить
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.

Ответить
Алексей

Поддерживаю автора выше. Тема микросервисов и организации в ней доступа к персистентному слоя очень интересна. Хотелось бы высказать пожелание осветить ее как можно подробнее, с практическими примерами.

Ответить
Руслан

Дмитрий, хотел узнать Ваше мнение насчет Werf (Go), не рассматривали его для создания пайплайнов сборки образов? Спасибо.

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

Не рассматривал, так что не подскажу.

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

Или войти через:

Google
GitHub
Yandex
MailRu