При большом количестве микросервисов в проекте приходится сталкиваться с тем, что в некоторых из них нужно дублировать один и тот же код (утилитные классы, настройки конфигураций и прочее), а обнаружив баг в одном месте, искать и исправлять его везде. При этом, если микросервисы поддерживаются разными разработчиками, то каждый будет исправлять баг по-своему и в дальнейшем будет сложнее привести всё к единообразию. Давайте на примере рассмотрим несколько подходов к переиспользованию кода в микросервисах.

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

На проекте используется spring boot 2.6.4 и kotlin 1.5.31. Также для конфигурации сервисов используется spring cloud config server, где в качестве backend используются Git + Vault.

Одна из настроек программы (системы управления версиями) «Git» называется «core.autocrlf». В этой статье я на практическом примере описываю, что происходит при каждом из трех возможных значений этой настройки. После этого я делаю выводы о том, для чего эта настройка нужна и в каких ситуациях какие ее значения можно использовать.

Всё описанное происходит в операционной системе «Windows 10». Работу с «Git» я показываю на примере работы из командной строки в программе «PowerShell» версии 7. Используемый дистрибутив «Git» называется «Git for Windows».

Программное обеспечение развивается с течением времени, и автоматизированное тестирование является необходимым условием для непрерывной интеграции и непрерывной доставки. Разработчики пишут различные типы тестов, такие как модульные тесты, интеграционные тесты, тесты производительности и E2E-тесты для измерения различных аспектов программного обеспечения.

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

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

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

Однако, используя Testcontainers, вы можете получить как легкость и простоту модульных тестов, так и надежность интеграционных тестов, работающих с реальными зависимостями.

Доброго всем дня уважаемые хабровчане!

До сего момента я являлся лишь читателем этого замечательного ресурса, но вот кажется и пришло время написать мою первую статью.

Oauth 2.1 - дальнейшее развитие популярного фреймворка авторизации Oauth 2.0, который на момент написания статьи всё ещё вроде как находится в стадии черновика. Но тем не менее уже начинает применяться. На хабре уже есть более подробная статья на эту тему.

Из не очень приятного, из Oauth 2.1 убраны варианты получения токена.