Projects文件夹结构建议

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（适用于Java的jUnit，适用于.NET的nUnit等）以进行测试。

一旦你开始走这条道路，你会发现很多关于项目结构，设计你的构建脚本，测试等的建议。现在我不会给你提供详细的建议，我会简单地告诉你这个建议 - 你会很容易在那里找到你问题的答案，并找到更多值得研究的问题。

享受！

根据评论，似乎需要一些细节。

我要做的一个特别建议是，将您的代码库分成单独的子项目，每个子项目都会产生一个可交付成果。主应用程序（.EXE）应该是一个，任何支持二进制文件都是单独的项目，安装程序将是一个单独的项目等。

每个项目都会生成一个主要的可交付成果：.EXE，.DLL，.HLP等。该可交付成果“发布”到单个共享的本地输出目录。

创建一个目录树，其中子项目是对等的（没有深度或层次结构，因为它没有帮助），并且不要让项目“到达”彼此的子树 - 每个项目应该是完全独立的，仅依赖于共享输出目录中引用的其他子项目的主要可交付成果。

不要创建相互调用的构建脚本层次结构，我做了，发现它不会增加价值，但会以指数方式增加维护工作量。相反，创建一个连续集成脚本来调用您的独立构建脚本，但首先要清理结帐到临时目录。

不要将任何可交付成果或依赖项提交到源代码控制中 - 不是您的构建输出，而不是您使用的库等。将Ivy用于与源代码控制分开部署的类似Maven的二进制存储库，并发布您自己的可交付成果，以便在您的组织内共享。

哦，不要使用Maven - 它太复杂了，会混淆构建过程，因此定制时效率不高。

我正在基于我的目标平台转向SCons，BuildBot，Ant，Ivy，nAnt等。

我一直在撰写关于这个主题的白皮书，我认为可能会有观众。

编辑：请参阅How do you organize your version control repository?

的详细答案

Answer 2

为什么5.x？ （在projectA下）

我不认为在树中引入版本是有用的 - 这就是subversion等的用途。