Pull to refresh
5
Karma
0
Rating
Александр @alexff91

SE

  • Followers 2
  • Following

CucumberTalks: избегаем антипаттернов и пишем выразительные сценарии

Есть несколько вопросов:


  1. Bdd не только про выразительность, но и про понимание\участие в разработке тестов не только автоматизаторов, но и аналитиков/разработчиков/ представителей бизнеса. Как справляетесь с такой проблемой, что автотесты становятся вещью в себе? Например, есть где-то группа автотестеров/один аатотестер и пишет себе сценарии, вроде есть автотесты, а вроде их и нет.
  2. Как оценить что эти "анипаттерны" помогают? улучшилось ли после рефакторинга легаси что-то? Скорость написания, ревью или только стали читабельнее?
  3. Кто ревьюирует их — другие тестировщики только?( как разработчики узнают об изменениях или аналитики)
  4. Согласно bdd, вначале идет аналитика, потом проектирование, потом разработка. На каком этапе начинаете/стоит начинать сценарии?

Как киту съесть Java-приложение и не подавиться

Данная рекомендация актуальна, если не используются флаги
-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.

Как киту съесть Java-приложение и не подавиться

Да, Вы правы, спасибо за апдейт!
Так же нашел интересную информацию, что все не так просто с этими флагами: blog.csanchez.org/2017/05/31/running-a-jvm-in-a-container-without-getting-killed

Как киту съесть Java-приложение и не подавиться

Spring Boot и обычные jar-ники работают нормально, если нужно что-то хитрее — например обычный Tomcat, то тоже проблем по идее не будет.

Как киту съесть Java-приложение и не подавиться

Ну, вообще цифры немного другие:
openjdk 8-jdk-alpine 3b1fdb34c52a 10 hours ago 101MB
openjdk 8-jre-alpine 5699ac7295f9 12 hours ago 81.4MB


В 6-7 раз меньший размер образа позволяет запускать агенты сборки с меньшим объемом памяти, экономить место локально, по сравнению с 700~800 Мб — довольно большая разница.

Как киту съесть Java-приложение и не подавиться

Из своего опыта работы с Jenkins и Teamcity могу сказать, что сборка в докер-контейнерах обычно протекает немного медленнее, а если используются обычные агенты с предустановленными maven и gradle, с правильными настройками очистки/сброса кэша, то особых проблем с сборкой не замечал. Тут уже в зависимости от нужд надо решать, лучшая изоляция или чуть большая скорость. По поводу кеширующего Artifactory — при большом количестве агентов и сборок может быть высокая нагрузка на сеть и в итоге будет потеря в скорости сборки. Если количество сборок небольшое, то Ваш вариант с раздельными сборкой артефакта приложения в контейнере и упаковки его в отдельный образ — отличное решение.
По поводу локальной сборки на машине разработчика — лично мне удобно иметь локально установленный maven и gradle и запускать сборки из ide, локально собирать в отдельном докер-контейнере мне кажется излишним.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Works in
Registered
Activity