Автоматизация наполнения Changelog через CI

[x0rHamster]

Шаг 1 ... введение нового требования к оформлению коммитов внутри команды, чтобы они соответствовали соглашению выше

Обычно это - самый сложный этап :) Точнее, сложно не ввести, а поддерживать его соблюдение на больших интервалах. Конечно, в коммите можно ограничиться ссылкой на задачу, а changelog строить по данным таск-трекера (теперь можно и коммитить раз в 15 минут, и squash'ить ветки), но это все еще требует дисциплины (адекватных названий карточек, которые и суть отразят, и пользователям показать не стыдно). У вас, насколько я понял, библиотеки сугубо для внутреннего использования, поэтому из-за случайно проскочившего слова "жопа" или изменения "this solves it" если и расстроятся, то не очень сильно. Или я неправ, и ваши процессы как-то гарантируют, что данные для changelog'ов всегда будут близки к идеалу?

[Aquahawk]

Pre push hook решает проблему кривых коммитов

[alexandrtumaykin]

Вы правы, библиотеки используются внутри компании. Для соблюдения требований к формату сообщений я добавил со временем еще дополнительные этапы проверок:

• локальные git-хуки, которые проверяют:

  • чтобы названия веток соответствовали номеру задачи в jira

  • заголовок коммита соответствовал требованию формата и чтобы номер задачи в заголовке соответствовал названию ветки

• gitlab-хуки на пуши и merge request, которые обрабатываются веб-сервисом. Здесь так же делаются аналогичные проверки, + еще проверяются другие кейсы и некоторые автоматизации, и в случае косяка в MR создается дискуссия с замечанием.

Похожим образом можно цензурировать сообщения + дополнительно проверять на ревью.

[AlexXYZ]

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

[alexandrtumaykin]

Плохо себе это представляю. Имеется в виду через комментарии к коду?

[alexandrtumaykin]

Меньше рисков конфликтов. В MR только свежий код, который отстает от "master" ветки на один коммит. Если код отстает больше, чем на один коммит, до задачу возвращаем на rebase

[alexandrtumaykin]

Интересный вопрос. Если честно, то не знаю. Мы как-то из практических соображений к этому подходу пришли.

[alexandrtumaykin]

Все верно.

Есть какие-то явные минусы у подхода?

Если накопились MR к одному сервису/библиотеке, их все придется периодически рибейсить, по мере попадания задач в тестирование.

Зависит от принятого флоу и на каком этапе есть "узкие горлышки".

[erratir]

Так как наши проекты так же пишутся на PHP, генератор показался интересным

Для JavaScript взял за основу semantic-release. Который с помощью плагинов так же может генерировать CHANGELOG.md (плагин @semantic-release/changelog ) и релизы на основе заголовков коммитов.

У GitLab в доках есть пример.

Бонусом сделал отправку changelog в телеграмм. Дергаю API GitLab, парсю поле description (оно в формате markdown) и перегоняю в формат понятный телеграмму. В итоге выглядит примерно так:

[erratir]

Не загрузился скрин из телеграмма

[alexandrtumaykin]

Идея хороша, когда мало репозиториев и версии не так часто растут

[erratir]

А в чем вы видите отличие от вашего варианта? Так же в пайплайн каждого репозитория добавлена джоба, которая стартует стартует на мердж в мастер, на основе заголовков коммитов повышает версию релиза в гите, повышает версию npm пакета (если надо), генерирует changlog.md и кидает сообщение в служебный канал телеграмма. Ручных действий не требуется.

[alexandrtumaykin]

Концептуально отличия нет.

Еще до ведения changelog'а мы начинали с ручного ведения истории в чате. По мере роста количества версий и репозиториев, в чат перестали смотреть.

[erratir]

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

Т.е. у нас есть группы/каналы в телеграмме, на которые подписаны IT-отделы клиентов и туда улетают ченджлоги некоторых репозиториев.