Здесь переводится видео в статью Андрея Смирнова и Дмитрия Красильникова "Полный цикл тестирования микросервисов в Docker контейнерах"
Ссылка на видеодоклад https://www.youtube.com/watch?v=pAMxJ2xGqMw
Текст сделан из субтитров. Буду очень благодарен в форматировании текста, его вычитки. Для этого достаточно знать русский язык. Присылайте свои pull request или присылайте текст на почту patsev.anton[собака]gmail.com
всем ещё раз привет кто про открытие меня зовут андрей это мой коллега дима зал зал диман всем привет что у нас сегодня будет а будет у нас сегодня следующие три сидр мы запустим микро сервисы с использованием докер протестируем это все с помощью грей дал его ермак а также настроим дженкинс pipeline adoquery плюс соберем отчета в репорт портале и аллюр ну и все что мы сегодня расскажем и покажем вы сможете увидеть у нас на репозиторий на гитхабе вот его ссылочка можете уже прямо сейчас открывать кому интересно + хорошие вопросы мы выдаем в конце призы что но мы тестируем это сервис который предоставляет большую часть и 5 для наших клиентов он является ядром большой обе платформы с помощью которой сторонние разработчики и компании могут с нами интегрироваться и получать доступ настройки бизнес-правил выкачивать аналитику отправлять сообщения айс mail и звонки в общем все можно делать через api и немного статистики про наш сервис ему уже более 5 лет при этом разработчики там написали порядка двухсот тридцати семи тысяч строк кода тестировщики от них не отставали написали порядка 230 тысяч строк кода при этом мы на каждый тест пишем тест кейс пишем его прямо в коде пошли нам так удобнее потом выгружаем в тоске из менеджер и написали мы тасс кейсов порядка двухсот тысяч строк кода кто-нибудь я представляю сколько это какой-то объем давайте попробуем представить война и мир это примерно полторы тысячи страниц популярная нынче игра престолов это 5 тысяч страниц а наши тесты то 6200 страниц это четыре войны и мира мы уже понаписали наш сервис является частью большой области системы для коммуникаций он построен на принципах сервис-ориентированной архитектуры и чтобы вы понимали размер наши api платформе порядка 30 компонентов а всего в нашей системе их 310 как выглядела бы окружении нормального человека это несколько виртуала фиг на которых можно развернуть все но сервис-ориентированной архитектура большое количество компонентов интеграции интеграции не позволяет нам это сделать вопрос кому нужен дата-центр для тестовых окружений поднимите пожалуйста руки у вас много наши ребята мы воспринимаем так что из себя представляет наше тестовое окружении в минимальной конфигурации это порядка 70 виртуальных машин 120 120 ядер и 160 гигабайт оперативной памяти и это минимальное окружении каждая команда может его еще и тюнить под себя тем самым увеличивая его размер и таких окружения у нас 11 по одному на каждую команду и 4 для проведения регрессии для того чтобы выпустить релиз и это только для нашей платформы что собственно в чем заключается релиз всем команд должны задерживаться в один репозиторий выглядит это примерно вот так вот в общем всем котиком очень грустную [музыка] чтобы это сделать команда разработки должна перед можем прогнать полную регрессию она в лучшем случае потратит на это один день ну или даже два или даже субботы и воскресенья и потом еще на понедельник останется в общем в итоге для проекта это где-то один месяц работы для того чтобы только замерзать все что мы сделали в основную ветку почему же так долго а ответ очень простой как я и говорил мы написали уже очень много тестов все тесты интеграционный их порядка 15000 мы их конечно же распараллеливание запускаем параллельно параллельные тесты делаем все что можем но все равно тратим полтора часа на один прогон и это еще не все затраты которые нужны для того чтоб прогнать регрессию мы еще до этого должны три часа готовить данные несмотря на то что это все происходит автоматически это все равно 3 часа на подготовку аккаунтов номеров приведение стенда в рабочее состояние после предыдущих прогонов это все занимает время если этого не сделать то прогон будет занимать 4 даже пять раз больше и вот на фоне всего вот этого наши архитекторы дело перешили что сервис нужно разбивать на микро сервиса нас был один большой сервис теперь их настанет десятки давайте представим что будет если наш сервер nude tan работу а наши сердца дико базировался а будет следующая регрессия вернее интеграция у нас станет намного больше то есть если раньше было много атак станет еще больше общая регрессия будет на порядок длине потому что придется больше компонентов тестировать фреймворк обязательно и однозначно потребуют переработки потому что раньше были одни требования для одного сервиса сейчас будут куча сервисов у каждых из них будут свои требования соответственно придется платить новый костыли и все переделывать поддержка сервиса превратиться просто в а то есть сейчас у нас 7 команд на один сервис это при этом каждой команде требуется порядка 15 джов чтоб прогнать регрессию это все как-то распространяется а теперь сервисов станет больше jogo встанет больше поддержка себя и это просто а тут в общем пищать сплошная короче хладный дим давай так читать до вычета делать дай начнем самого простого из первого с чего можно начать изменения это дистрибьюция сейчас для дистрибьюции нашего сердца мы используем template и виртуальных машин и сервис запаковываем в пакет и делаем такой бумажный мы бережем экологию мы также производим в качестве артефакта залевский файлик в котором пишутся отверстия template а виртуальной машины версии пакета как это все можно поставить как-то живем более-менее работы но при этом очень часто случаются проблемы с тем что на продакшен попадает не тот темплейт виртуальной машины которые не синхронизировали в общем случаются проблемы надо как-то от этого избавляться и тут приходит докер в чем же он хорош хорошим в следующем работает одинаково всегда и везде он нравится всем и он хранит все всю конфигурацию то есть раньше у нас было три артефакта после релиза сейчас станет один это докер-контейнер шикарно я считаю да это неплохо мы разобрались дистрибьюции теперь переходим к тому как нам надо поменять тестирование раньше у нас был один сервис у него было много интеграцией закрываю все это муками было сложно теперь у нас один маленький сервис пары 1 о новом ольга маленьких сетов но того одного маленького сервиса интеграция 7 немного и гораздо проще закрыть мог ими то есть мы можем сменить фокус интеграционного тестирования на компонентное это нам позволит уменьшить общий объем регрессе так как компонентный тест тест и можно прогнать быстрее проще общий объем интеграционных тестов уменьшить в разы а что такое компонентная теста это мы берем наш докер-контейнер поднимаемого закрываем маками и протестируем то есть мы это и роль тестируем сервис в изолированном окружают мы говорим мы говорим другим пользователям нашего сервиса что наша пи будет работать как они ожидают а также используя все это можно делать более компактно и окружение то есть мы знаем что у нас изменилась какие интеграции изменилась и мы поднимаем только такие сервисы которые нам нужны нужно наверно пример нужен пример мы нагуглили вот первое что нам попалось в гугле микро сервисной архитектура пример сервис пеги metrics это простенький сервис который предоставляет возможность управлять своим бюджетом он состоит из трех основных микро сервисов таких нам немного больше это сервис для статистики для аккаунтов и для нотификации вот на основе него мы сделали наш пример и дальше на нем все покажем ну когда мы разобрались что мы будем тестировать как мы это будем доставлять на наши сервера пришло время сделать тестовое окружения а сделать его достаточно просто в случае докером его можем сделать из подручных средств и палок в простейшем случае мы можем использовать докер кампус dead компонентных тестов для небольших сервисов небольших окружений этого вполне хватит если же у нас что-то крупнее что-то больше то для менеджмента виртуальных машин у менеджера как менеджмента инженеров контейнеров мы можем использовать меза с кубер нити сном от тира форм есть очень много открытых окон сложных решений которые это всё решают так же нам может потребоваться балансировка нагрузки тут тоже уже все придумали до нас это все работает мы можем использовать х брак sir jinx для сервис discovery консул зуб диппер мы кстати консул используем на пустыню логотип лучше чем уже кипер однозначно ну например уже небольшой пример как выглядит докер кампус файл это просто несколько строчек где мы объявляем наши сервисы указываем у них либо ссылку на docker файл либо прописываем имидж название имиджа котором будет искать в реджистер это все очень просто а там маленький ям файлик в котором мы можем описать все как его использовать так как мы любим рейду используем грей down мы подумали что нам нужен какой-то плагин чтобы это все использовать и такой плагин уже оказалась написали до нас он уже есть очень просто мы объявляем докер файл говорим что перед тестами запусти его после тестов удали его или не удалить если мы захотим погиба жить если у нас теста упали и говорим что передай пожалуйста все переменные окружения и все адреса контейнеров в тесты очень удобно это работает мы разобрались с тем как нам сервис наш дистрибьютер как тестировать теперь мы перейдём уже непосредственно к тестам когда мы сами на пи делали свою свой микро сервис начинали его тестировать мы попробовали применить the test framework который был у нас в компаниях стать кто думает вот что вот их самописный free вор который уже есть вот микро сервисом отлично подойдет поднимите руку я не могу понять наш не подошел посмотрим в общем мы его начали применять оказалось что куча костылей который хорошо работает для одного сервиса микро сервиса вообще не нужны нужно определять зависимости которые сервису не нужны без этого ничего не работает в общем ганс к и чудовище которое надо прикручивать малюсеньком у сервис вы таки кракен вот именно так это все и выглядело да вот надо с этим что-то делать с тест на когда текущей тестов фреймворк уже не получился он не справляется с микросферы сми ноющего не нового еще пока нет о чем стоит подумать заранее мы для себя выбрали основные принципы первое это надо разделять на независимые модуль нас микро сервиса и такие же независимые модели фреймворке мы подключаем к конкретному микро сервиса только то что нам необходимо также необходимо делать вклад выбрал службы биотики которые вы используете вот мы например для тестирования используем роста shuhrat у нас была там сделал несколько костылей в проекте чтобы он сам там про узел между нашими сервисами параллельную работу немножко поправили когда вышла новая версия с теми вещами которые нам были нужны мы потратили где-то неделю для того чтобы эту версию обновить при том что четыре дня только на разбор регрессия потратили то есть нам чтобы она библиотек нужно было прогнать целиком всю регрессию ворот это ужас вот и мы поняли что лучше делать вклад open source и также к тестам и каждому коду нужно предъявлять такие же требования как и продакшен коду сделать code review использовать риса статического анализа все это необходимо делать если вы не хотите потом иметь проблемы из каких модулей должен фреймворк сосны состоять вам наверняка потребуется disel как и говорил у нас например роста шуру для api вам нужно будет обрабатывать выходные данные различные отчеты лаггера дашборд у нас дальше будут пример store for порталами аллюром покажем как это все работает работа с конфигурациями и маками получать информацию об окружении аналитика когда вот у нас например больше десяти тысяч тестов вот чтобы их запускать нужно порядке очень надо как бы подумать чтобы оптимизировать вообще скорость агрессия в области таких инструментов не нашли если кто то знает скажите нам будем благодарны вот но все придется кресел писать самим ну интеграции с различными jerome менеджерами тасс кейсов например триллер с централизованными хранилищами лака чтобы можно было туда логе со всех сервисов скинуть а потом просто ссылочку в отчет прикрепить ну и когда мы уже разобрались как тестировать какой фреймворк нам может понадобиться пришло время как организовать это все тестирование нам потребуется seo service не дай бог мы захотим все-таки иметь continuous delivery нам потребуется хороший сервис это самое главное в качестве примера мы возьмем дженкинс кто-нибудь работал с дженкинсом и попробуем превратить его в конфетку первое что мы сделаем мы засунем его в докер почему только программисты суют свои микро сервисы в докер мы тоже хотим это весело это интересно мы засунем дженкинс мастеру в докер к сожалению к сожалению в текущей архитектуре дженкинс требуют чтобы у него были какие-нибудь слои вы или но мы все постоянно помним что как только у нас появляются слева они постоянно заняты постоянно очередь на build это это нехорошо конфигурацию на где-то хранить это вообще ужас поэтому мы решили fly вы тоже засунем в docker и будем подключать их по запросу то есть у нас будет гетов облака и мы будем поднимать слои вы по запросу носа вы нам не нужны мы хотим чтобы разработчики сами говорили где и как в каком окружении собирать их сервис поэтому наши слои будут только делать git checkout и больше нечего и соответственно после чекаута там поднимать нужные контейнеры который попросят разработчики соответственно у нас мастер будет поднимать slave анализировать pipeline говорить какие контейнеры поднять контейнеры в которых будет проходить происходить сборка смогут говорить какие еще контейнеры им нужны контейнер для тестирования тоже будут говорить такие контейнеры на прием и будет помимо загружения и мы надеемся что волшебные докер на и феи нам в этом помогут пойдем дальше собственно говоря как только мы решили какую конфигурацию дженкинса мы хотим использовать мы кстати и сделали она есть в репозитории мы хотим все таки пойти дальше и дать наконец-то разработчикам возможность объявлять в чем только разработчикам тестировщиком и тестировщиком куда без них объявляй как собрать все собрать и что собрать от кто-нибудь пользовался старым папой блайном плагином джефф если плагин который был ну и не только джобс это все было очень страшно это просто набор job который как-то между собой связаны в конфигах это сложно к тому же кто нибудь вот в интерфейсе дженкинса открывал конфигурации достаточно больших job at age можно открыть и пойти чаю попить куда годится соответственно дженкинс 20 принес нам pipeline мы можем хранить его вместе с исходным кодом верси они ровать вместе с исходным кодом и самое главное это это groovy это groovy мы можем использовать все практически все фишки из полноценного языка программирования и делать все что наше душе угодно ну ладно давай дальше на примере что-нибудь на примере например мы хотим поднять какой-нибудь builder в данном случае с аллюром указываем ссылочку на docker файл который лежит в папочке дженкинс аллюр builder говорим с билде нам этот контейнер и запустил внутреннего команду это все и это работает поднимается контейнер в нем выполняется команда шарится workspace все работает все очень хорошо а так же мы можем это все сделать параллельно то есть мы можем поднять двадцать тридцать сорок контейнеров подряд и это все будет работать параллельно им и в них разные команды выполним просто магия у нас билде наверно будет просто секунды выполняться до сюда верные феи они самые мы сделали примерно следующий pipeline это вот если вы заметили это новый плагин для уж он он пока бета тут есть небольшие недоработки но он хорошо работает каждая зелененькая точечка на этом плане это отдельный контейнер в рамках которого происходят определенные действия в чарок минимум отдельный как минимум один а то их там может быть и не один когда мы собираем сервисы мы прогоняем еще июнь стоит для этого мы поднимаем по отдельному контейнеру и делается это все параллельно потом и пушем если она все произошло хорошо если теста июня тесты прошли мы пушем имидже в наш локальный registry прогоняем компонентные тесты потом интеграционные тесты и если у нас вообще все хорошо то мы можем зарелизить это все в наш публичный реджистер кстати в рамках компонентных тестов мы поднимаем еще контейнеры как раз таки с нашим сервисом и магами которые нам нужно хотя почему у нас сборочка то красненькая пестик один упал ой не понятно что то вот кто вот у себя в тестах в отчетах вот такие вот ошибки встречает вот эти вот вот вот они самые да они сами нам нужен нормальный инструмент для отчетов и сразу скажу что если вы в такое все мастер так пишите вам отчет уже никакие не помог а инструменты для отчетов мы тестируем micro series и нам нужны разные уровни детализации много микро сервисов один микро сервис сьют конкретный тасс кейс нам нужно обе для интеграции с этими отчетами мы хотим все данные потом куда-то забирать анализировать смотреть что у нас то получалось но и хорошо получать результат в реальном времени чтобы сразу реагировать на то есть что-то пошло не так ну чтобы не ждать полтора часа пока у тебя упадут тестом можно было сразу прекратить все починить и перес рынке что из инструментов сейчас есть на рынке open source а есть старый добрый репортажи который тестом же идет в придачу мы его не рекомендую вот это вот скрин вот запомните его не надо использовать юрий порт отличная разработка от компании яндекс ребята привет детка [музыка] соответственно что он имеет его очень классная фича что можно со всех наших контейнеров джобса брать тестовые отчеты закинуть в эту папку и сгенерировать report и это будет работать даже на больших объемов объемов данных например сейчас наши регрессия это порядка 600 мегабайт тестовых тестовый отчет у нас есть команда себя у которых десятки гигабайт и вот например репортажи даже с нашим отчетам не справляются нормального агрегировать в этом почти там все гоняем мурок вот салютом репортов все круто плюс можно делать дополнительные плагин чеки расширять его функция предоставлять отображать данные так как нам удобно но к сожалению мы можем генерить отчет только в конце то есть нет говорил тайма есть инструменты человек snare по extend report я могу сказать сразу его не очень рекомендуем у него очень много возможностей по кастомизации можно вообще весь интерфейс переделать но плюс можно в реальном времени отобразить но вот весь отчет это одна единственности малька и вот когда она там 600 мегабайт и вы в нее правильно пишете будут наверняка какие-то проблемы с этим поэтому нет и разработка компании epam report портал такое большое решение для ваших отчетов все туда выгружается в реальном времени а он кстати поставляется еще и в докер-контейнер а кстати это огромный плюс все это выгружается в реальном времени есть и пиа и для того чтобы эти данный потом забирать как там крутить анализировать куда-то забрасывать в общем удобная штука аллюре порт и report портал мы сейчас юри портал уже интегрируем report портал рассматриваем как решения для такого объемного хранилища logo кстати ребята из аллюра по секрету мне сказали в следующем году они хотят выпустить аллюр сервер для того чтобы али русские репорты можно было также хранить историю там и и статистику по ним делать вот пример вот мы сделали аллюре порт для нашего теста который у нас есть там помните упал вот было ошибочка что код 200 ожидали 200 пришла 301 прикрутили немножко логирование получили response очень крутая штука мы идем буквально за неделю прикрутили к нашему проект из 15 тысяч тестов используя вот буквально вот такую простенькую конструкцию мы все методы лоббирования наше обозначили аннотаций степ про кинули в роста сюжет возможность получать виде attachment of luck request и response а и очень быстро получили хорошие красивые отчеты прошу заметить 7 не ушло на то чтобы четыре дня прогнать агрессию трения написать плагин и ареста шуры до чтобы он наконец-то писала request a response и и пять минут на то чтобы интегрировать аллюр шикарного и report портал у него есть всякие даже бороды можно все это красиво отобразить есть история по прогонам там внизу показан слайдик как я уже говорил а есть теперь что можно все это выгружать но есть сложности с интеграция если валер вы все скинули его ту папочку сгенерили отчет то здесь вам нужно настраивать каждый прогон чтобы он там писал в 1 тестовый прогон то есть сначала там и войди и получить потом бы тот же эти там во все тесты пропушить в общем посложнее integra сопрет спадут с аллюром все легко и просто ну и что же мы в итоге получили получили мы следующее у нас получился артефакт который можно развернуть всегда и везде в том числе и на машине разработчика и тестировщика также вся конфигурацию нас хранится вместе с кодом сервиса то есть как собирать что собирать где собирать что в итоге мы должны получить абсолютно все нет не разрешить едем сейчас за мельник то это не вид также мы получили удобные инструменты для отчетов и самое главное самое главное да наши сервисы теперь умеет и сами себя собирать тепло и и тестировать все что для этого необходимо хранится в репозитории вместе с сервисом докер файлы genki с файлы все в одном месте все настраивается разработчиками и тестировщиками предлагаю наверно сейчас посмотреть как от все в реальности выглядит как выглядит наш дженкинс то что там действительно мы никого не обманули там нет слоев то что эти слои вы когда поднимаются понимают build контейнеры давай покажем кто только только о ком так там показывается а там показывается не показывается вот обратите внимание нет ни одного узи кьютер а сама главную очередь тестов пустая и вот нажимаем собрать нажали мы тоже tele2 сборки и это все все равно сработает то есть основная пища pipeline а это то что он помимо того что может работать параллельно он для каждой сборки делает отдельный workspace поэтому вас никогда ничего не пересечется и самое главное если кто-то из вас хоть раз на одном билдере параллельно запускал сборку грей был наивен npm хоть что он это все постоянно падает потому что она не может лоцировать свою темпов у директорию для нескольких сборок и постоянно разбираться с этим городить костыли это все очень неудобно так ну и вернемся сейчас посмотрим сколько у нас сливов поднялась где мы как мы видим у нас уже поднялся докер slave он поднял наверное уже несколько контейнеров для себя и это все работает что было за день может быть что 20 наверное на этом на слайде кивер не ну давайте пока вернемся на слайде ки мышкой секундочку в общем как мы говорили все что мы проделали все эти примеры лежат нашим репозитории вы там найдете переделана немножко пике matrix мы его смолина тестом g&g юнита перенесли наградил это стужи на так было удобнее да так же вы найдете там нашу презентацию найдете конфиг как поставить такой же дженкинс и найдете немного исправленные плагин для дженкинса дакар вал workflow чтобы можно было использовать синтаксис докера в pipeline их и чтобы он умел наконец-то работать с dockers формам потому что такая прям удаленном только такая схема как сделаем сейчас она в релизных версиях плагинов не работает с нам пришлось сидеть разбираться тебя жить бачить вот так же рекомендуем прочтение инженерный блог компании riot games который собственно у нас вдохновили бти немножко дальше однозначно и замечательный игру battle блок все это который нам предоставила котиков пишите нам письма мы с удовольствием на все отвечу сейчас готов ответить на ваши вопросы а себореи дмитрий я что благодать микрофон добрый день спасибо , сергей санкт перербург а компания rp скан если позволите у меня два вопросе к первым не хотелось бы немножко подробнее о дистрибуции то есть о том как вы распространяете вас права вашу систему как я понимаю у вас ваши ваши заказчики ваш клиент и скачивают и из вашего публичного жеский позвольте я немного вас перебью мы продуктовая компания наш продукт он наш мы сами его для себя поставляем сервера то есть мы хостится полностью на наших серверах и клиентам только клиентское приложение это мобильные десктопные и ничего более спасибо а и вот второй вопрос и в в ваша система интегрируются с каким быть внешними сторонними системами на не знаю там например самое со старым там с точки контактов там все 1 1 2 не и прочее и если да то каким образом вы проводите интеграцию с ними какие-то какие какие-то создаете mockery что-то еще для них вот это хотел бы подробнее спасибо вот как вообще в принципе наша система интегрируются другими компаниями правильно понимаем то есть ваша ваша система с другими сторонними сторонними сервисами каким-то образом земля конечно вот вы для этого собственно и разрабатываем для интеграции да и тестируйте ли вы взаимодействия то есть в двусторонней системы может постучаться к вашей системе ok ваша система к сторонним систем каким-то образом может обращаться дают ли их муки да даже вот для нашей для нашего одного из сервисов над которым мы работаем у него более по моему 60 сторонних интеграций и на тестовых сценах мы разумеется это все мокрым дальше у нас идет просто edge style и прочее стенды и там уже проверяется интеграция с реальными системами а также для здоровья сервис у нас есть например сэндбокс где они могут приоритеты грацию с нами нас там несколько последовательных инвалидов где мы проверяем интеграцию другими сервисом тогда это все мы тестируем конечно же без этого никуда привет раз ванна из беркута санкт-петербург а можно микрофон поближе да надо чтобы слышно было лучше да да да она не будут повторять а значит у меня вопрос и такое небольшое небольшой опыт если вы хотите от истица на соляре дать вам не друг на чем еще раз солярии для чего нам это мы теста засовываем даже в docker и у нас нет проблем теста в докере сервиса в докере все в докере а где стоит докер нам по большому счету без разницы это разница solaris не дружит докером используем solaris да нам повезло поэтому это это немножко не так а вопрос у меня к вам как пользователь реп реп от портала одно дело услышать это от товарищей сапом и какой он классный а вот вопрос сколько времени у вас ушло и пользуетесь ли вообще этой фичей авто анализатор мы сейчас в принципе интегрируем то есть так как те на мы еще не использовали мы сейчас его интегрируем себе и возможность что в репорт портале можно задать в принципе общая кастомную castano статуса все прописать и потом их у себя мы сначала анализируете ручками что ваши тесты значит а потом он уже сам да нет смотри ты первый раз когда настраиваешь принципе она подключаешь там есть у статусная модель но ты ее можешь расширить это это расширение можешь в адаптере для который для тестов ты там тоже ты можешь прописать что у тебя сами тесты во-первых автоматическим опились это ещё куда авто анализа вот когда уже как бы потом ты когда падаешь нафтан allison ошибкам собственно на эти тесты но на эти старцы tes мопед мы ее как в продакшене это функции ч не тестировали добрый день меня зовут александр компания водой и у меня вопрос по бокам вы сказали когда перешли на микро сервисе стало проще мог ими их со всех сторон покрывать а кто собственно следит за актуальностью api по которому общаются вашими к сервисы с маками то есть есть ли какие-то автоматизированные штуки которые генерят этапе автоматизированных штук мы не используем которые генерят от айпи мы используем ремонта петля в ярмо к и просто поднимаем vr мог и указываем что он будет вместо этого сервиса а дальше уже в тестах говорим что он должен ответить и на какой запрос а вот откуда вы берете знания о том что он должен ответить на какой запрос а это уже из требование к системе то есть мы анализируем перед тем как что-то делать какие требования какое должно быть api каком этапе и уже используем по факту все сценарий которые варим опрокидываться несет а также с тестами хранятся то все на уровне тестов хранится там где-то это твое рама который поднялся на нем но ничего не ну просто как сервис а если api поменяется тогда теста упадут и тесты поменяются соответственно я понял спасибо добрый день меня зовут алексей компания dji у нас спасибо за доклад и у меня два вопроса первый ну получается и если у вас микро сервисной архитектура и вас тесты запускаются они быстро работает и велела при быстро получает фидбэк о том как все работает и так ли на самом деле вы каким-нибудь образом после тестов коллег тити логий у то есть если произошел фэйл именно самого приложения и в данный момент мы недавно внедрили у себя elastic для того чтобы микро сервиса писали логе в него а также мы сейчас разрабатываем адаптер для тестов которые после прогона тестов случае файла будет доставать лог именно и из централизованного хранилища есть более простой способ как работает для более простых случаев можно так как у нас контейнеры поднимаются самим сливом в докере они поднимают вместе с тестами можно просто подцепиться к по сокету gudok.ru контейнеру и получить весь его лапу в тестах и потом до также вставить почет и второй вопрос у нас что-то очень очень похоже я прям как про нас слышал голос работает clio 2 спасибо второй вопрос у меня опять же узнать больше насколько это на наше похоже то есть у вас получается микро сервис они между собой общаются по какому-то контракту каким у вас образом происходит если вы занимаетесь модульным тестированием каждого компонента каким образом вы гарантируете валидацию контракта между разными микро сервисами вот под модулем мы поднимаем отдельный отдельно взятый микро серых я понял и отлично соответственно мы просто заранее описываем api в документе мы ведем документацию по сервису там описывается api и после этого мы проверяем что это api не меняется прям в тестах в частности мы очень активно используем для валидации джейсон схему и по ней проверяем что у нас все корректно каждого из вопросов вы как-то именно из документации генерить и контракт ну типа у вас есть какая-то именно контракт но сейчас пока мы значит swagger начали использовать ребята вот с миссис лагерь внедряем и в принципе что можно было потом из него весь контракт выпорхнул окей спасибо нам добрый день меня зовут александр спасибо за доклад меня несколько вопросов но во-первых мы используем многие части похоже на есть много различий какой плагин вот вы используя для динамического создания своего доктор клауд плагин окей мы другой но принцип принцип понятен а как бы прокидывайте соки докера внутрь контейнер мы не прокидываем соки в доке надо используется мы используем ремоут api и поэтому это все работы и именно поэтому у нас были проблемы с тем что плагины с этим не работали а какими хорошо следующее это вот смотрите вас много сервисов и сколько у вас их вот сейчас в штуках ну так порядок хотя бы понимание микро сервиса дата до но смотри мы вот сейчас вот начали декомпозировать наш сервис общей нами к сервиса то есть столько же по моему чуть больше десятка уж больше десятка до microserver застыть мой старый сервис поддерживаем и весной цена мы поставляем уже виде микро сервису а когда вам нужно добавить вот вас описании есть досыта the pipeline там на эти цели просто такой вот как вы решаете проблему того что вам нужно добавить какой-то общий эта обо все эти 10 сервис а очень просто у нас в груве мы можем использовать импорт мы можем сделать расширенную библиотеку где-нибудь на гитхабе на git лобби где хотим в любом репозиторий и потом просто подключить этот groovy файл к нашему проекту и то есть каждому проекту нужно сходить и ручками подключить в коде ну как конь это не только библиотека каждый каждый сервис у вас фактически отдельно самим интернете и в том случае если нужно добавить что-то общее то вы идете и собственными разработчик идет и меняет это всегда есть общая репозиторию с общими шагами есть командной репозиторий где работаю только командой и соответственно так это все и решается минут мы у себя используем job детстве чтобы сгенерировать кучу плагинов для нас для всех сервисов и он автоматических регенерирует то есть вы pipeline охране тени вместе с кодом да а тогда возникает самая главная проблема от которой мы хотели отказаться это версия нирования как это можно версия не ровать я создал ветку там что-то поменял теперь все не собирается донеслись если такой проблемы нету то ваш подход отлично работает но у нас такая проблема очень остро стояла поэтому многие я в не превысит орех зиму ну хорошо возраст подход спасибо привет тоже джуно но с мобильной страны как вы минджи те два больших вопроса как уменьшить и разрастание docker и джесс 3 то есть вы стоя пушкиным джедаи не он как бы разрастается вы как-то удалять у нас у нас есть devops инженерно все отвечают за инфраструктуру поэтому мы не волнует то есть у нас ну на месте построен у клауд все это всем удобно первый шанс мы вы такие у нас докеры давайте использовать блоки это докер так и потом так по мы не пушатся смотри когда вот в принципе для вот этой схемы вообще потребуется да реально для дженкинса ресурс менеджмент то есть вот по серьёзке до нужен риса установишь вы тоже на оркестрация нужен мониторинг то есть без этого как бы нормально не сделать вот такой клауд окей и очень круто что вы храните всего как бы с проектом это правильно в прессе анимирование но нравится ли вам то что вы сильно завязывались на сам дженкинс то есть именно на то что вот например локальная захочу как разработчик до тест я не смогу дженкинс нет локального как разработчик сможете это все прогнать потому что дженкинс что делает он просто вызывает грей долбил д-да локально вы не сможете это все сделать параллельно на разных контейнерах но запустить это все вы сможете вы сможете прогнать любые тесты просто не запускаются с помощью кредла и они так же поднимут контейнера и все будет работать ну подними себе мастер подними себе как надо все они лучше ли написать бил скрипты ну словно там на компасе да ну начале марта крайдолл и то есть бил screen ну я там тоже крови вот чтобы из дженкинс джо бы вызвался просто ваш скриптик all pages cryptic уже будет все параллель и тогда можно будет как бы локально запускать просто этот скриптик у нас такой проблемы пока не было но когда возникнет мы подумаем над ее решением нет не слышно мы можем повторить вопрос это что для всех используем ли мы генерации тестов по джейсон схема используем нет по моему нет ни справа ни генерируем написали вот этими руками пять лет писали ну ладно мы не 5 описали меньше и меньше год от года нового проекта то есть именно shape платформа проекта уже пять лет и реально вот ребята посвящена того что у нас тестировщиков там два раза мин таким разработчиков они написали почти такое же количество кода и еще к нему описание столько же стоят все еще поддерживать на ололо а я хочу поддержать человека из буду этого такие модные молодежные все разбили на микро сервисы но до этого я мог мог и написать и они бы проверялись на уровне компиляции что они правда совпадают с реальным а другим сервисам его api а теперь api независимые они через степи общаются при этом то сервис может поменяться вы об этом не узнаете или вы можете поменяться может не узнать теперь всё надо это тестировать вместе выходит в конце и поднимайте это все вот мой и блоком рознь смотри то есть даже в проекте например там есть тесты которые назовем их unit тесты которые там прибил где прогоняются они поднимают нам через makita они это все делают мой это отдельные макета вот они там вот билде поднялись и все протестировали мы поднимаем уже мог отдельный как сервис hdpi они там наш сервис с этим мог бы почти и общаются мы просто говорили что до этого вы вам приходилось все тестировать вместе а потом вы такие взяли и разбили это все на контейнеры написала чему нам приходилось это все тестировать вместе потому что у нас был один большой сервис у которого очень много интеграций при этом большинство этих интеграции идут был достаточно сложными и написать столько мог of для одного сервиса это очень сложно к тому же потом все равно придется это все проверяют как фактически систему переписать еще раз а в случае микро сервисов у нас есть один маленький сервис у которого небольшой функционал у которого есть немного интеграция тоже немного функционала которая можно очень легко замок отмена подавить да такие вы развелись и знаете на micro series удара из них мало интеграции но в сумме у системы интеграции никогда понял вас на самом деле да хороший вопрос в сумме тестов у вас меньше не станет просто вы меняете фокус у вас будет больше компонентных тестов и в итоге вам на будет меньше писать тестов я проверяются реальные интеграции именно за счет этого у вас регрессия будет меньше просто нет смысла гоняет полностью на реальном окружении каждый раз большой набор тестов триале последний плевок который microserver сделала нашу команду нас там 100 компонентных тестов и 4 интеграционных то же самое вы могли монолите написать монолите намного сложнее выделить отдельно взятый компонент который не затронет что-то такое манали тебе надо поднять на окружение все к нему подключить настроить но и блюз колб определить очень сложно в случае монолита кто-то может твой модуль и переиспользовать переписать и непонятно какие когда вы прогонять когда в монолит быть мер статья надо всю игры и прогоняет ты мог где-то что-то сломать мне кажется не понимать вам про слова но мы можем судить потом кулуарах следующий вопрос как вы цитируете обратную совместимость вылезете все сразу вместе и ли у вас один сервис может работать обратно совместим с другом мэрилин все по одному компоненту и соответственно обратная совместимость мы каждый раз проверяем мы проверяем всегда брату совместимость вот вы два раза гоняете тесты на двух разных окружениях 1 на 2 1 1 там с одной версии с другой версии да мы гоняем это всегда хорошо просто нам ином случае чего всегда надо откатиться и надо чтобы все это работало и последний вопрос как вам с ручными шагами в pipeline флаги не этот ручной шаг он говорит действительно ли вы хотите зарелизить и это очень полезная вещь то есть это ручную прав без которого ну очень сложно но это был с арканом просто там нет ручных на самом деле нормальных шагов они очень плохо поддерживаются да там в основном нас за ходить куда-то в билд логе нажимать на ссылочку это пока не удобно но это скоро исправят я надеюсь владимир компании джун и я просто понял subtils индукционный даст остались а мы здесь мы сейчас в процессе декомпозиция у нас еще большой сервис остался большая регрессе пока осталось но мы потихонечку а ты снова факторы и еще появилось но ответ на вопрос как бы контракт прежнему стоит он так ну не интересует как приготавливается площадка для операционных тестов то ты это понимаешь делается автоматически дамы во время написали собственную систему для менеджмента окружения у нее есть определенные архетипе api она написана на базе питон питон vagrant по моему или побед и диплом систем хоть один ствол сервис базы данных и есть у нас много сервисов с базами данных а некоторые даже с 1 - в этом случае составит от традиционного смотри мы как раз когда начинали что у нас на подготовку тестовых данных нужно потратить три часа то есть у нас запускается там несколько сервисов которые там с бажин начинают колдовать генерят аккаунт и телефоны номера все там соединяют правда гораздо проще у нас есть отдельный сервис который готовит тестовые данные да у нас есть отдельный сервис который готовит тестовый дано и вот ударная команда тестирует сдаст компания компания малия завтра хинкала учитель с на доклад вопрос такой вы предоставляете это компании команде команде девелопера вот эти дроби то есть они в каком-то смысле да можете вместе работать все правильно а джайлс как полностью одна команда все кто-то следит за тем как пишется и не теста при том что вы так все сделали два часто говорю да потому как здорово все сделали не хочется писать в нем теста хочется вот взять и кнопочку в жанре сажать и коммитить комитете копить как вы знаете мк тот кто за этим следит и как меняются юнит-тесты удивил команду вот после таких вот замечательных подвижек у нас есть практика code review в рамках которой мы должны были бы заставлять их писать июня тесты но это не всегда работает к сожалению на слишком хороший тест точки поэтому разработчики ленится даровали мне решено обычным проблема с ливнем тестами никак не решена до оно есть не можем заставить если кто-то подскажет как это сделать волкам ну то есть ребята там как бы разработчики пишет и не тест ну хорошо не пишут ну но бы вообще делать все делать мы мы все сделаем понятно спасибо