Комментарии 9
Спасибо, с интересом прочитал!
Проголосовал в голосовалке, но ради статистики - changelog.md формирую вручную, использую SemVer (то есть, соответственно, https://keepachangelog.com/ru/1.0.0/ и https://semver.org/spec/v2.0.0.html)
Меня лично не парит, наоборот нравится, потому что лишний раз подумать, что сделал и зачем - это всегда полезно. Но в большой команде, конечно, это здорово.
Но в последнее время я чешу репу и раздумываю, не перейти ли на ComVer? (https://gitlab.com/staltz/comver) . Что-то три числа иногда начинают меня парить :-)
Супер статья, решение огонь!
A на сколько большая по вашему команда должна быть чтобы было целесообразно наворачивать такую систему?
И на сколько быстро мы можем запилить это решение в среднем?(дни, недели, годы?) :)
Спасибо!
С технической точки зрения задача не очень сложная. Правда, на мой взгляд, сложность внедрения решения обратно пропорционально размеру команды. Если у вас на проекте не много программистов, довольно легко будет объяснить им, почему следует добавлять ID задач Jira в сообщения коммитов. С другой стороны, если команда большая, то будут люди, которые начнут нарушать поставленные правила (либо по невнимательности, либо из желания протестовать). В этом случае, следует внедрить еще и git hooks.
Я бы оценил внедрение решения в срок от недели до пары месяцев, в зависимости от количества разработчиков, наличия других практик по коммитированию и полноты описания задач в таск-трекере.
Первый я бы назвал technical oriented, тогда как второй — business oriented стратегией.
Кажется тут последовательность шагов неверно соотносится с предложение ранее. Technical — это про коммиты, а business — про задачи.
То есть не позволяла бы написать некорректное сообщение коммита.
Следующий шаг автоматизации — брать номер задачи из названия ветки и так же через хук подставлять в commit message. Потому что добавлять руками номер задачи в каждый коммит — это довольно нудное занятие, удобнее сделать это единожды для ветки и больше не вспоминать до следующей задачи.
А в целом спасибо за статью, рано или поздно любой растущий проект сталкивается с этой рутиной, которую хочется максимально упростить.
Такое действительно может произойти. Обычно проблема не в том, что задачи описаны двусмысленно. Это следствие. Проблема в коммуникации. Люди решают, что нужно сделать голосом, а потом заводят задачу для соблюдения формальности. Здесь нужно сместить фокус таким образом, чтобы проблемы и вопросы по задаче решались в рамках заведенного тикета. Проще говоря, если задача описана не понятно, я оставляю комментарий к ней до выяснения обстоятельств. Как все вопросы разрешатся, можно поправить описание и только после приступать к выполнению.
Вообще, если честно, у нас такой проблемы не возникало. Для срочного решения можно ставить к таким задачам какой-нибудь лейбл
wrong_task. На CI/CD проверять его наличие или отсутствие, чтобы решить, нужно ли ее добавлять в Release Notes.Если было 4 merge request'а, привязанных к 4 разным задачам, то в Release Notes так же попадет 4 задачи, все верно. Не вижу здесь проблемы.
В таких ситуациях можно добавлять не все задачи, а только story. Обычно именно в них описываются бизнес-кейсы. Если story прилинкована к техническим задачам, то с помощью API Jira можно так же получить по ней информацию.
Расскажите, как этот процесс реализован у вас в проекте и спасибо за чтение!
В одной пластилиновой местности сделано было похоже - в Bitbucket хуки, чтобы pull request-ы не проходили без указания задачи, в Jenkins при сборке формируется Release Notes. И ещё отдельный дашбоард, собирающий, хорошо ли эти RN собираются, и все ли пишут комменты, как надо.
Но один нюанс - Release Notes никто не видел, т.к. прав на их чтение почти ни у кого не было.
Как мы автоматизировали процесс генерации Release Notes