Привет, я — Лёша, и у меня память (часто) как у дрозофилы. Ну не могу я запомнить, где что лежит: где логи, где репозиторий с конфигами, где метрики, конфиг-мапа или трейсы. А кроме того, когда ты только пришёл в новую компанию, то вообще не знаешь, есть ли что-то из этого? Поэтому начну свой рассказ как раз с процесса онбординга в большую компанию (в малых компаниях всё ещё хуже) и проблемами, с которыми я столкнулся.
И о решении, которое подойдёт не только мне.
Про боль онбординга
Лет 6 назад я поменял стек на Java/Kotlin и пришёл в компанию с птичкой, которой, к сожалению, уже почти нет. Мой онбординг начался с задачи, где надо было поправить лог и проверить. Скачал репозиторий, поправил код, собрал приложение на локалке, сделал коммит.
А дальше что? Где посмотреть лог? Куда собирается приложение при коммите? Сколько у нас стендов?
Пошел уточнять у наставника — опытного и не очень разговорчивого сеньора младше меня. Он скинул мне ссылку и примерно описал, что за стенды у нас есть, а также скинул ссылку на CI/CD. Ок, решили.
А потом появилась новая задача. И новые вопросы к наставнику. И опять я забыл, где лежат логи...А в ответах явно чувствовались нотки раздражения: «Я же уже показывал». Не забуду это «туалетное» чувство надолго...
Сначала, чтобы не чувствовать себя дураком, я просто сохранял все инфраструктурные ссылки в закладках. А когда в компании появилась страница с онбордингом в конкретный продукт, стало легче: не надо бегать по закладкам, страница с онбордингом более полная, в ней есть не только та информация, с которой я уже работал. И более актуальная.
Недостатки всё равно присутствовали. Например, я помнил, что где-то там, посреди 40 ссылок, есть такая, в которой более-менее описан процесс деплоя и инфраструктура. Она существовала и до этого, но найти в большой компании в Confluence часто бывает непросто. И да, часто она была устаревшей, например, поменяли Kibana на OpenSearch или что-то добавили. Но ориентироваться всё равно стало проще.
Не забываем, что пришёл я фактически джуном, потому что поменял стек, а значит, стандартное окружение чаще всего отличалось от привычного. Как следствие, часто для меня было секретом, например, что за конфиг я вижу в приложении: вроде пайплайнов, написанных на DSL для CI/CD, или переменных типа {someValue}, которые, как оказалось, подтягиваются из Vault.
Кроме того, в компании были свои разработки, типа приложения-паспорта сервиса (скрин ниже). В нём можно было посмотреть описание/сетевые доступы, которые автоматически добавлялись приложению при коммите, PRC и REST-контракты сервиса, связанность с другими сервисами.
О том, что такое приложение существует, я узнал случайно — от коллеги, потому что групповые чаты у меня, естественно, замьючены. У вас ведь также, когда рабочие чаты довольно быстро превращаются во флудилку?
Примечание: для себя решил проблему своим же ботом.
Неожиданная подсказка
Проблема решилась, когда я освоился. Но осадочек остался.
Я хожу на IT-конференции, чтобы не остаться за IT-бортом — часто там обсуждают технологии или решения, которые скоро станут мейнстримом. И, чтобы чувствовать индустрию, я считаю посещения таких мероприятий своего рода цифровой гигиеной (хотя, конечно, с учётом экспоненциального роста стоимости билетов на конференции, свои деньги я иногда экономлю и смотрю доклады в записи).
И вот где-то в 2022 году на конференции HighLoad я увидел доклад от VK про внутренний плагин для IDEA, который решает описанную мной проблему.
Ребята из dev2dev команды написали плагин, добавляющий удобные ссылки на инфраструктуру. В прямом эфире докладчик показал, что это не сложно, добавив ссылку на случайный сайт.
Но поделиться ссылкой на плагин, чтобы можно было потыкать и переписать под себя, он отказался, так как там были ссылки на их внутреннюю инфраструктуру. И, как он выразился, написать новый плагин и распространить в своей компании архив плагина не сложно.
Решение под себя
В птичьей компании у нас были хакатоны, на которых можно было поработать над чем-то, не связанным с бизнесом напрямую, но полезным для компании. И я взялся за написание плагина для нашей инфраструктуры.
Попытался разобраться в документации IDEA для написания плагинов и понял, что это
ни фиганичуть не просто. Там столько концепций, что просто интуитивно ничего не напишешь. Это как изучать Spring с нуля (имхо, писать на Java / Kotlin и изучить Spring — это задачи разного уровня).
Туториалы в интернете скудные и малоинформативные, а какого-то Baeldung для IDEA нет. Поэтому, если бы не GPT, я бы застрял с плагином на пару месяцев.
В итоге, с некоторым хаком через GPT, подготовил болванку за несколько дней до хакатона (соперники и организаторы, простите, но иначе за сутки ничего бы просто не получилось). За сутки сделал ссылки на часть инфраструктуры и показал на демонстрации. Победил в одной номинации и получил приз.
Но плагин использовался только в нашем продукте, да ещё и в доработанном виде от моего коллеги, потому что был не совсем универсальным и разработали его не dev2dev, соответственно, продвигать некому.
Решение для всех
Ещё тогда пришла в голову мысль, что можно было бы сделать что-то универсальное, чтобы не программировать, а просто настроить и собрать плагин под свою компанию. И вот оно свершилось! Плагин в GitHub — форкайте и радуйтесь!
Плагин настраивается через JSON-конфигурацию и позволяет:
№1. Добавлять ссылки в контекстное меню.
№2. Добавлять ссылки на полях в XML-файлы.
№3. Добавлять ссылки на полях в YAML-конфигах.
№4. Добавлять ссылки по вызову метода определённого класса.
№5. Добавлять ссылки при наличии аннотаций.
Как работает внутри?
И что, если мне нужно больше?
Сейчас плагин анализирует только Java/Kotlin/YAML и XML с помощью IDEA-плагинов для анализа синтаксического дерева. Но у IntelliJ полно других плагинов для адаптации его под:
PHP,
Python,
C-подобные языки,
Ruby,
JavaScript.
И многое другое (полный список плагинов).
Помимо анализа того, что нужно вывести кнопку в меню или ссылку на полях при её формировании, можно передавать маркеры, которые будут браться из контекста. Например, можно использовать:
{fileNameWithPath}— название файла с путем от корня проекта;{yamlValue}— значение в YAML-файле;{appName}— название проекта из Maven или Gradle файлов;{parameter1}— передаваемый статический аргумент в вызываемую функцию;{annotationName}— где name — название параметра в аннотации;{andQueryStringParameters}— конкатенированный список параметров, например, для Kibana или OpenSearch.
Полный список в README.
Для доработки плагина под свои возможности, если не хватает описанного и JSON-конфигурации, добавьте плагин в plugin.xml (если файлы такого типа ещё не анализируются). Вся логика по проверке необходимости отображения хранится в MarginsFactory.kt и в BaseCustomAction.kt, а формирование ссылок находится в LinkGenerator.kt.
Чтобы тестировать написанное, у IDEA есть режим «Sandbox». Запускается так:
В этом режиме IDEA запускает вторую IDEA и можно ставить брейкпоинты/тестировать то, что написали:
После того, как протестировали плагин, надо собрать архив, чтобы распространит в вашей компании:
Если чего-то не хватает, то плагин доделать под себя. Большая просьба — форкните репозиторий или сделайте PR для развития OpenSource. Это облегчит жизнь вашим коллегам, особенно новичкам!
Полезные ссылки:
