У нас в базе тоже хранятся разные типы данных, просто мы приводим их к нужному виду для отображения. Если же вы спрашиваете про разные типы ячеек, то у нас для этого были сделаны специальные методы. Они для каждого QuestionnaireCellType возвращали его contentType, который отвечал за вид ячейки. А уже для каждой ячейки строится своя viewModel.
Все viewModel ячеек подписаны на один протокол, чтобы его можно было передавать в любую ячейку. И уже ячейка будет определять, подходит ли ей эта viewModel или нет.
А что именно он выкладывает в релизную ветку? релизная ветка имеет название версии вашего продукта?
Релиз :)
Изменения собираются в очередную RC ветку, которая проходит все необходимые предрелизные процедуры и потом эта ветка мержится в релизную ветку.
Сколько у вас компонентов?
На данный момент около 20
То есть при каждом релизе вы деплоите (удаляете и снова создаете) все докер образы в кубере?
Docker-образы в кубернетисе мы не удаляем, но да, всё приложение разворачивается из новых версий docker-образов.
Аффектит ли ошибка в компоненте системы на другие системы? Я так понимаю другие разработчики ждут пока все у кого ошибка в тестах их не исправят. Верно? Хотя наверное у вас Feature branch и ошибки исправляются в тестах в Feature branch.
У нас разработка в feature-ветках, и на Merge Request обязательно запускается билд с прогоном всех тестов, так что ошибки изолируются.
Какая версия Java? Какой вендор Java вы используете? Какой средний размер образа docker?
На самом деле, по умолчанию git describe выдает хэш последнего комита именно из семи символов. Но мы решили это проставить явно, чтобы не зависеть от возможного изменения дефолтного поведения команды.
Сначала вы синхронизируетесь с Git-репозиторием заказчика, а потом вы развертываете в тесте? Сначала обычно тестируют в тесте, а потом отправляют изменения заказчику.
Это среда UAT — User Acceptance Testing. То есть та среда, где конечные бизнес-пользователи или владельцы продукта могли проверить главные бизнес-фичи.
Как вы справляетесь с проблемами helm?
habr.com/ru/company/southbridge/blog/429340
habr.com/ru/company/flant/blog/438814
С какими именно? В этих статьях довольно большой обзор разных проблем.
Мы работаем с SOAP запросами, нам приходится парсить и модифицировать XML запросы, а Kong, согласно этой информации, не умеет с ними работать.
В сторону Ocelot и Tyk не смотрели, поскольку с нашим набором условий (API-портал с зарегистрированными пользователями и огромная экосистема, построенная вокруг портала) показалось проще и надежнее сделать свой API Gateway. Вы их использовали? Поделитесь опытом?
В документе неплохо отобразить критерии по котором тестировщик будет выставлять Severity дефекту, от проекта к проекту они могут меняться. Полезно команде тестирования иметь один подход к определению важности и на случай ротаций пригодится.
Полностью согласны. Мы написали про приотритеты тестирования во второй главе, кажется, это соотносится с вашим тезисом.
Стратегия тестирования = тест-план в вашем подходе?
Согласны, кардинальной разницы нет. Мы описываем подход к тестированию на конкретном проекте, нам удобнее называть это стратегией.
Многостраничный документ с подробным описанием подходов, методов и техник точно поможет в этом? Есть подозрение, что условный Вася-разработчик на документ и не посмотрит.
Наш опыт показывает, что документ получается не такой уж и большой. Например, составленный документ на одном текущем проекте — всего 3 листа. Для разработчиков важны задачи, а они как раз берутся из стратегии.
Если тестировщик делает что-то не связанное с тестированием, зачем это отражать в документе про тестирование? В списке для примера обычные задачи тестировщика, по крайней мере из моего опыта. Для молодых PM-ов, которые впервые столкнулись с тестированием список будет полезен. Для остальных — наверное, нет.
Наш опыт показывает, что не всем это бывает столь же очевидно, поэтому лучше свериться и знать точно, чего PM ждёт от тестировщика на проекте.
Такой документ обязательно должен давать ответ на то, какие ошибки мы считаем важными, какие — нет. Какие необходимо чинить ASAP, а на какие можно забить. Отсылка в критериях готовности к этому в статье есть.
KPI мы используем не для того, чтобы отследить, работает или нет. Функциональность может работать, но ей никто не будет пользоваться. И осмысленные KPI помогают такие ситуации отловить.
Конфигурация ПО на них определяется динамически (например есть файл описания среды в ветке), или есть статический файл конфигурации, который обновляется по мере необходимости?
Вся конфигурация находится в гите. При деплойменте выгружаем на сервера. Разработчик, выполняющий задачу, отвечает за то, чтобы в настройках всех окружений стояли правильные настройки, которые он добавляет или меняет.
"Нет, уже перешли, теперь настала стадия «А правильно ли все сделано? может есть более лучший способ, практики?»"
Мы на нескольких проектах используем Gitlab CI и с контейнерами, и без. То есть опыт у нас довольно обширный. Но без предмета обуждения сложно сказать. Если приведете пример вашего файла, то сможем прокомментировать.
Сейчас ждем новую версию Gitlab CE, в которой будет доступна возможность разделить .gitlab-ci.yml на несколько файлов.
Мы все запускаем ранером. Он деплоит, ждет, чтобы все запустилось, выполняет тесты и т.д.
Используете контейнеры (чем оркестрируете) или отдельные виртуальные сервера?
Используем отдельные виртуальные севера.
Есть ли что то интересное в действиях ранеров?
Уточните ваш вопрос, пожалуйста. Вы рассматриваете возможность перехода на Gitlab CI, и вам нужно понять стоит это делать или нет?
Как именно тестировщики идут в ветку для воспроизведения ошибок?
Тестировщики не "ходят" в ветку. Руками тестируется магистральная ветка, созданая специально для этих целей с очевидным названием QA. Мы руками не тестируем каждый фича бранч отдельно.
Насчёт задержек. Честно признаться, в тех редких в наших тестах случаях, когда нам чего-то нужно было дождаться (например, серверную валидацию), мы использовали те самые слипы: await browser.sleep(300). Понимание, что это не круто, есть, но пока что оставили так. Если вдруг вы когда-то найдёте более элегантное решение, будем рады услышать :)
На проекте, описанном в статье, у нас 49 подобных тестов. На полный прогон уходит около 20 минут, запускаем по 2 Хрома и FF. Контейнер Zalenium'a развёрнут на виртуалке с 11Гб RAM, ей доступно 16 ядер xeon e5, но, очевидно, что один этот контейнер расходует очень малую часть всего этого. Вопросом минимальных требований железа не задавались.
Изначальная база для написания тестов была заложена разработчиками, сейчас новые тесты пишет QA-специалист.
С большой вероятностью сделаем, спасибо!
Поскольку свою среду мы считаем доверенной, вопросы безопасности глубоко не рассматривали. Это хорошая мысль, чтобы немного доработать наш подход.
У нас в базе тоже хранятся разные типы данных, просто мы приводим их к нужному виду для отображения. Если же вы спрашиваете про разные типы ячеек, то у нас для этого были сделаны специальные методы. Они для каждого QuestionnaireCellType возвращали его contentType, который отвечал за вид ячейки. А уже для каждой ячейки строится своя viewModel.
Все viewModel ячеек подписаны на один протокол, чтобы его можно было передавать в любую ячейку. И уже ячейка будет определять, подходит ли ей эта viewModel или нет.
Спасибо за отклик! Рады, что наш опыт вам полезен
Релиз :)
Изменения собираются в очередную RC ветку, которая проходит все необходимые предрелизные процедуры и потом эта ветка мержится в релизную ветку.
На данный момент около 20
Docker-образы в кубернетисе мы не удаляем, но да, всё приложение разворачивается из новых версий docker-образов.
У нас разработка в feature-ветках, и на Merge Request обязательно запускается билд с прогоном всех тестов, так что ошибки изолируются.
OpenJDK 8
На самом деле, по умолчанию git describe выдает хэш последнего комита именно из семи символов. Но мы решили это проставить явно, чтобы не зависеть от возможного изменения дефолтного поведения команды.
Это среда UAT — User Acceptance Testing. То есть та среда, где конечные бизнес-пользователи или владельцы продукта могли проверить главные бизнес-фичи.
С какими именно? В этих статьях довольно большой обзор разных проблем.
Да
Мы не храним ничего в контейнерах, все микросервисы у нас stateless.
Вы могли бы уточнить, каких подробностей не хватило в статье?
Как бы странно это ни звучало, но такое демо действительно было (слайд "OKMP: результаты")
Летом записи появятся на YouTube-канале конференции
Мы работаем с SOAP запросами, нам приходится парсить и модифицировать XML запросы, а Kong, согласно этой информации, не умеет с ними работать.
В сторону Ocelot и Tyk не смотрели, поскольку с нашим набором условий (API-портал с зарегистрированными пользователями и огромная экосистема, построенная вокруг портала) показалось проще и надежнее сделать свой API Gateway. Вы их использовали? Поделитесь опытом?
Организаторы конференции говорят в комментариях, что весной доклады появятся в публичном доступе, и можно будет посмотреть всё в онлайне.
Дополним предыдущий ответ.
Да, вы совершенно правы, смысл в итеративности.
Полностью согласны. Мы написали про приотритеты тестирования во второй главе, кажется, это соотносится с вашим тезисом.
Согласны, кардинальной разницы нет. Мы описываем подход к тестированию на конкретном проекте, нам удобнее называть это стратегией.
Наш опыт показывает, что документ получается не такой уж и большой. Например, составленный документ на одном текущем проекте — всего 3 листа. Для разработчиков важны задачи, а они как раз берутся из стратегии.
Наш опыт показывает, что не всем это бывает столь же очевидно, поэтому лучше свериться и знать точно, чего PM ждёт от тестировщика на проекте.
KPI мы используем не для того, чтобы отследить, работает или нет. Функциональность может работать, но ей никто не будет пользоваться. И осмысленные KPI помогают такие ситуации отловить.
Вся конфигурация находится в гите. При деплойменте выгружаем на сервера. Разработчик, выполняющий задачу, отвечает за то, чтобы в настройках всех окружений стояли правильные настройки, которые он добавляет или меняет.
Мы на нескольких проектах используем Gitlab CI и с контейнерами, и без. То есть опыт у нас довольно обширный. Но без предмета обуждения сложно сказать. Если приведете пример вашего файла, то сможем прокомментировать.
Сейчас ждем новую версию Gitlab CE, в которой будет доступна возможность разделить .gitlab-ci.yml на несколько файлов.
Мы все запускаем ранером. Он деплоит, ждет, чтобы все запустилось, выполняет тесты и т.д.
Это люди, которые осуществляют приемку. В нашем случае — технологи заказчика.
Используем отдельные виртуальные севера.
Уточните ваш вопрос, пожалуйста. Вы рассматриваете возможность перехода на 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-специалист.