(не плохо бы третий пункт добавлять - для тех кто не пишет мик. серв, а нажать хочется)

Еще вариант с git сабмодулями добавить можно.

Потомуштогит

сабмодули хоть както бы решили, но идея не могет в них, поэтмоу каждому свой проект и своя репа

Коллеги, очень интересный опрос, было бы здорово, если бы вы еще написали свой опыт и почему такой выбор был сделан.

что бы не пересекались никак, не мешать разработке других команд

Я вот думал что микросервисы - это уже про разные команды. И если изоляция происходит на уровне кода, в репозиториях, то у меня возникает вопрос, какие же задачи решают разработчики проекта микросервисным подходом? Или может быть нет там микросеовисов вовсе?

У меня такие соображение: каждому микросервису, свой гит, чтобы удобно было смотреть изменения по нему, без всяких коммитов-шумов. Но, когда я работаю с несколькими из микросервисов, я их импорчу себе в проект, и работают с одним окном и n сервисов

https://12factor.net/codebase

Я вот думал что микросервисы - это уже про разные команды. И если изоляция происходит на уровне кода, в репозиториях, то у меня возникает вопрос, какие же задачи решают разработчики проекта микросервисным подходом? Или может быть нет там микросеовисов вовсе?

ну как разные

Я вот думал что микросервисы - это уже про разные команды. И если изоляция происходит на уровне кода, в репозиториях, то у меня возникает вопрос, какие же задачи решают разработчики проекта микросервисным подходом? Или может быть нет там микросеовисов вовсе?

Я, кстати, никогда не думал так, почему микросервисы всегда разные команды?

сабмодули хоть както бы решили, но идея не могет в них, поэтмоу каждому свой проект и своя репа

Я в идее их пользую.

читал такую мысль, что нет в микросервисах проектного подхода

типо админы, фронтендеры, бэкендеры и т.д.

а просто тасуют народ и каждый раз на новый сервис посылают

т.е. сегодня я с Антоном пилю один сервис, а завтра с Васей другой

на то он и микро

т.е. сегодня я с Антоном пилю один сервис, а завтра с Васей другой

отлично же?

Я, кстати, никогда не думал так, почему микросервисы всегда разные команды?

Нет не всегда, не так выразился, сорри. Просто это один из бенефитов, который представляют микросервисы в корпоративной среде

https://12factor.net/codebase

Вот там ни слова про микросервисы же? Или я с мобильника не увидел?

Я в идее их пользую.

Чета год назад, когда я пытался это использовать нихера нормально не работало, хотя уже точно и не упомнишь в чем пробелмы были

Я вот думал что микросервисы - это уже про разные команды. И если изоляция происходит на уровне кода, в репозиториях, то у меня возникает вопрос, какие же задачи решают разработчики проекта микросервисным подходом? Или может быть нет там микросеовисов вовсе?

А задачи, какие решают, наверное: разделяют приложения по типам, уменьшают сложность, улучшают масштабироваемость более мелких узлов системы. Но, с другой стороны усложняют инфроструктуру.

Вот там ни слова про микросервисы же? Или я с мобильника не увидел?

в общем, на юдасити эти 12 факторов просят использовать в каждом микросервисе

Вот там ни слова про микросервисы же? Или я с мобильника не увидел?

Это отличный подход, я его под сомнение не ставлю, если что. Просто он не говорит о том что не может быть одна репозитория но одно приложение (читай, микросервис)

у юдасити есть курс по куберу и докеру и они об микросервисах тоже там рассказывают

У меня такие соображение: каждому микросервису, свой гит, чтобы удобно было смотреть изменения по нему, без всяких коммитов-шумов. Но, когда я работаю с несколькими из микросервисов, я их импорчу себе в проект, и работают с одним окном и n сервисов

так-то и git log path/to/my/shitty/service позволяет смотреть нужные изменения

А задачи, какие решают, наверное: разделяют приложения по типам, уменьшают сложность, улучшают масштабироваемость более мелких узлов системы. Но, с другой стороны усложняют инфроструктуру.

Резонно, если так

мне нравится, что когда проджект пер репо, джобы сиай для каждого проекта отдельно

тестируется тоже отдельно

ну в этом есть плюсы

тестируется тоже отдельно

А если интеграционные тесты? Отдельно репа для тестов?

по сути сиай двухуровневый

А если интеграционные тесты? Отдельно репа для тестов?

интеграционные или системные?

А если интеграционные тесты? Отдельно репа для тестов?

(Я бы так сделал)

(Я бы так сделал)

так и делали в общем-то

для поднятия всех компонент

даже вот в РП немного обсуждали это

мне нравится, что когда проджект пер репо, джобы сиай для каждого проекта отдельно

но с другой стороны на стадии разработки придётся часто делать два параллельных пул реквеста, что неудобно

интеграционные или системные?

Допустим, тестируешь 2 компонента из 5и?

когда я вопрос задал

Допустим, тестируешь 2 компонента из 5и?

Это системный тест тогда, или интеграционный?

мое мнение - интеграционный

я бы сделал отдельно модуль, с общими элементами для тестов. И в каждый микросервис пихал его как тест компайл, а дальше бы писал тесты

и можно юзать докер-контенеры для зависимых компонент

