Comments 6
Я отказался от bash в пользу Python
Вот собственно для этого питон и создавался, чтобы им баш заменять в тех случаях, где башевые скрипты получаются чрезмерно сложные. А не для всего того, что сейчас стали делать на питоне.
У нас все проще: мы выстроили систему задач в джире, определили какие сущности являются единицами релиза, какие не являются. И пользуемся сущностью релиз. Когда определяем, что должно войти в релиз - крепим к каждой задаче версию релиза. На выходе у нас есть список релизов с датами выпуска и кратким описанием на вьюхе. Если провалиться внутрь конкретного релиза можно увидеть список задач, в которые тоже можно провалиться, посмтореть полную историю разработки и прикрепленную документацию. Там же в релизе можно в текстовом виде посмотреть, что вошло в релиз - задачи группируются по типам
Как идея - не плохо, но на стадии зарождения проекта у нас была заложена немного другая релизная политика. Отсюда и появилась нужда в подобном решении.
Кстати описанная вами схема реализована в новой версии моего скрипта, но, так сказать, от обратного. После исполнения скрипт сам проставляет в трекере задач версию релиза в рамках которой была сделана задача. В следствии можно будет увидеть прям на вебморде трекера сделанные в релиз задачи)
У атлассиан есть библиотека под питон. Хочешь - получай список задач по коммиту, хочешь - по задаче забирай/модифицируй инфу в джире.
У нас тоже релизная политика выстроена постфактум и только так и спасаемся. Есть инфа о прошлом теге, о новом, дергаем диф между тегами и инфу по этим задачам.
А вы изобрели велосипед, извините, дёргая апи напрямую.
QA Documentation. Как я автоматизировал самую нелюбимую часть работы — написание ReleaseNotes