12

ソース管理システム（Subversion）を実装する準備をしていますが、フォルダーの構造化方法についていくつかの疑問に直面しています。

私はすべての開発にDelphiを使用し、IDE内からプロジェクトをコンパイルします。

私の現在のプロジェクトフォルダ構造は次のとおりです。

-E：\ Work\1。共有
-フォーム（すべてのプロジェクトで共有されるフォーム）
-ユニット（JCLなどのサードパーティを含むすべてのプロジェクトで共有されるユニット/クラス）

-E：\ Work\2。会社名
--管理者（管理者に関連するものは、ライセンスキージェネレーター、注文処理を自動的に処理するWindows CGIなど、すべてDelphiで開発されています）
-プロジェクト
---- ProjectA
----- 5.x（バージョン5.x）
------ BIN（このプロジェクトのすべてのバイナリが移動する場所）
------ビルドマネージャー（FinalBuilderプロジェクトが存在する場所）
-------インストール（setup.exeを作成するNSISファイル）
-------保護（コンパイルされたexeを保護するためのプロジェクトファイル）
-------更新（自動更新に関連するinfファイル）
------ドキュメント（セットアップファイルに含まれているreadme.txt、license.txt、history.txtがあります）
-------欠陥（私または他の人が行ったテストのドキュメント）
------- HTMLHelp（プロジェクトのhtmlヘルプ）
------ R＆D（スクリーンショット、デザインのアイデア、その他のR＆Dの内容）
------リリース（FinalBuilderでリリースをビルドする場合、nsisによって作成されたセットアップファイルはここに配置されます）
------リソース（このプロジェクトで使用される画像およびその他のリソース）
------ソース（サブプロジェクトが存在する場合、それらはすべて関連しているため、BINにコンパイルされます）
-------サブプロジェクトA
-------サブプロジェクトB
------- SubprojectC
-サイト
--- companywebsite.com（現時点では1つだけですが、製品用に個別のWebサイトを用意することにした場合、それらはすべてSitesフォルダーに配置されます）

記号「-」はディレクトリを示します。

誰かが現在の構造についてコメントしたり、それを改善するための提案がありますか？

ありがとう！

4

2 に答える 2

30

何年にもわたって文字通り何百ものプロジェクトをセットアップし、ソフトウェア構成管理とリリース エンジニアリングに特化してきたので、まずプロジェクトをどのようにビルド/リリースするかに焦点を当てることをお勧めします。

IDE のみを使用してプロジェクトをビルド (コンパイルおよびパッケージ化) する場合は、その IDE の一般的な規則に加えて、見つけた「ベスト プラクティス」に従うこともできます。

ただし、IDE だけでビルドしないこと、またはまったくビルドしないことを強くお勧めします。代わりに、利用可能な多くの優れたオープンソース ツールの 1 つまたは複数を使用して、自動化されたビルド/リリース スクリプトを作成します。あなたは Windows をターゲットにしているように見えるので、テストのために Ant、Ivy、および適切な xUnit (Java の場合は jUnit、.NET の場合は nUnit など) を調べることから始めることをお勧めします。

その道をたどり始めると、プロジェクト構造、ビルド スクリプトの設計、テストなどに関する多くのアドバイスを見つけることができます。今は詳細なアドバイスで圧倒されるのではなく、その提案だけを残します。答えはすぐに見つかります。そこにあるあなたの質問に答えるだけでなく、調査する価値のあるさらに多くの質問を見つけてください。

楽しみ！

コメントに基づいて、詳細が必要なようです。

私が特にお勧めするのは、コードベースを個々のサブプロジェクトに分割し、それぞれが 1 つの成果物を生成することです。メイン アプリケーション (.EXE) は 1 つにする必要があり、サポートするバイナリはそれぞれ別のプロジェクトにする必要があり、インストーラーは別のプロジェクトにするなどです。

各プロジェクトは、単一の主要成果物 (.EXE、.DLL、.HLP など) を生成します。その成果物は、単一の共有ローカル出力ディレクトリに「公開」されます。

サブプロジェクトがピアであるディレクトリ ツリーを作成し (深さや階層は役に立たないため)、プロジェクトが互いのサブツリーに「到達」しないようにします。各プロジェクトは完全に独立し、主要な成果物のみに依存する必要があります。共有出力ディレクトリで参照される他のサブプロジェクトの。

相互に呼び出すビルド スクリプトの階層を作成しないでください。私が作成したところ、価値はありませんが、メンテナンスの労力が指数関数的に増加することがわかりました。代わりに、スタンドアロン ビルド スクリプトを呼び出す継続的インテグレーション スクリプトを作成しますが、最初に一時ディレクトリへのクリーン チェックアウトを実行します。

ビルド出力や使用するライブラリなどではなく、成果物や依存関係をソース管理にコミットしないでください。ソース管理とは別にデプロイする Maven のようなバイナリ リポジトリに対して Ivy を使用し、独自の成果物をそこに公開します。組織内で共有するため。

Maven は使用しないでください。複雑すぎて、ビルド プロセスが難読化されるため、カスタマイズするのに費用対効果が高くありません。

ターゲット プラットフォームに基づいて、SCons、BuildBot、Ant、Ivy、nAnt などに移行しています。

私はこのトピックに関するホワイトペーパーを作成しており、聴衆がいる可能性があります。

編集:バージョン管理リポジトリをどのように整理しますか?に対する私の詳細な回答をご覧ください。

于 2008-11-17T20:30:40.430 に答える
2

なぜ5.x？（projectAの下で）

ツリーにバージョンを導入することは有用ではないと思います-それがsubversionなどの目的です。

于 2008-11-17T19:49:05.583 に答える