а поднимать в том репозитории, что оттестировать хочешь

системные прогоняются на всей системе вроде как, по крайней мере мне так ответили на стриме)

кстати, для следующего РП темы еще не подбирали?

системные прогоняются на всей системе вроде как, по крайней мере мне так ответили на стриме)

Ну вот тонкая грань :)

может обсудим вот это?

люди в команде у вас есть с такой экспертизой

кстати, для следующего РП темы еще не подбирали?

Никогда не подбирают особо

@gamussa что скажешь?

в чем тогда разница между интеграционными тестами и системными?

Коллеги, очень интересный опрос, было бы здорово, если бы вы еще написали свой опыт и почему такой выбор был сделан.

есть и то и то =)

в чем тогда разница между интеграционными тестами и системными?

1. Проверяют существующий функционал 2. Проверяют всю систему

А были ли РП про zookeeper или подобные вещи? Кто знает? =)

но грань очень тонкая и хотелось бы прояснения от сильных мира сего

поэтому @gamussa

откликнись как будешь доступен

А были ли РП про zookeeper или подобные вещи? Кто знает? =)

Не было

Не было

Антон, ну или ты, пожалуйста, передай Виктору этот вопрос.

зачем

он тебе ответит позже

зачем

может он в телегу не заходит, на всякий случай

Антон, ну или ты, пожалуйста, передай Виктору этот вопрос.

Передал. Проснется посмотрит

Не было

Жаль, у меня сейчас каша в голове. Изучаю zookeeper, пока все хорошо, но он сам по себе странноват.

ERROR: S client not available

У нас вот интеграционные тесты лежат с кодом приложения. Системные тесты в отдельной репозитории, и поднимают все модули, не важно сколько их там тестируется. Мой вопрос про 2 из 5 был набросом :)

а интеграционные тесты к чему доступ имеют?

В интеграционных тестах вполне нормально использовать моки на уровне системы. В системных тестах все компоненты настоящие

Жаль, у меня сейчас каша в голове. Изучаю zookeeper, пока все хорошо, но он сам по себе странноват.

там все просто, главное используй библиотеку curator, а не оригинальную zookeper https://habrahabr.ru/post/334680/

Бывают исключения, конечно, когда.какойто сервис вообще внешний и обращение к нему стоит денег. Если такое автоматизировать на живую, может дорого обойтись :)

например, я хочу протестировать какой-то сервис в приложении, который работает с базой

Передал. Проснется посмотрит

спасибо, дружище

у нас есть база в тестовом контуре

там все просто, главное используй библиотеку curator, а не оригинальную zookeper https://habrahabr.ru/post/334680/

я так и делаю. Но есть вопросы

где нужно мокать, а где нужно реально использовать реализации?

если это интеграционный тест

вот поэтому я их хочу, чтобы РП новый на эту тему был

я бы книжку прочитал

лучше

окей, скинь мне книжку такую

https://www.amazon.com/Integration-Testing-Trenches-Nicolas-Frankel/dp/2955021431

вроде выглядит неплохой

Николас хороший дядька, вредного не посоветует

с амазона заказать

или купить на торренте

где нужно мокать, а где нужно реально использовать реализации?

У меня на это ответа нет. Смотря какие цели, я считаю

или купить на торренте

скинь линк, как купишь)

@fundamentalparticle когда на сайте РП выложите 141 выпуск?

Народ, не упарывайтесь по тестам, там все просто. Лучше делите на группы по длительности: [очень быстрые] - юнит, их должно быть много и от них зависит сборка пакета перед деплоем/покоммитная сборка. Они проверяют всю логику и ветвления, после этого логику тестировать уже не надо на уровне системных/интеграционных. [быстрые] - интергационные, в них все внешние системы замоканы, но используются большие связные куски вашей системы. БД может быть embedded, поэтому они тоже довольно быстрые. Покоммитная сборка может от них не зависеть, но сборка билда/пакета должна. Они не должны тестировать логику, они тестируют связи компонентов. [медленные] - системные, они используют реальные внешние системы (БД, зукипер, редис) и обычно запускаются против приложения, развернутого в dev или prestable контуре. Сборки от них не зависят, но когда они красные билд не едет в прод. Могут занимать и полчаса, но чем быстрее - тем лучше - меньше time to market. Их еще можно назвать регрессионными. [очень медленные] - например smoke. Подтип системных, но когда даем запредельную нагрузку. Эти по желанию, если важно держать rps на заданном уровне и не подохнуть на пике.

smoke это не оч медленные

в каком случае пишете интеграционные и выше тесты?

Всегда, без них стрёмно

90% покрытие интеграционными? как поддерживаете все моки внешних систем и базы?

По coverage не скажу, это больше характеристика юнит тестов. Моки нечасто выходят из строя, когда выходят - ручками поддерживаем

Тоже вот стараемся писать на все что можно юниты и интеграционные, с тестами jms много заморочек было, если бы ещё во всех микросервисах проекта был spring boot, а то без mock bean и прочего сахара в интеграционных тестах - стремно иногда становится прям.. Ну сейчас ещё для тестов сопряжения нескольких микросервисов, есть мысль соседние сервисы в докер завернуть. Но это прям slowly tests.. Делать такое перед каждым пул-реквестом терпения не хватит.