Структура 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 Итоговый пайплайн
Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Спасибо!
Спасибо за материал! Скажите, а как можно поступить с фикстурами, если e2e тесты лежат в отдельном проекте? Например, в проекте мобильного приложения. Есть какие-нибудь варианты, кроме вызова команды заполнения тестов вручную?
Вручную. Либо в папке выше проектов добавить общий sh-скрипт или Makefile, который в каждом проекте команды загрузки фикстур вызовет и потом тесты запустит.
Спасибо!
Спасибо :)
Класс!) Все по полочкам! Просто о сложном) У вас все таки талант преподавания. Мне кажется аналогов вашим урокам на русском языке нет) Спасибо вам!) Интересно, а если мы будем делать микросервисы не в монолите, то нам придётся для каждого микросервиса такой Pipeline выстаивать?)
С нетерпением жду такого же разбора доменной модели, ограниченных контекстов, микросервисов) Жду не дождусь!)))
Да, для каждого отдельный репозиторий со своими тестами и деплоем. И помимо этого можно сделать отдельный pipeline с тестами для проверки совместной работы всех сервисов.
Возможно ли продолжение этого большого образовательного урока «распил» монолита на микросервисы? Или может запланирован разбор этого вопроса в отдельном видео? Хотелось бы услышать ваше мнение!
Вопросов в этой части накапливается много.
В ваших уроках вы часто следовали денормализации данных. Ограниченный контекст дублировал все необходимые данные для своей работы. Что если такие данные используются во нескольких микросервисах: города, страны, регионы, категории мероприятий, локации (места, площадки), организации?
Организации, или на ваших примерах: покупатель, комментатор, логично вписываются в это правило. Так как пользователь действительно в разных контекстах может иметь разные имена и статусы и т.п. А данные о местах, городах нет. Но для работы сервиса все эти данные нужны. Как в этих ситуациях поступать?
В микросервисах я встречал хранение в сервисе только ID, а уже он сам делает запросы, проверки, в другие сервисы по прямому взаимодействию RPC или через события. Как быть с отказоустойчивостью и независимостью?)
В ваших уроках всегда рассматривался вариант создания: комментатора, покупателя, участника на основании авторизованного пользователя. В этом случае мы брали ID пользователя и присваивали его комментатору. А что если мы сначала добавили какого-то человека, который необходим для работы системы и он не имеет аккаунта в системе, например: сотрудник, участник, ребенок (3 года), а потом мы захотим его связать с аккаунтом. Как лучше поступать? Изменять ID в таких системах мы не можем. Приходит в голову только одна мысль: ссылка на аккаунт или персону по ID: Organization -> Person или Organization -> Account. Это правильный подход?
Извиняюсь за длинный текст. Спасибо за ответ!)
Возможно, что здесь или в другом проекте это сделаем.
Эти вещи лучше выносить отдельно и ссылаться на них по ID. И понятие используются достаточно растяжимое. Они могут действительно использоваться для внутренней логики. Тогда эти данные или их копии должны храниться внутри. А могут не использоваться для логики, а только подтягиваться для отображения на фронтенде. Тогда сервису внутри хватит только ID.
Отказоустойчивость процессов достигается именно за счёт очереди: отвалившийся сервис вернётся и свою очередь обработает. А на фронтенде при отвалившемся сервисе просто его виджет не загрузится.
А независимость достигается именно разделением границ по бизнес-логике, чтобы действия осуществлял по возможности именно тот сервис, которые эти данные хранит.
Тогда ему добавить второе поле вроде user_id.
Поддерживаю автора выше. Тема микросервисов и организации в ней доступа к персистентному слоя очень интересна. Хотелось бы высказать пожелание осветить ее как можно подробнее, с практическими примерами.
Дмитрий, хотел узнать Ваше мнение насчет Werf (Go), не рассматривали его для создания пайплайнов сборки образов? Спасибо.
Не рассматривал, так что не подскажу.
Или войти через: