継続的インテグレーション中のプロジェクトがあり、エンドユーザーのドキュメントをプロジェクトに追加したいと思います。エンドユーザーのドキュメントはユーザーマニュアルであり、APIのドキュメントではありません。私たちの環境では、windows、c＃、msbuild、cruisecontrol.net、subversionを使用しています。現在、DocToHelpを使用して、mswordドキュメントに基づくヘルプファイルを作成しています。
エンドユーザーのドキュメントを管理する方法についてのガイダンスを探しています。どのドキュメントツールを使用する必要がありますか？ドキュメントツールのいずれかをビルドスクリプトの一部にする必要がありますか？ドキュメントツールからの出力ファイルをSubversionに保存する必要がありますか？どのタイプのヘルプファイルを使用するのが最適ですか？
過去 6 年間、 XMLMind XML エディターを使用して、バージョン管理システムに保存できる統一された docbook 形式でユーザー ドキュメントを作成してきました。標準の XSL 変換を使用して、Docbookから HTML および PDF 形式のユーザー ドキュメントを生成します。もちろん、これはすべて継続的インテグレーションとリリース ビルド サイクルの一部です。
お役に立てれば。
Doxygen をご覧になることをお勧めします: http://www.doxygen.nl/
Doxygen は、C++、C、Java、Objective-C、Python、IDL (Corba および Microsoft フレーバー)、Fortran、VHDL、PHP、C# のドキュメント システムです。
私はDocToHelpを知りませんが、ここに私の意見があります：
それが唯一のことだとしても: 生成されたヘルプ ファイルと、それを作成するために使用したすべてのファイルをバージョン管理システムに追加することから始めます。
ヘルプ ファイルを生成することが、Word doc ファイルを処理することと大差ないのであれば、CI サーバーに統合する必要はないでしょう。CI サーバーのビルド アーティファクト フォルダーには、バージョン管理から取得したヘルプ ファイルのみが含まれます。
大量のファイル (ドキュメント内の外部リンクされた画像など) があり、失敗する可能性がある場合は、ファイルを追加できます (ヘルプ ファイル構築ツールで許可されている場合)。
基本的に、CI サーバーが証明するのは、バージョン管理からヘルプ ファイルを再現できるかどうかです (コミットしてすべてを追加しましたか?)。さらに、ビルド ヘルプ ファイルを調べて、ソフトウェア自体で参照されているヘルプ コンテキスト ID と比較する自動テストを作成することもできます。しかし、ここで私は推測しています (私は長い間ヘルプファイルを作成していません :-))。