どのようにリリースノートを生成しますか？
[質問]
自動化されたプロセスを介して製品のリリースノートはありますか？もしそうなら。特に継続的な統合サービスでは。スクリプトを使用してログファイルを解析し、そのリリースで修正された問題を探して適切なテキストファイルを作成していますか？
[背景]
最近、趣味のプロジェクトに継続的な統合を実装しました。その一部として、ビルドにリンクされた問題追跡レポートがありました。ただし、リリースについては、同じことを行い、nhibernateリリースノート.txtに似たリリースノートファイルを生成して、非常にクリーンだと考えています。
[例]
ビルド1.2.1
バグを修正しました：
* [ID-1] - The system doesn't accept valid usernames改善点：
* [ID-2] - Saving the file takes 3 minutes when it should take a few seconds.新機能：
* [ID-3] - Allow users to refresh the page using the F5 key.完了したタスク：
* [ID-4] - Document undocumented configuration properties.
通常、この種のことは問題追跡ソフトウェアによって行われます。すべての新機能、すべてのバグ修正、すべての拡張機能を追跡し、それらをリリースに割り当てて、説明からリリースノートを生成します。
Mavenを使用している場合、この目的のために maven changesプラグイン があり、このレポートの作成は継続的な統合プロセスで簡単に自動化できます。
JIRA（私が提案する方法を推奨します）を使用する場合、 リリースノートを自動生成する を使用できます。組み込みフォーマットはかなり単純化されていますが、多くの場合うまく機能します。これは柔軟性の点で究極の言葉ではありませんが、コンテンツはある程度カスタマイズ可能です。
JIRAからのより良いリリースノートを探す場合は、 PDFビュープラグイン を試してください。それ：
- 未加工の「完了した問題」リストだけではありません（例：インストールとアップグレードの手順、法的詳細、実行されたテスト、変更されたファイル）
- 何を含めるかをより詳細に制御する（特定のステータス、解決策、問題の種類などを除く）
- リリースノートドキュメントを電子メール（PDF形式）または紙に印刷して配布できます。
免責事項：私はこの商用JIRAアドオンの開発者です。
私は同じ問題に取り組んでいます。私たちの開発ではsvn/jiraを使用しており、変更がコミットされる前にビルドとサニティテストの変更を試みるカスタムツールがあります。開発では、プロセスの一部としてjira番号を入力します（番号を検証します）。このjira番号はSVNコミットに含まれます
それから、svnの2つのポイントの間にリリースノートを生成し、各コミットのコメントから、コミットされた問題のリストを作成して、リリースノートに入力します。
これに関する問題は、1。リリースノートの問題をコードの変更として入力する必要があることです。コードを変更せずに修正された問題は含まれていません。 2.開発者が修正の途中にいる場合は、リリースノートに表示されない場合があります。
CIシステムからビルドを取得してリリースに変えることができる、最小限の手動オーバーヘッドのソリューションを見つけたいと思います。
問題を解決しないとリリースノートの生成が失敗するようにプロセスを調整することを検討していますが、開発者はリリースしたいときに問題の途中にあると不満を感じるでしょう。
もう1つのオプションは、リリースノートに完了した問題のみを含めることです。ただし、それに関する問題は、開発者がリリースAで修正を行ったが、Aがリリースされたときに問題を閉じなかった場合、Aがリリースされた後にコードを変更せずに問題を閉じた場合、これを自動的に含めるにはどうすればよいですか。リリースノートの問題（リリースAとBの間で閉じられたすべてのジラを検索できるかもしれません...）
読んでくれてありがとう
私の会社では、bugzillaを使用しています。マイルストーンを使用して、特定のリリース番号でバグにタグを付けます。次に、特定のマイルストーンを持つすべてのバグのxmlレポートを生成し、小さなスクリプトを使用してそこからリリースノートを生成します。
これは、一般に、バグ追跡ソフトウェアに簡単に一般化できるものです。
バージョンコントロールシステムのコミットメッセージのコメントに関連付けられている可能性もあります。クエリを実行して、versonコントロールのコミットに関するすべてのコメントを一覧表示し、特定のタグを持つすべてのコメントをフィルター処理できます。
開発者が私人ではなく、割り当てを取得して実行するチームの一部であると仮定すると、実行された、UATの一部であるはずのリストは、事実上のリリースノートです。ファイル変更などのリストは無関係であり、ソース管理から簡単に抽出できます。
問題番号が含まれているコードをチェックインする開発者のポリシーを適用するのは非常に難しいので、気にしません。コードレビューで聞いてみます。私たちが取り組んでいることのリストも保持しています。完了したものは、mvn release：prepareコマンドが実行される直前にログに追加されます。次に、それをQAとUATに渡します。
これは、1週間あたり数百の問題に拡大する可能性は低いです。これらの場合、より堅牢なシステムが望ましいと思われます。
これを行うにはdoxygenのようなツールを使用できますが、doxygenが期待する方法をコメントするのはちょっと退屈です。私は通常これらを手で入手します。
確かではありませんが、FogBugzのようなものもこれを実行しませんか？
私は最近同様の問題に直面し、これを行うために既存のmavenプラグインを拡張しました。
ソース管理にGitを使用し、Mavenを使用してプロジェクトをビルドする場合、これは良い解決策になる可能性があります： https://github.com/pankajtandon/maven-git-commit-id-plugin#releasenotes
.NETとTFSを使用している場合は、 TfsChangeLog を使用してリリースノートを自動的に生成できます。
TFS ChangeLogを使用すると、Team Foundation Server（TFS）ユーザーは、変更セットと関連するWorkItemに関連する情報を、HTMLに変換されるXML形式に抽出できます。 TFSChangeLogは、選択された変更セットの範囲に基づいて、変更ログ/リリースノートを自動的に生成します。
TFSは、登録された変更セットと関連するWorkItemを介してファイルバージョン履歴を保持します。この正確な情報は、リリースノートの生成に使用されます。構成/リリースマネージャは、リリースノートの内容を生成するために、システムデータフィールドまたはカスタムフィールドを使用できます。生のXML形式からデータを変換するための強力なXSLT 2.0サポートは、箱から出してすぐに提供され、さまざまな形式でデータを生成する可能性を確実に広げます。 XSLT 2.0のサポートにより、ユーザーの必要に応じて、変換出力のフィルタリング条件を非常に簡単に適用できます。