Bdd не только про выразительность, но и про понимание\участие в разработке тестов не только автоматизаторов, но и аналитиков/разработчиков/ представителей бизнеса. Как справляетесь с такой проблемой, что автотесты становятся вещью в себе? Например, есть где-то группа автотестеров/один аатотестер и пишет себе сценарии, вроде есть автотесты, а вроде их и нет.
Как оценить что эти "анипаттерны" помогают? улучшилось ли после рефакторинга легаси что-то? Скорость написания, ревью или только стали читабельнее?
Кто ревьюирует их — другие тестировщики только?( как разработчики узнают об изменениях или аналитики)
Согласно bdd, вначале идет аналитика, потом проектирование, потом разработка. На каком этапе начинаете/стоит начинать сценарии?
Данная рекомендация актуальна, если не используются флаги
-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
В 2 раза больше, потому что при запуске с командой -m 150M докер-демон выделит так же 150 Мб под swap. https://developers.redhat.com/blog/2017/03/14/java-inside-docker/
Но, в целом, увеличение памяти в 2 раза не всегда спасает, т.к. может быть зарезервировано больше памяти и лучше использовать данные флаги(они доступны с версии Java SE 8u131 и в 9-й версии Java) или комбинации ограничений для докер-контейнера по swap и memory.
Ну, вообще цифры немного другие:
openjdk 8-jdk-alpine 3b1fdb34c52a 10 hours ago 101MB
openjdk 8-jre-alpine 5699ac7295f9 12 hours ago 81.4MB
В 6-7 раз меньший размер образа позволяет запускать агенты сборки с меньшим объемом памяти, экономить место локально, по сравнению с 700~800 Мб — довольно большая разница.
Из своего опыта работы с Jenkins и Teamcity могу сказать, что сборка в докер-контейнерах обычно протекает немного медленнее, а если используются обычные агенты с предустановленными maven и gradle, с правильными настройками очистки/сброса кэша, то особых проблем с сборкой не замечал. Тут уже в зависимости от нужд надо решать, лучшая изоляция или чуть большая скорость. По поводу кеширующего Artifactory — при большом количестве агентов и сборок может быть высокая нагрузка на сеть и в итоге будет потеря в скорости сборки. Если количество сборок небольшое, то Ваш вариант с раздельными сборкой артефакта приложения в контейнере и упаковки его в отдельный образ — отличное решение.
По поводу локальной сборки на машине разработчика — лично мне удобно иметь локально установленный maven и gradle и запускать сборки из ide, локально собирать в отдельном докер-контейнере мне кажется излишним.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Есть несколько вопросов:
Данная рекомендация актуальна, если не используются флаги
-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
В 2 раза больше, потому что при запуске с командой -m 150M докер-демон выделит так же 150 Мб под swap.
https://developers.redhat.com/blog/2017/03/14/java-inside-docker/
Но, в целом, увеличение памяти в 2 раза не всегда спасает, т.к. может быть зарезервировано больше памяти и лучше использовать данные флаги(они доступны с версии Java SE 8u131 и в 9-й версии Java) или комбинации ограничений для докер-контейнера по swap и memory.
Так же нашел интересную информацию, что все не так просто с этими флагами: blog.csanchez.org/2017/05/31/running-a-jvm-in-a-container-without-getting-killed
Spring Boot и обычные jar-ники работают нормально, если нужно что-то хитрее — например обычный Tomcat, то тоже проблем по идее не будет.
Ну, вообще цифры немного другие:
openjdk 8-jdk-alpine 3b1fdb34c52a 10 hours ago 101MB
openjdk 8-jre-alpine 5699ac7295f9 12 hours ago 81.4MB
В 6-7 раз меньший размер образа позволяет запускать агенты сборки с меньшим объемом памяти, экономить место локально, по сравнению с 700~800 Мб — довольно большая разница.
Из своего опыта работы с Jenkins и Teamcity могу сказать, что сборка в докер-контейнерах обычно протекает немного медленнее, а если используются обычные агенты с предустановленными maven и gradle, с правильными настройками очистки/сброса кэша, то особых проблем с сборкой не замечал. Тут уже в зависимости от нужд надо решать, лучшая изоляция или чуть большая скорость. По поводу кеширующего Artifactory — при большом количестве агентов и сборок может быть высокая нагрузка на сеть и в итоге будет потеря в скорости сборки. Если количество сборок небольшое, то Ваш вариант с раздельными сборкой артефакта приложения в контейнере и упаковки его в отдельный образ — отличное решение.
По поводу локальной сборки на машине разработчика — лично мне удобно иметь локально установленный maven и gradle и запускать сборки из ide, локально собирать в отдельном докер-контейнере мне кажется излишним.