CHANGELOG.md: ручное и автоматическое ведение истории изменений проекта в Git
С начала января я веду свой проектик, на котором обкатываю новые для меня технологии:
- Статический анализ кода, phpcs, phpmd, Scrutinizer
- Автоматическая сборка, Travis CI
- Unit тесты, PHPUnit
- Покрытие кода, Coveralls
- Работу через задачи для любых изменений, Github Issues, PhpStorm tasks
- Документирование всего: README, CHANGELOG, сайт проекта, –help
В этом посте изложена история изменений моего мнения о разных генераторах историй изменения.
Tl;dr: conventional-changelog, стандартизация коммитов.
UPD 15.04.2020: как я использую conventional changelog в связке с npm version
CHANGELOG.md
Понятная для человека история изменений проекта нужна. Тут надо заметить что такими историями не являются:
- Issues проекта, ветка в менеджере задач, доска проекта и т.п.
- git log проекта
Файл CHANGELOG.md в корне проекта стал стандартом де-факто для проектов, в котором ведется история изменений, Gitlab даже делает для него отдельную вкладку на странице репозитория.
Про это, конечно, есть сайт, репозиторий на Github с тысячей звезд, проблема явно беспокоит людей.
Про ведение CHANGELOG я задумался, когда изучал проект otto, когда писал про него статью на хабр.
Структура у CHANGELOG более-менее у всех одна и та же:
- Версия и дата релиза
- Сломанные обратные совместимости
- Новые фичи
- Прочие изменения и улучшения
- Исправленные баги
Вести такой документ достаточно просто, я за 120 коммитов почти не забывал это делать. В файле нужно всегда держать вверху секцию Next Release с подготовленными заголовками, как-то так:
## Next Release BREAKING CHANGES: FEATURES: IMPROVEMENTS: BUG FIXES: Перед коммитом я всегда просматриваю дифф, в это время я записываю в коммент к коммиту кратко изменение в первую строку и более подробно в третью, если изменений больше одного, делаю в виде списка. Если про это есть задача, нужно упомянуть ее в виде #123 ссылки, Github умный и такие ссылки делает активными.
Так вот, нужно просто добавить в этот процесс копипасту коммента к коммиту в CHANGELOG, с раскладыванием по категориям изменений.
Во время релиза называем секцию, ставим ей дату, копипастим заголовки.
Процедура очень простая, настолько простая, что хочется ее поручить роботу.
github_changelog_generator
github_changelog_generator — ruby утилита, которая умеет генерировать CHANGELOG.md из любого репозитория. На выходе получаем документ типа этого, наполненный ссылками на задачи и пулл-реквесты, разбитый по категориям, все круто, как в рекламе. У меня получилось совсем не так красиво.
Что мне не понравилось в этом генераторе:
- Текст коммитов никак не учитывает, как и текст задач.
- Чтобы она нормально работала, нужно по полной использовать Github Issues и метки для них, пулл-реквесты, в общем сильно завязано на Github (кто бы мог подумать?), иначе будут генериться просто ссылки на диффы между тегами.
- Нельзя указывать свои секции (например, Breaking changes встроенного нет), но есть issue #316 про это, судя по активности проекта, они скоро появятся.
- Поведение из коробки что-то генерирует, даже если вы не думали про CHANGELOG.md до этого и не использовали Github фишки, это лучше, чем ничего. Но не намного.
- Можно привязывать свои метки к существующим секциям лога.
- Можно настраивать как параметрами к команде, так и конфигом. При запуске скрипт говорит: Performing task with options , так вот, каждую строку из перечисленного ниже конфига можно вставить в файл .github_changelog_generator и переопределить, заменив _ на — .
- Поддерживает сосуществование заполняемой вручную версии (которая все равно лучше автоматической) и генерируемого лога, для этого нужно переложить старый CHANGELOG.md в HISTORY.md (или другой файл, указав его в конфиге).
В общем, github_changelog_generator в моем случае подходит хорошо, если вся работа ведется на Github, это самый простой способ получить красивый CHANGELOG.md
Но на этом я не успокоился, основная причина в том, что на рабочие проекты на Github я не делаю. Хотелось более общего решения.
git-extras changelog
tj/git-extras — это огромный (около 50) пакет дополнительных команд, упрощающих работу с git. Я его раньше уже видел, но в то время подумал, что мне и встроенных в git команд слишком много. Но в поисках генератора снова набрел на него, у него есть такая команда.
Вот таким нехитрым способом можно в одну команду сгенерировать и запушить лог для проекта, где его не было, но версии помечались тегами и комменты к коммитам были осмысленными:
git changelog -a -p -x > CHANGELOG.md && git add CHANGELOG.md && git commit CHANGELOG.md -m "add CHANGELOG.md" && git push origin master Для пробы сделал лог для site-setup, server-scripts, drupal-scripts, на этом успокоился, больше в общем и тестить не на чем.
Ниже я отказался от него в пользу conventional changelog .
Плюсы:
- Простой как дверь, выполняешь команду, получаешь список изменений, разделенных версиями
Минусы:
- Нет почти никаких настроек
rafinskipg/git-changelog
rafinskipg/git-changelog — node.js cкрипт, который парсит коммиты, написанные по стандартам Angular. Я их прочитал, оказалось, что стандарты годные, к angular никак не привязаны.
Конфликтует с git-extras, так как оба они хотят называться git-changelog. Этот я сделал симлинком git-changelog-angular .
Параметров у скрипта немного, я с ними поигрался, но ничего хорошего у меня с этим тулом не вышло. Идем дальше.
conventional-changelog
stevemao/conventional-changelog-cli — node.js скрипт, также нацелен на стандарты Angular, но, по заявлениям авторов это как раз то, что нужно:
- поддерживает свои форматы коммитов и несколько общих: ‘angular’, ‘atom’, ‘codemirror’, ‘ember’, ‘eslint’, ‘express’, ‘jquery’, ‘jscs’, ‘jshint’
- поддерживает шаблоны
- протестирован, в отличие от github_changelog_generator
- отвязан от Github
- имеет модульную структуру и несколько модулей вокруг себя
Воспользовавшись conventional-commits-detector , узнал, что мои комменты к коммитам больше всего похожи на стандарт eslint .
Сгенерированный лог дал понять, что в eslint принято указывать категорию и через двоеточие суть, так коммиты в релизе разбиваются по категориям. Но в целом, конечно, коммиты были названы неправильно и хорошего лога не получилось.
Зато запуск без указания пресета сообщений выдал почти то же, что и git-extras , но вдобавок к этому задал мажорным и минорным версиям разный уровень и указал ссылку на коммит на Github для каждого коммита.
Сгенерировать лог с нуля можно командой:
conventional-changelog -i CHANGELOG.md -s -r 0 После этого я конечно побежал исправлять логи у проектов, которым сделал логи час назад, вот что вышло: site-setup, server-scripts, drupal-scripts.
Для проектов на своем Gitlab все сложнее: чтобы правильно делались ссылки на коммиты, нужно, во-первых, указать адрес проекта через файл package.json:
А во-вторых не знаю, что надо сделать, он генерит ссылки с сокращенными хэшами, которые Github понимает, а Gitlab открывает страницу списка коммитов, т.к. ему нужен полный хэш, шаблон сходу не нашел.
Дальше искать не стал, думаю это оно самое.
Кроме лучшего результата из коробки и полной кастомизации мне в нем понравились модули:
- angular-precommit — готовый валидатор сообщений к коммитам
- conventional-changelog-lint — скрипт для pre-commit хука, проверяющий сообщения коммитов на соответствие стандартам, стандарты описываются в файле
- conventional-github-releaser — автоматическое создание релизов на Github. У меня они уже создаются, но приходится вручную заходить туда и править сообщение к релизу
Выводы
Для того, чтобы генератор создавал по-настоящему хорошие логи, важно определиться с форматом сообщений к коммитам, научиться следовать ему и научить роботов понимать наш формат, чтобы роботы поработили людей помогали правильно и не напрягаясь вести историю изменеий проекта в процессе, а не после работы над проектом.
Для себя я нашел инструмент, которым я теперь могу за 5 минут создавать историю изменений для проектов на основе коммитов.
Генерация CHANGELOG.md — шаг в сторону хорошей и актуальной документации по проекту, которая не будет занимать часы или дни, она будет частью рабочего процесса, конечно для маленького проекта из одного программиста это избыточно, мягко говоря, но надо же с чего-то начинать.
UPD 08.03.2016
npm install -g conventional-changelog-lint echo 'conventional-changelog-lint -e' > .git/hooks/commit-msg chmod +x .git/hooks/commit-msg После этого коммиты с неправильными сообщениями перестанут проходить.
Перед релизом генерирую CHANGELOG.md:
conventional-changelog -p angular -i CHANGELOG.md -s Это допишет в лог содержимое коммитов с последнего релиза (semver тега). После этого остается поправить руками то, что не нравится, проставить версию.
После этого я генерирую документацию специфичной для проекта командой, коммит, тег, пуш:
git add . git commit -m 'docs: v0.6.0' git push --follow-tags После этого релиз. Релиз будем делать через conventional-github-releaser :
npm install -g conventional-github-releaser CONVENTIONAL_GITHUB_RELEASER_TOKEN=your_public_repo_token conventional-github-releaser -p angular Еще не разобрался с тем, как это скрестить с выкладкой PHAR архива с Travis: для github-releaser нужно, чтобы релиза еще не было, но он создается автоматически при пуше тега на Github. После удаления релиза (превращения в Draft), github-releaser отработал, вставил данные CHANGELOG в релиз, все как надо.
Ведите CHANGELOG
Не позволяйте друзьям сливать логи гита в CHANGELOG™
Version 0.3.0
Что такое лог изменений?
Лог изменений – это файл, который содержит поддерживаемый, упорядоченный в хронологическом порядке список значимых изменений для каждой версии проекта с открытым исходным кодом.
# Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ## [1.1.1] - 2023-03-05 ### Added - Arabic translation (#444). - v1.1 French translation. - v1.1 Dutch translation (#371). - v1.1 Russian translation (#410). - v1.1 Japanese translation (#363). - v1.1 Norwegian Bokmål translation (#383). - v1.1 "Inconsistent Changes" Turkish translation (#347). - Default to most recent versions available for each languages - Display count of available translations (26 to date!) - Centralize all links into `/data/links.json` so they can be updated easily ### Fixed - Improve French translation (#377). - Improve id-ID translation (#416). - Improve Persian translation (#457). - Improve Russian translation (#408). - Improve Swedish title (#419). - Improve zh-CN translation (#359). - Improve French translation (#357). - Improve zh-TW translation (#360, #355). - Improve Spanish (es-ES) transltion (#362). - Foldout menu in Dutch translation (#371). - Missing periods at the end of each change (#451). - Fix missing logo in 1.1 pages - Display notice when translation isn't for most recent version - Various broken links, page versions, and indentations. ### Changed - Upgrade dependencies: Ruby 3.2.1, Middleman, etc. ### Removed - Unused normalize.css file - Identical links assigned in each translation file - Duplicate index file for the english version ## [1.1.0] - 2019-02-15 ### Added - Danish translation (#297). - Georgian translation from (#337). - Changelog inconsistency section in Bad Practices. ### Fixed - Italian translation (#332). - Indonesian translation (#336). ## [1.0.0] - 2017-06-20 ### Added - New visual identity by [@tylerfortune8](https://github.com/tylerfortune8). - Version navigation. - Links to latest released version in previous versions. - "Why keep a changelog?" section. - "Who needs a changelog?" section. - "How do I make a changelog?" section. - "Frequently Asked Questions" section. - New "Guiding Principles" sub-section to "How do I make a changelog?". - Simplified and Traditional Chinese translations from [@tianshuo](https://github.com/tianshuo). - German translation from [@mpbzh](https://github.com/mpbzh) & [@Art4](https://github.com/Art4). - Italian translation from [@azkidenz](https://github.com/azkidenz). - Swedish translation from [@magol](https://github.com/magol). - Turkish translation from [@emreerkan](https://github.com/emreerkan). - French translation from [@zapashcanon](https://github.com/zapashcanon). - Brazilian Portuguese translation from [@Webysther](https://github.com/Webysther). - Polish translation from [@amielucha](https://github.com/amielucha) & [@m-aciek](https://github.com/m-aciek). - Russian translation from [@aishek](https://github.com/aishek). - Czech translation from [@h4vry](https://github.com/h4vry). - Slovak translation from [@jkostolansky](https://github.com/jkostolansky). - Korean translation from [@pierceh89](https://github.com/pierceh89). - Croatian translation from [@porx](https://github.com/porx). - Persian translation from [@Hameds](https://github.com/Hameds). - Ukrainian translation from [@osadchyi-s](https://github.com/osadchyi-s). ### Changed - Start using "changelog" over "change log" since it's the common usage. - Start versioning based on the current English version at 0.3.0 to help translation authors keep things up-to-date. - Rewrite "What makes unicorns cry?" section. - Rewrite "Ignoring Deprecations" sub-section to clarify the ideal scenario. - Improve "Commit log diffs" sub-section to further argument against them. - Merge "Why can’t people just use a git log diff?" with "Commit log diffs". - Fix typos in Simplified Chinese and Traditional Chinese translations. - Fix typos in Brazilian Portuguese translation. - Fix typos in Turkish translation. - Fix typos in Czech translation. - Fix typos in Swedish translation. - Improve phrasing in French translation. - Fix phrasing and spelling in German translation. ### Removed - Section about "changelog" vs "CHANGELOG". ## [0.3.0] - 2015-12-03 ### Added - RU translation from [@aishek](https://github.com/aishek). - pt-BR translation from [@tallesl](https://github.com/tallesl). - es-ES translation from [@ZeliosAriex](https://github.com/ZeliosAriex). ## [0.2.0] - 2015-10-06 ### Changed - Remove exclusionary mentions of "open source" since this project can benefit both "open" and "closed" source projects equally. ## [0.1.0] - 2015-10-06 ### Added - Answer "Should you ever rewrite a change log?". ### Changed - Improve argument against commit logs. - Start following [SemVer](https://semver.org) properly. ## [0.0.8] - 2015-02-17 ### Changed - Update year to match in every README example. - Reluctantly stop making fun of Brits only, since most of the world writes dates in a strange way. ### Fixed - Fix typos in recent README changes. - Update outdated unreleased diff link. ## [0.0.7] - 2015-02-16 ### Added - Link, and make it obvious that date format is ISO 8601. ### Changed - Clarified the section on "Is there a standard change log format?". ### Fixed - Fix Markdown links to tag comparison URL with footnote-style links. ## [0.0.6] - 2014-12-12 ### Added - README section on "yanked" releases. ## [0.0.5] - 2014-08-09 ### Added - Markdown links to version tags on release headings. - Unreleased section to gather unreleased changes and encourage note keeping prior to releases. ## [0.0.4] - 2014-08-09 ### Added - Better explanation of the difference between the file ("CHANGELOG") and its function "the change log". ### Changed - Refer to a "change log" instead of a "CHANGELOG" throughout the site to differentiate between the file and the purpose of the file — the logging of changes. ### Removed - Remove empty sections from CHANGELOG, they occupy too much space and create too much noise in the file. People will have to assume that the missing sections were intentionally left out because they contained no notable changes. ## [0.0.3] - 2014-08-09 ### Added - "Why should I care?" section mentioning The Changelog podcast. ## [0.0.2] - 2014-07-10 ### Added - Explanation of the recommended reverse chronological release ordering. ## [0.0.1] - 2014-05-31 ### Added - This CHANGELOG file to hopefully serve as an evolving example of a standardized open source project CHANGELOG. - CNAME file to enable GitHub Pages custom domain. - README now contains answers to common questions about CHANGELOGs. - Good examples and basic guidelines, including proper date formatting. - Counter-examples: "What makes unicorns cry?".
Для чего нужен лог изменений?
Чтобы пользователи и контрибьюторы могли с меньшими усилиями точно определить, какие значимые изменения были сделаны в каждом релизе (или версии) проекта.
Почему я вообще должен думать об этом?
Потому, что инструменты программирования делаются для людей. Если вам пофигу, зачем вы вообще занимаетесь программным обеспечением с открытым исходным кодом? У вас обязательно в голове должен быть центр «не пофигу» 🙂
Я беседовал с Адамом Стаковиаком и с Джеродом Санто в подкасте The Changelog (в тему название, правда?) о том почему авторам программного обеспечения с открытым исходным кодом и их коллегам должно быть не пофигу, и о моих мотивах в создании этого проекта. Послушайте, если у вас есть время (1:06).
Что должно быть в хорошем логе изменений?
Я рад, что вы спросили.
Хороший лог изменений придерживается этих приниципов:
- Он сделан для людей, а не машин, так что понятность имеет решающее значение.
- Легко сослаться на любой раздел (поэтому Markdown лучше обычного текста).
- Один подраздел на каждую версию.
- Релизы перечислены в обратном хронологическом порядке (самые новые – сверху).
- Пишите все даты в формате YYYY-MM-DD . (Например: 2012-06-02 для даты 2 июня 2012 .) Он международный, рациональный, и независим от языка.
- Ясно указывает, использует ли проект Семантическое Версионирование.
- Каждая версия должна:
- Показывать дату релиза в формате, упомянутом выше.
- Группировать изменения согласно их влиянию на проект следующим образом:
- Added для новых функций.
- Changed для изменений в существующей функциональности.
- Deprecated для функциональности, которая будет удалена в следующих версиях.
- Removed для функциональности, которая удалена в этой версии.
- Fixed для любых исправлений.
- Security для обновлений безопасности.
Как минимизировать время, необходимое для ведения лога изменений?
Всегда ведите секцию Unreleased в начале файла, чтобы держать в ней не выпущенные изменения.
Это нужно для двух вещей:
- Люди смогут видеть, какие изменения ожидаются в ближайших релизах
- В момент релиза вам нужно всего лишь заменить секцию Unreleased на номер версии и добавить новую секцию Unreleased в начале файла.
Что заставляет плакать единорогов?
Хорошо… давайте разберёмся.
- Выгрузка изменений лога коммитов. Просто не делайте так, это никому не принесёт пользы.
- Отсутствие отметок планируемой к удалению функциональности. Когда люди обновляются от одной версии к другой, им должно быть очевидно до боли, что сломается.
- Даты в местном формате. В Соединённых Штатах, люди сначала пишут месяц («06-02-2012» для даты 2 июня 2012, что не имеет никакого смысла), хотя много людей в остальном мире пишет роботоподобное «2 июня 2012», всё ещё произнося это по-другому. «2012-06-02» логично работает от самого большого к самому маленькому, не пересекается с другими форматами дат, и является стандартом ISO. Таким образом, этот формат является рекомендуемым для логов изменений.
Существуют и другие. Помогите мне собрать слёзы единорогов, открыв тикет или пулл-реквест.
Существует стандарт формата лога изменений?
К сожалению, нет. Спокойней. Я знаю, что вы яростно бросились на поиски ссылки на GNU-руководства по стилю лога изменений, или на поиски файла «guideline» с парой параграфов в GNU NEWS. GNU-руководство по стилю неплохо для начала, но оно наивно. В наивности нет ничего плохого, но когда людям нужно руководство, она редко бывает полезна. Особенно, когда приходиться сталкиваться со множеством краевых случаев.
Этот проект содержит информацию, которая, я надеюсь, станет соглашением получше о ведении файлов CHANGELOG для всех проектов с открытым исходным кодом. Может ли сообщество учиться на своих ошибках, а не просто действовать согласно десяти записям, которые были написаны много лет назал, и, якобы, без одной ошибки? Хорошо. Поэтому, пожалуйста, посмотрите вокруг, и помните, что обсуждения и предложения по улучшению приветствуются!
Как можно назвать файл лога изменений?
Ну, если вы не не можете ответить на этот вопрос, глядя на пример выше, CHANGELOG.md пока наилучший вариант.
Некоторые проекты используют HISTORY.txt , HISTORY.md , History.md , NEWS.txt , NEWS.md , News.txt , RELEASES.txt , RELEASE.md , releases.md , и так далее.
Это непорядок. Все эти имена только усложняют поиск нужного файла.
Почему люди не могут использовать просто дифф команды git log ?
Потому, что диффы логов по своей природе содержат слишком много «шума». С их помощью невозможно сделать подходящий лог изменений даже в гипотетическом проекте, который делается идеальными программистами, которые никогда не делают опечаток, никогда не забывают коммитить новые файлы, никогда не пропускают ни одну часть рефакторинга. Назначение коммита в том, чтобы задокументировать один атомарный шаг в процессе развития кода от одного состояния к другому. Назначение лога изменений – документировать значимые различия между этими состояниями.
Как отличаются хорошие комментарии к коду и сам код, также отличаются друг от друга и лог изменений с логом коммитов: первые отвечают на вопрос почему, а вторые на вопрос как.
Могут ли логи изменений быть автоматически распарсены?
Это сложно из-за того, что люди следуют сильно отличающимся форматам и соглашениям о именах файлов.
Гем для Руби Vandamme, который создали в команде Gemnasium, парсит многие (но не все) логи изменений проектов с открытым исходным кодом.
Почему вы пишите то «CHANGELOG», то «лог изменений»?
«CHANGELOG» – это имя файла. Оно несколько крикливо, но это историческое соглашение, которому следуют многие проекты с открытым исходным кодом. В качестве примеров подобных файлов можно привести README , LICENSE , и CONTRIBUTING .
Верхний регистр в имени файла (который в старых операционных системах заставляет эти файлы находиться наверху списков) используется для привлечения внимания. Так как в этих файлах содержится важная метаинформация о проекте, они могут быть полезны любому использующему или дорабатывющему проект, также как бейджи проектов с открытым исходным кодом.
Когда я упоминаю «лог изменений», я говорою о назначении этого файла: об учёте изменений.
Как насчёт yanked-релизов?
Yanked-релизы – это версии, которые изымаются из обращения из-за серьёзного бага или проблемы безопасности в них. Часто такие версии даже не упоминаются в логах изменений. А должны. И вот как вам следует их упоминать:
## [0.0.5] — 2014-12-13 [YANKED]
Тег [YANKED] такой «громкий» не просто так. Очень важно, чтобы люди его заметили. А из-за того, что он окружён скобками, его легче определить программно.
Стоит ли переписывать лог изменений?
Конечно. Всегда есть причины для улучшения лога изменений. Я регулярно открываю пулл-реквесты в проекты с открытым исходным кодом с неподдерживаемыми логами изменений для добавления недостающих релизов.
Также вы можете обнаружить что вы забыли адресовать критичное изменение в описании версии. В этом случае очевидно, что нужно обновить лог изменений.
Как я могу помочь?
Этот документ не истина в последней инстанции; это моё тщательно сформулированное мнение вместе с информацией и примерами, которые я собрал. Хотя я предоставил настоящий CHANGELOG из GitHub-репозитария, я специально избегал цели создать стандарт или чёткий список правил (как это делает, например, SemVer.org).
Я сделал это потому, что хочу, чтобы наше сообщество достигло консенсуса. Я верю, что дискуссия также важна, как и её результат.
This project is MIT Licensed // Created & maintained by Olivier Lacan // Designed by Tyler Fortune
Что такое CHANGELOG-файл?
У нас есть один существующие программные обеспечения, связанные с файлами CHANGELOG (как правило это программное обеспечение от Unknown Developer, известное как Unknown Software), и их можно отнести к категории основных типов файлов один. Традиционно эти файлы имеют формат Project Log Or Record File . Чаще всего файлы CHANGELOG классифицируют, как Uncommon Files.
Расширение файла CHANGELOG поддерживается Windows. Данные типы файлов можно найти в основном на настольных компьютерах и некоторых мобильных устройствах. Рейтинг популярности данных файлов составляет «Низкий», что означает, что они не очень распространены.
Однако следует учитывать, что существует намного больше информации, которую следует знать о файлах CHANGELOG; далее представлены лишь савые важные детали в отношении этих типов файлов. Если у вас возникли проблемы с открытием этих файлов, или вы хотите получить более подробную информацию, ознакомьтесь с подробной информацией, представленной ниже.
Правила написания Release Notes
Release Notes – это документ, описывающий изменения между выпускаемой и предыдущей версиями программного продукта. Адресатом данного документа в первую очередь являются технические специалисты клиента, которые занимаются обслуживанием продукта, интеграторы и команды внедрения. Поэтому документ в первую очередь должен содержать полезную техническую информацию, а не маркетинговые лозунги.
Состав документа
В некоторых конторах в качестве Release notes наружу выдают маркетинговый булшит, а реальное техническое содержание оставляют только для внутреннего читателя. Это косвенно указывает на то, что в продукте много проблем, а производитель ПО вместо их исправления скрывает их. В обратной ситуации, когда принята политика открытости перед пользователем, и его честно информируют о всех косяках в софте, то пользователь будет более лоялен к производителю ПО. В качестве дополнительного бонуса прозрачность мотивирует делать качественные продукты. Стыдно ведь публично писать о своей криворукости.
Сам документ состоит из следующих разделов:
Краткое описание продукта
Несколько предложений или пара абзацев о продукте. Служит для того, чтобы человек, которому в руки попал документ, мог погрузиться в контекст. Иначе без введения на него сразу будет вывален список нового функционала и багов. Не нужно сразу пугать людей.
Что нового
Изменение функциональности относительно прошлой версии. Перечисление основных изменений с их кратким описанием. Цель раздела — объяснить пользователю зачем ему тратить своё время и переходить на новую версию.
Исправленные ошибки
Список исправленных ошибок относительно предыдущей версии. Как и предыдущий раздел, этот тоже стимулирует пользователя на апгрейд. Обязательно описать исправленные проблемы, на которые жаловались клиенты и которые были заявлены как known issues в прошлых версиях. Крайне желательно описать те серьезные проблемы, с которыми пользователь мог столкнуться в прошлых версиях, но жалоб на них не поступало. Отсутствие жалоб вовсе не означает, что с ними никто сталкивался. Возможно люди мучились, но у них не хватило сил пробиться через поддержку.
Включать в этот список все содержимое баг трекера не нужно:
- Если баг был сделан, найден и исправлен в процессе разработки текущей версии, то пользователь его видеть не мог, а значит и писать о нем смысла нет.
- Если баг был в прошлой версии, но пользователь его с ним не мог столкнуться. Например, проблема была прикрыта заплаткой в стиле «программа падает при вводе имени пользователя длинной более 10 символов, поэтому мы сделали ограничение на ввод в 9 символов».
Удобно указывать ID проблемы, для удобства истории ошибки.
Список известных проблем или known issues
Если у вас нет known issues – значит никто не тестировал продукт.
Приводим список известных проблем (багов). Идеально, если в нем содержатся все актуальные баги для данной версии. Если их слишком много, то выбираем наиболее критичные для пользователя. Для каждого бага нужно указывать:
- ID по которому дальше можно отслеживать его судьбу.
- Workaround. Что делать пользователю, если он встретился с данной проблемой? Если workaround’а нет для критичного бага, значит продукт содержит критическую проблему и не готов к релизу.
Есть соблазн написать в этот раздел поменьше, чтобы не пугать клиентов. Всех, кто так считает, можно отправить к рассказу Драгунского «Тайное становится явным». Если клиенты действительно используют продукт, то все равно они найдут все эти баги, в дополнение у них еще появятся вопросы к качеству тестирования продукта производителем. А так вы честно демонстрируете открытость клиентам и сразу выдаете список woraround’ов, снижая затраты на поддержку.
Не стоит забывать и про мотивационную составляющую. Если люди работают в условиях прозрачности, то они склонны делать свою работу более качественно, краснеть никто не любит.
Технические ограничения
Любое ПО имеет технические ограничения. Ваш сервер позволяет работать одновременно 10 пользователям? В базу можно сделать только 10000 записей? UI рассчитан только на Full HD? Напишите об этом.
Системные требования
В данном разделе все понятно: минимальные и рекомендуемые требования по железу, поддерживаемые операционные системы, требуемый сторонний софт.
Если параметры железа зависят от сценариев использования продукта, например, от количества пользователей, сложности вычислений, количества данных в базе, то хорошо сделать sizing guide. Это таблица в стиле: если ожидается такая нагрузка, то рекомендуется такое железо.
Особенности обновления с прошлой версии.
Апдейт не всегда проходит гладко. А потеря данных пользователя вообще караул. Лучше сразу предупредить о возможных проблемах.
Кто пишет документ
Документ должен писать технический писатель, как обладатель грамотного письма. А вот информацию для документа: системные требования, описания workaround’ов, исправленные баги и т.п., должны готовить технические специалисты, руководитель разработки, product manager. Если повесить все на человека, у которого основной навык знание языка, то получиться плохо.
Все новости сайта в телеграм канале: @CTO_in_Action