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

Какие инструменты есть в подавляющем большинстве компаний для управления разработкой? Конечно стек Atlassian (Jira + Confluence).

Atlassian хорош тем, что у него есть плагины на все случаи жизни, почти Spring Boot )) Но текущие реалии (да и цена, и завязывание на плагины, которые могут перестать поддерживать) накладывают некоторые ограничения. А что если сделать управление только на том, что есть как говорится "из коробки"?

Итак какую боль хотим решить, зачем мы вообще это делаем:

1. Уменьшить энтропию в репозиториях кодовой базы.

2. Контролировать и фиксировать, что и когда едет в прод.

Вариант решения:

Заводим новый проект в Jira, который будет показывать статус деплоев в прод. Каждый проект Jira обладает уникальным набором компонентов. Вот и можно представить, что компонент в Jira == микросервис, а если еще есть правило, что один репозиторий == микросервис, все становится еще лучше)

Но не будем же мы вести реестр микросервисов в Jira? Нет конечно, это неудобно и Jira не про документацию и реестры, для этого есть Confluence.

Тогда создаем новое пространство в Confluence и оно у нас будет каталогом (мастер данными, НСИ или как угодно) наших микросервисов. Это пространство ТОЛЬКО для этого! То есть 1 страница == 1 паспорт микросервиса. Делаем шаблон паспорта (шаблоны в Confluence) и вуаля, у нас есть два объекта, которые если соединить, то можно получить и описание объекта (паспорт) и его статус (что и как часто деплоится).

Чтобы не синхронизировать справочники руками, достаточно написать скрипт, который будет периодически синхронизировать Confluence с Jira.

Все! Теперь вы можете деплоить только то, у чего есть паспорт (если сделаете поле компонента обязательным;) )

Далее можно сделать много разных фичей на этом решении:

1. Интегрируем с CI\CD. Можно автоматически создавать тикеты в Jira при сборке и перед доставкой. Все таки не все живут на решениях - PR в master, код автоматом в прод.

2. Можно управлять созданием репозиториев. То есть "сначала паспорт, потом репа". Это помогает, в том числе и управлять архитектурой, потому что исключает создание неуправляемого кода.

3. Можно использовать в тикетах жиры автоназначение на code owner'а, через указание его в карточке и заполнение тем же скриптом, например.

4. Структурой в пространстве Confluence можно управлять классификацией микросервисов (отделить бекенд от клиентов, разделять по системам, и т.п.)

5. и многое другое, что решит конкретные боли, конкретной команды.

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