項目文件夾結構建議

Question

我準備實施一個源代碼管理系統（顛覆），但我正面臨着如何構建我的文件夾一些懷疑。

我使用Delphi進行所有開發，並從IDE中編譯項目。

我當前的項目文件夾結構如下：

 
-E:\Work\1. Shared 
--Forms (shared forms across all projects) 
--Units (shared units/classes across all projects including 3rd party like JCL) 

-E:\Work\2. Company Name 
--Admin (stuff related with admin work like a license keys generator, Windows CGI to handle order processing automatically, all developed in Delphi) 
--Projects 
----ProjectA 
-----5.x (version 5.x) 
------BIN (where all the binaries for this project go) 
------Build Manager (where the FinalBuilder project lives) 
-------Install (NSIS file that create the setup.exe) 
-------Protection (Project files to protect the compiled exe) 
-------Update (inf files related with the auto-update) 
------Docs (where the readme.txt, license.txt and history.txt that are included in the setup file are) 
-------Defects (docs for any testing done by me or others) 
-------HTMLHelp (html help for the project) 
------R&D (where screenshots, design ideas and other R&D stuff goes to) 
------Releases (when building a release with FinalBuilder the setup file created by nsis is placed here) 
------Resources (Images and other resources used by this project) 
------Source (if a sub-project exists it will compile to BIN since they are all related) 
-------SubprojectA 
-------SubprojectB 
-------SubprojectC 
--Sites 
--- companywebsite.com (the only one at the moment but if we decide to have individual web sites for products they would all be placed on the Sites folder) 

符號 「 - 」 標記目錄。

任何人都在意對當前結構發表評論或有任何改進建議嗎？

謝謝！

Answer 1

多年來，我已經設置了數百個項目，並且專門從事軟件配置管理和發佈工程，我建議您首先關注如何構建/發佈項目。

如果您只使用IDE構建（編譯和打包）您的項目，那麼您可能只需遵循該IDE的典型約定以及任何可能找到的「最佳實踐」。

但是，我強烈建議您不要僅使用IDE構建，甚至根本不要構建。相反，使用一個或多個可用的許多精彩的開源工具創建一個自動構建/發佈腳本。既然你看起來是針對Windows的，我建議先看一下Ant，Ivy和相應的xUnit（jUnit for Java，nUnit for .NET等）來進行測試。

一旦你開始了這條道路，你會發現很多關於項目結構，設計你的構建腳本，測試等的建議。現在，我不會給你提供詳細的建議，而只是給你留下這個建議 - 你很容易在那裏找到你的問題的答案，以及找到更多值得調查的問題。

享受！

根據評論，似乎需要一些細節。

我會做的一個特別的建議是將代碼庫分成單獨的子項目，每個子項目生成一個單一的可交付物。主要應用程序（.EXE）應該是一個，任何輔助二進制文件都將是單獨的項目，安裝程序將是一個單獨的項目等。

每個項目都會生成一個主要可交付物：.EXE，.DLL，一個.HLP等等。這個可交付成果被「發佈」到一個單獨的，共享的，本地的輸出目錄。

製作一個目錄樹，其中的子項目是對等的（沒有深度或層次結構，因爲它沒有幫助），也不要讓項目「進入」彼此的子樹 - 每個項目應該是完全獨立的，在其他子項目的主要可交付成果中，在共享輸出目錄中引用。

不要創建相互調用的構建腳本的層次結構，我做了並發現它不會增加值，但會成倍增加維護工作量。相反，製作一個持續集成腳本來調用獨立的構建腳本，但首先會對臨時目錄執行乾淨檢查。

不要將任何可交付成果或依賴關係提交到源代碼管理 - 不是您的構建輸出，也不是您使用的庫等。使用Ivy針對與源代碼管理分開部署的類似Maven的二進制存儲庫，併發布您的將自己的交付成果交給您的組織進行共享。

呵呵，不要使用Maven - 它太複雜了，混淆了構建過程，因此不具有成本效益。

我正在朝着SCons，BuildBot，Ant，Ivy，nAnt等基於我的目標平臺發展。

我一直在撰寫關於這個話題的白皮書，我看到的可能有觀衆。

編輯：請看看我的詳細解答How do you organize your version control repository?

Answer 2

爲什麼5.x？ （在項目A下）

我不認爲在樹中引入版本是有用的 - 這就是顛覆等等。