Используете контейнеры (чем оркестрируете) или отдельные виртуальные сервера?
Используем отдельные виртуальные севера.
Есть ли что то интересное в действиях ранеров?
Уточните ваш вопрос, пожалуйста. Вы рассматриваете возможность перехода на Gitlab CI, и вам нужно понять стоит это делать или нет?
Как именно тестировщики идут в ветку для воспроизведения ошибок?
Тестировщики не "ходят" в ветку. Руками тестируется магистральная ветка, созданая специально для этих целей с очевидным названием QA. Мы руками не тестируем каждый фича бранч отдельно.
Насчёт задержек. Честно признаться, в тех редких в наших тестах случаях, когда нам чего-то нужно было дождаться (например, серверную валидацию), мы использовали те самые слипы: await browser.sleep(300). Понимание, что это не круто, есть, но пока что оставили так. Если вдруг вы когда-то найдёте более элегантное решение, будем рады услышать :)
На проекте, описанном в статье, у нас 49 подобных тестов. На полный прогон уходит около 20 минут, запускаем по 2 Хрома и FF. Контейнер Zalenium'a развёрнут на виртуалке с 11Гб RAM, ей доступно 16 ядер xeon e5, но, очевидно, что один этот контейнер расходует очень малую часть всего этого. Вопросом минимальных требований железа не задавались.
Изначальная база для написания тестов была заложена разработчиками, сейчас новые тесты пишет QA-специалист.
По поводу отладки: дебажим локально. Visual studio предоставляет возможность локально дебажить контейнеры. На других средах мы не дебажим. Для этого мы используем Elasticsearch и Kibana.
Мы руководствовались двумя книгами: "Микросервисы .NET. Архитектура контейнерных приложений .NET" и "Микросервисы на платформе .NET". Лучше, чем там описано, мы не сможем объяснить. Главная идея: каждый микросервис должен отвечать за специализированную функциональность.
Асинхронный обмен у нас практически везде, кроме тех мест, где нужно гарантировать, что действие выполнено на другом микросервисе. Например, что результат, полученный с мобильного приложения, обработан другим микросервисом. Также мы руководствовались принципом, что микросервис должен иметь все данные в своей БД, которые ему нужны для работы.
Которые позволили организовать способ взаимодействия между клиентами и микросервисами, которые размещены в K8S. Мы реализовали собственный сервис авторизации,
Выбрать сервисы, которые нужно было разместить в K8S, а какие нет,
Поскольку компания крупная, и мы собираемся расширять функционал, решением будут пользоваться десятки тысяч человек.
О причинах выбора архитектуры подробно описали в этой статье. СУБД развернута на отдельной виртуальной машине без Kubernetes, поэтому объем хранимых данных не сказывается на производительности сервера с приложением, это больше вопрос к структуре БД.
У нас реализован отдельный микросервис авторизации, который отвечает за генерацию jwt токенов по SAML Assertion, который нам отдает ADFS 3.0. Этот jwt токен принимается всеми микросервисами. Реализацию мы подсмотрели здесь и здесь.
Это люди, которые осуществляют приемку. В нашем случае — технологи заказчика.
Используем отдельные виртуальные севера.
Уточните ваш вопрос, пожалуйста. Вы рассматриваете возможность перехода на Gitlab CI, и вам нужно понять стоит это делать или нет?
Тестировщики не "ходят" в ветку. Руками тестируется магистральная ветка, созданая специально для этих целей с очевидным названием QA. Мы руками не тестируем каждый фича бранч отдельно.
Конечно. Напишите вашу почту в ЛС?
Спасибо, перезалили схемы в статье. Увы, Хабр ужимает картинки. Если каждую схему открыть в новом окне — видно лучше.
Насчёт IE в докере — загляните вот сюда https://github.com/MicrosoftDocs/Virtualization-Documentation/issues/214. (P.S. ничего хорошего)
Насчёт задержек. Честно признаться, в тех редких в наших тестах случаях, когда нам чего-то нужно было дождаться (например, серверную валидацию), мы использовали те самые слипы: await browser.sleep(300). Понимание, что это не круто, есть, но пока что оставили так. Если вдруг вы когда-то найдёте более элегантное решение, будем рады услышать :)
На проекте, описанном в статье, у нас 49 подобных тестов. На полный прогон уходит около 20 минут, запускаем по 2 Хрома и FF. Контейнер Zalenium'a развёрнут на виртуалке с 11Гб RAM, ей доступно 16 ядер xeon e5, но, очевидно, что один этот контейнер расходует очень малую часть всего этого. Вопросом минимальных требований железа не задавались.
Изначальная база для написания тестов была заложена разработчиками, сейчас новые тесты пишет QA-специалист.
Спасибо за ценный комментарий! Полностью с ним согласны.
О, спасибо за рекомендацию!
Именно про само переписывание кода писали в предыдущей статье. Ваш комментарий — хорошее дополнение к тем пунктам.
Спасибо за ценный комментарий! Такие очень мотивируют писать новые статьи дальше.
Да, у каждого сервиса своя база.
Это решение на перспективу, когда количество пользователей и функциональности станет больше.
Да, на этом этапе уверены. На практике убедились, что мы правильно разбили проект на микросервисы, и это даёт результат.
Мы также рассматривали настройку с помощью конфиг мапа, но этот подход показался удобнее.
Версионность API нам пока не понадобилась.
Rabbit MQ почти используется для всех коммуникаций, частично ответили на этот вопрос в другом комментарии https://habr.com/company/eastbanctech/blog/420665/#comment_19037049
По поводу отладки: дебажим локально. Visual studio предоставляет возможность локально дебажить контейнеры. На других средах мы не дебажим. Для этого мы используем Elasticsearch и Kibana.
Мы руководствовались двумя книгами: "Микросервисы .NET. Архитектура контейнерных приложений .NET" и "Микросервисы на платформе .NET". Лучше, чем там описано, мы не сможем объяснить. Главная идея: каждый микросервис должен отвечать за специализированную функциональность.
Асинхронный обмен у нас практически везде, кроме тех мест, где нужно гарантировать, что действие выполнено на другом микросервисе. Например, что результат, полученный с мобильного приложения, обработан другим микросервисом. Также мы руководствовались принципом, что микросервис должен иметь все данные в своей БД, которые ему нужны для работы.
Мы считаем нетривиальным следующие решения:
В нашей компании TFS — это корпоративный стандарт, поэтому использовали его.
Именно поэтому микросервис авторизации имеет минимум связей с другими системами. Он зависит только от работы ADFS.
Поскольку компания крупная, и мы собираемся расширять функционал, решением будут пользоваться десятки тысяч человек.
О причинах выбора архитектуры подробно описали в этой статье. СУБД развернута на отдельной виртуальной машине без Kubernetes, поэтому объем хранимых данных не сказывается на производительности сервера с приложением, это больше вопрос к структуре БД.
Это хороший вопрос и достаточно обширный! Хотим ответить в отдельной статье на Хабре.
Спасибо, поправили это предложение в статье. Теперь фраза звучит так:
Соответственно, мы не можем запустить в Docker решения на платформе .Net Framework под Linux.
У нас реализован отдельный микросервис авторизации, который отвечает за генерацию jwt токенов по SAML Assertion, который нам отдает ADFS 3.0. Этот jwt токен принимается всеми микросервисами. Реализацию мы подсмотрели здесь и здесь.
Elasticsearch и Kibana развернуты на отдельной виртуалке, не в Kubernetes.