Разработка

Привет! Я Анатолий, фронтенд-разработчик сайта Selectel. Тот, кто работает с кодом, понимает, как часто приходится делать коммиты. Вроде бы «дело на пять минут», но это не так: процесс отнимает много времени, если нужно внести десятки изменений. Чтобы сэкономить драгоценные минуты и упростить работу себе и коллегам, я разработал расширение, которое автоматически переносит информацию из задачи в GitLab. Проблема потерянного времени Коммит изменения в GitLab — фоновый и рутинный процесс, на который никто не закладывает рабочего времени. Но в нем есть действия, которые съедают 18 секунд при каждом коммите. Десять коммитов — уже три минуты за день и 15 за неделю. Да, немного, но на это тратится внимание. К тому же за эти 15 минут можно сделать что-то полезное или просто выпить кофе и дать мозгу отдохнуть. Полгода назад я сменил место работы. Во время адаптационного периода у меня не было серьезных проектов, поэтому я мог придумывать задачи сам себе. Это отличный шанс посмотреть на процессы в команде и попробовать сделать их лучше. И, как позже выяснилось, это очень благодарный труд. В команде принято использовать ID задач из Jira в качестве названий для веток и Conventional Commits. Формат: type (compontent_from_Jira): subject TASK_ID. Удобство от такого подхода я ощутил сразу: в Gitlab намного проще ориентироваться. Ветки, коммиты, мердж реквесты — все становится очевидным. Но есть и обратная сторона медали — приходится писать эти сообщения о коммите. Процедура коммита выглядит так: Копируешь тип задачи в Jira, вставляешь в сообщение коммита. Копируешь компонент задачи в Jira, вставляешь в сообщение коммита. Копируешь название задачи в Jira, вставляешь в сообщение коммита. Копируешь ID задачи, вставляешь в сообщение коммита. Коммитишь. Получаем сообщение типа «feat(common): Сделать кнопку чуть краснее или чуть больше WEB-1234». Именно исправлению этого малого неудобства я и решил посвятить большую часть своего внимания. Очевидное и простое решение Зачем заставлять пользователя (разработчика) копировать эти поля и вручную форматировать сообщение коммита, когда можно отказаться от конвенции автоматизировать это с помощью расширения для браузера? ТЗ: кнопка на странице Issue в Jira, которая будет класть в клипборд отформатированное сообщение. Попытка №1 Используя crxjs, создаем расширение на Vite и Preact. Расширение состоит из манифеста, content script, popup и service worker. Если не вдаваться в подробности, то popup – это окошко, которое появляется при клике на иконку расширения. Там мы размещаем пользовательские настройки, а content script вставляется в страницу и позволяет манипулировать DOM-ом. Внутри content script создаем кнопку в нужном месте: По клику на нее соберем поля таски и составим из них сообщение: Полученное сообщение кладем в клипборд и показываем тост, чтобы пользователь не сомневался, что ему в клипборд что-то попало и это не «каша»: Вуаля! Теперь можно наслаждаться новой кнопкой в Jira и экономить 18 секунд каждый раз, когда надо составить сообщение коммита. Осознание и новое решение Через неделю использования меня стала тревожить мысль о том, что я заменил несколько глупых шагов одним глупым шагом. Конвенция коммитов не стала абсолютным плюсом, а так и осталась компромиссом. Мы получали читаемый GitLab, но все еще платили за это своим временем, хотя и не так много как раньше. Теперь мне приходилось открывать браузер с открытой Issue в Jira и нажимать на кнопку. Это лучше, чем копировать четыре поля, но все равно глупо. А самое обидное, что бескомпромиссное решение было все это время под носом, а если точнее, над промптом. Мы же в консоли и IDE знаем, в какой ветке мы находимся, а значит знаем, над какой таской работаем! ТЗ: написать расширение для WebStorm, которое будет ходить в Jira, находить Issue, исходя из названия текущей ветки в IDE, составлять сообщение о коммите и сразу вставлять его в соответствующее окошко в IDE. Попытка №2 Для основы я нашел существующий open source-проект, который добавляет окно для создания сообщений коммита по шаблону. Для работы с ним достаточно изучить Java, потратить день, чтобы понять, как ставить зависимости, сбилдить проект и пофиксить LinkageError. Это совсем не то, что нам надо, но это намного лучше, чем начинать с нуля! Интерфейс плагина. Например, в этом плагине уже добавлена кнопка в интерфейс, по нажатию на которую появляется окно выше: И реализована функция получения названия ветки для использования в качестве Jira ID: Напишем класс для взаимодействия с API Jira и будем передавать туда этот ID. Напишем класс CommitMessage, который будет принимать Issue и иметь метод для превращения этого Issue в строку подходящую под наш формат. Везде для взаимодействия с Jira используется пакет Atlassian Jira REST Client API. В плагине уже существовал класс CreateCommitAction, который соответствовал из plugin.xml, он обрабатывает нажатие на добавленную в интерфейс кнопку. Перепишем его, чтобы он не открывал окно, а обращался в API и создавал сообщение о коммите из полей таски: Код выше использует класс AppSettingsState. С помощью него мы получаем параметры, заданные пользователем в настройках. Взаимодействие с настройками реализованы в соответствии с официальным туториалом. Билдим проект через Tasks → intellij → buildPlugin. Ставим его с диска — и получаем желаемый результат! Заключение Не уверен, что конечный продукт стоил потраченных усилий, но полученные навыки определенно того стоили. Я наконец получил решение, которое фундаментально лучше уже не сделать. Или сделать? Оставим этот вопрос на будущее.

Разработка

Netdata: мониторинг в реальном времени

Как улучшить монетизацию игр при помощи CDN

Анализ HTTP-трафика с mitmproxy

Статические сайты: настройка и оптимизация

Выбираем генератор статических сайтов

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