[PHP, Go, Тестирование веб-сервисов, Kubernetes] Как мы делали инструмент для QA, а сделали для всего техотдела
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
От печали до радости или от идеи до реализацииКак-то очень давно наш отдел автоматизации внутренних процессов посетил админ (ops) с идеей помочь нашим тестировщикам. Он предложил упростить деплой, т.к. было очень неудобно писать ручные curl запросы к gitlab'у с кучей меняющихся параметров. Так заставили нас наша команда решила помочь дружественному отделу и сделать их работу более приятной.В статье я постараюсь поделиться тем, как мы в Каруне разрабатывали GUI для curl'a, а сделали очень крутой сервис автоматизации. Ещё расскажу, с какими проблемами столкнулись и как их решили (или нет).А почему не взяли готовые решения? (с)Опережая ваши вопросы, дорогие читатели, могу ответить примерно так: хотелось получить более гибкую вещь под наши нужды. По ходу прочтения статьи можно понять, что требования часто менялись, проект развивался. А готовое решение было бы не таким эффективным. Тем не менее, если вы знаете нечто похожее, милости прошу в комментарии.РеализацияВ то время основной проект был монолитом с одним отпиленным сервисом "сбоку". Но, к счастью, был развернут kubernetes, который значительно упростил работу с сервисами. Реализация предполагала простейшую идею: дёргаем настроенный админами триггер гитлаба, передавая названия нужных веток к двум репозиториям.Но тут понеслась...Естественно процесс на этом не остановился, больше людей проявляло интерес к нашему сервису: QA, админы, программисты всех видов и подвидов. С каждым днём мы получали все больше хотелок. Мы улучшали интерфейс сервиса.Начало образовываться все больше внешних интеграций. Например, QA нужны были логи, чтобы понимать, кто удалил или создал очередной стэк (стэком мы называем развёрнутый набор сервисов), кого ругать и кого за него спрашивать. Для этого мы подключили API Kubernetes. Естественно нам нужны были простейшие операции со стеками, такие как удаление, для чего необходимо было использовать helm.Для связи с развёрнутыми контейнерами к каждому сервису мы подключили консоль, которая тянулась через kubernetes websocket.Также необходимо было подключить ssl. Сертификаты стали генерироваться через vault, а далее отправлялись на балансеры и cloudflare.Матрица зависимостейНаверное, это представляется очень пафосно, как-то так:
Но на деле с основе лежала простая идея. Параллельно нашему сервису основной проект также стремительно развивался. Монолит постепенно переходил на SOA, образовывались новые микросервисы. Каждый деплой запускал неконтролируемо огромное количество ненужных сервисов, которые были лишними в разворачиваемом стэке. Необходимо было более умное использование ресурсов. Для этого мы создали так называемую "матрицу зависимостей", позволяющую настроить, какие сервисы от каких "зависят". Пользователь смог сам задавать "наборы сервисов". Выбрав при деплое, что ему нужно, он получал действительно только то, что ему нужно.Например, деплой сервиса статистики разворачивал только необходимый сервис статистики и авторизацию, а не весь монолит с сервисами.Интерфейс нашей шайтан-машины с заполненными фейк-данными представлен ниже. 
Упомяну также об ограничении на количество задеплоенного. Все-таки мощности ограничены, и необходимо было ввести лимит на количество стейджей. Т.к. в стейдже может быть разное количество сервисов (и соответственно контейнеров), то ограничение вводилось как раз на количество контейнеров.Веб-сокетыДа, мы их тоже сделали. Вначале это была штука просто для удобства "чтобы не перезагружать страничку".Как я уже описал выше, в одном из проектов Каруны осуществлялся переход от монолита к микросервисной архитектуре. Это заставляло использовать все больше и больше репозиториев gitlab'a. Последовательная обработка запросов к гитлабу сильно тормозила разворачивание сервисов. Пользователь очень долго ждал своего стейджа. Т.к. основное взаимодействие с гитлабом осуществлялось через веб-сокет сервер, мы решили внедрить golang. Это позволило распараллелить эти запросы и значительно увеличить скорость создания нового стейджа.Как. Это. Тестировать.Через полгода активной разработки мы получили сервис с большим количеством внешних зависимостей — было невозможно сложно тестировать. С сервисом уже плотно работало несколько десятков человек, и его недоступность критично сказывалась на процессах. Тестирование через mock'и не справлялось, да и не казалось оптимальным решением. И мы решили...
Сделать возможность разворачивать стейдж этого инструмента через этот же инструмент. Не сказать, что это полностью решило наши проблемы, но мы смогли получить окружение со всем работающими зависимостями, что значительно упростило тестирование и релизы новых версий приложения.Что мы имеем?После около 3 лет использования продукт развился от "дёргателя апишки" до полноценного инструмента для разворачивания тестового окружения с множеством настроек, удобств, а также пасхалок. Сейчас им пользуются около 100 человек технического отдела. Невозможно переоценить вклад этого сервиса в автоматизацию процессов в одном из самых нагруженных проектов — он очень велик. Я не стал описывать то, что умеет наш сервис в подробностях: насколько гибкую имеет админку, редеплой по расписанию, скрытые стэки и т.д. Целью было описание сложностей разработки нашего велосипеда стейджинг-инструмента. А также поделиться опытом в создании подобного функционала. А теперь расскажите, как вы в своих проектах тестируете свои десятки и сотни сервисов в разных комбинациях?
===========
Источник:
habr.com
===========
Похожие новости:
- [Хранение данных, Хранилища данных, Облачные сервисы] Google представила новую версию «Диска» на замену «Автозагрузке и синхронизации»
- [Разработка мобильных приложений, Смартфоны, Игры и игровые приставки, IT-компании] Владельцы смартфонов с Android 12 смогут играть в игры в процессе их загрузки
- [Тестирование IT-систем] Тестирование или управление качеством? Часть 1. Что такое тестирование? (перевод)
- [Робототехника] Улучшая движения роботов. Как стартап из MIT автоматизирует маркетплейсы (перевод)
- [Искусственный интеллект, Транспорт, Будущее здесь, Урбанизм] Как автомобили общаются с дорогой и светофорами
- [Информационная безопасность, Гаджеты, Смартфоны] На вторичном рынке появились смартфоны, которые ФБР использовала для шпионажа
- [Управление разработкой, Управление проектами, Микросервисы] От (не)управляемого хаоса к автоматизированному процессу
- [Accessibility, Тестирование веб-сервисов] Обеспечение доступности веб-контента: стандарты, критерии, пример реализации
- [Платежные системы, IT-компании] Google планирует выйти на японский рынок финансовых услуг
- [Go] Golang-дайджест № 6 (1 – 30 июня 2021)
Теги для поиска: #_php, #_go, #_testirovanie_vebservisov (Тестирование веб-сервисов), #_kubernetes, #_php, #_gitlabci, #_avtomatizatsija (автоматизация), #_kubernetes, #_testirovanie (тестирование), #_blog_kompanii_karuna (
Блог компании Karuna
), #_php, #_go, #_testirovanie_vebservisov (
Тестирование веб-сервисов
), #_kubernetes
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:44
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
От печали до радости или от идеи до реализацииКак-то очень давно наш отдел автоматизации внутренних процессов посетил админ (ops) с идеей помочь нашим тестировщикам. Он предложил упростить деплой, т.к. было очень неудобно писать ручные curl запросы к gitlab'у с кучей меняющихся параметров. Так заставили нас наша команда решила помочь дружественному отделу и сделать их работу более приятной.В статье я постараюсь поделиться тем, как мы в Каруне разрабатывали GUI для curl'a, а сделали очень крутой сервис автоматизации. Ещё расскажу, с какими проблемами столкнулись и как их решили (или нет).А почему не взяли готовые решения? (с)Опережая ваши вопросы, дорогие читатели, могу ответить примерно так: хотелось получить более гибкую вещь под наши нужды. По ходу прочтения статьи можно понять, что требования часто менялись, проект развивался. А готовое решение было бы не таким эффективным. Тем не менее, если вы знаете нечто похожее, милости прошу в комментарии.РеализацияВ то время основной проект был монолитом с одним отпиленным сервисом "сбоку". Но, к счастью, был развернут kubernetes, который значительно упростил работу с сервисами. Реализация предполагала простейшую идею: дёргаем настроенный админами триггер гитлаба, передавая названия нужных веток к двум репозиториям.Но тут понеслась...Естественно процесс на этом не остановился, больше людей проявляло интерес к нашему сервису: QA, админы, программисты всех видов и подвидов. С каждым днём мы получали все больше хотелок. Мы улучшали интерфейс сервиса.Начало образовываться все больше внешних интеграций. Например, QA нужны были логи, чтобы понимать, кто удалил или создал очередной стэк (стэком мы называем развёрнутый набор сервисов), кого ругать и кого за него спрашивать. Для этого мы подключили API Kubernetes. Естественно нам нужны были простейшие операции со стеками, такие как удаление, для чего необходимо было использовать helm.Для связи с развёрнутыми контейнерами к каждому сервису мы подключили консоль, которая тянулась через kubernetes websocket.Также необходимо было подключить ssl. Сертификаты стали генерироваться через vault, а далее отправлялись на балансеры и cloudflare.Матрица зависимостейНаверное, это представляется очень пафосно, как-то так:  Но на деле с основе лежала простая идея. Параллельно нашему сервису основной проект также стремительно развивался. Монолит постепенно переходил на SOA, образовывались новые микросервисы. Каждый деплой запускал неконтролируемо огромное количество ненужных сервисов, которые были лишними в разворачиваемом стэке. Необходимо было более умное использование ресурсов. Для этого мы создали так называемую "матрицу зависимостей", позволяющую настроить, какие сервисы от каких "зависят". Пользователь смог сам задавать "наборы сервисов". Выбрав при деплое, что ему нужно, он получал действительно только то, что ему нужно.Например, деплой сервиса статистики разворачивал только необходимый сервис статистики и авторизацию, а не весь монолит с сервисами.Интерфейс нашей шайтан-машины с заполненными фейк-данными представлен ниже.  Упомяну также об ограничении на количество задеплоенного. Все-таки мощности ограничены, и необходимо было ввести лимит на количество стейджей. Т.к. в стейдже может быть разное количество сервисов (и соответственно контейнеров), то ограничение вводилось как раз на количество контейнеров.Веб-сокетыДа, мы их тоже сделали. Вначале это была штука просто для удобства "чтобы не перезагружать страничку".Как я уже описал выше, в одном из проектов Каруны осуществлялся переход от монолита к микросервисной архитектуре. Это заставляло использовать все больше и больше репозиториев gitlab'a. Последовательная обработка запросов к гитлабу сильно тормозила разворачивание сервисов. Пользователь очень долго ждал своего стейджа. Т.к. основное взаимодействие с гитлабом осуществлялось через веб-сокет сервер, мы решили внедрить golang. Это позволило распараллелить эти запросы и значительно увеличить скорость создания нового стейджа.Как. Это. Тестировать.Через полгода активной разработки мы получили сервис с большим количеством внешних зависимостей — было невозможно сложно тестировать. С сервисом уже плотно работало несколько десятков человек, и его недоступность критично сказывалась на процессах. Тестирование через mock'и не справлялось, да и не казалось оптимальным решением. И мы решили...  Сделать возможность разворачивать стейдж этого инструмента через этот же инструмент. Не сказать, что это полностью решило наши проблемы, но мы смогли получить окружение со всем работающими зависимостями, что значительно упростило тестирование и релизы новых версий приложения.Что мы имеем?После около 3 лет использования продукт развился от "дёргателя апишки" до полноценного инструмента для разворачивания тестового окружения с множеством настроек, удобств, а также пасхалок. Сейчас им пользуются около 100 человек технического отдела. Невозможно переоценить вклад этого сервиса в автоматизацию процессов в одном из самых нагруженных проектов — он очень велик. Я не стал описывать то, что умеет наш сервис в подробностях: насколько гибкую имеет админку, редеплой по расписанию, скрытые стэки и т.д. Целью было описание сложностей разработки нашего велосипеда стейджинг-инструмента. А также поделиться опытом в создании подобного функционала. А теперь расскажите, как вы в своих проектах тестируете свои десятки и сотни сервисов в разных комбинациях? =========== Источник: habr.com =========== Похожие новости:
Блог компании Karuna ), #_php, #_go, #_testirovanie_vebservisov ( Тестирование веб-сервисов ), #_kubernetes |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:44
Часовой пояс: UTC + 5